develooper Front page | perl.perl5.porters | Postings from June 2013

Re: dmake can't find config.h, and collector throws error when tryingto compile perl-static.exe (perl-5.18.0 / mingw / 32b)

Thread Previous | Thread Next
From:
Leon Timmermans
Date:
June 2, 2013 13:05
Subject:
Re: dmake can't find config.h, and collector throws error when tryingto compile perl-static.exe (perl-5.18.0 / mingw / 32b)
Message ID:
CAHhgV8hzG9w1zg6t0_ipac9VjRXTDRfJym0JZF6VTMBuTRf1kA@mail.gmail.com
On Jun 2, 2013 2:16 PM, <sisyphus1@optusnet.com.au> wrote:
>
>
> From: Steve Hay
>
>
>> > No better results, all normal exes are ok but static one is not build,
>> > the same error at the end:
>> >   dmake:  Error code 129, while making '..\perl-static.exe'
>> > full raw log: http://pastebin.com/raw.php?i=hLXaeH81
>>
>> Otherwise, I see the same problem in blead (with WIN64=undef, as Rob
>> said). It also happens when just doing a BUILD_STATIC (as opposed to
>> ALL_STATIC) build, this time, of course, ending with just an undefined
>> reference to _boot_Win32CORE since that is the only extension linked
>> statically in that case:
>>
>> ..\libperl519s.a(perllib.o):perllib.c:(.text+0x9c): undefined reference
>> to `_boot_Win32CORE'
>> collect2.exe: error: ld returned 1 exit status
>>
>> dmake:  Error code 129, while making '..\perl-static.exe'
>>
>> This is with MinGW's gcc-4.7.0.
>>
>> The build works fine with nmake/VC++ and with dmake/VC++, so it is
>> definitely a problem with the gcc toolchain, rather than the dmake
>> makefile.
>>
>> I will try to investigate more later. Sorry for not testing this before
>> 5.18.0 was released. Static builds are not a configuration I generally
>> have in mind.
>>
>>
>> Sorry for the delay in getting back on this.
>>
>> I've now tried earlier versions of perl (the BUILD_STATIC option was
added
>> in Nov 2006 by commits 4e036e4bbb and ed2eab3fc8 and first appeared in
>> 5.9.5; the ALL_STATIC option was added in Sep 2007 by commit a1f2e71991
and
>> first appeared in 5.10.0) and an earlier version of www.mingw.org's gcc
>> (3.4.5), and even on an older version of Windows (XP SP3 rather than 7
SP1),
>> but I have not found any combination which works -- the BUILD_STATIC and
>> ALL_STATIC configurations always seem to end with that same "undefined
>> reference to '_boot_*'" error.
>>
>> I was a little surprised by this since I thought that I would surely have
>> tested this before committing the changes, but I have noticed in the
course
>> of trying things out today that 5.9.5 (which BUILD_STATIC was first added
>> to) doesn't actually build with gcc anyway. It had issues with
>> generate_uudmap.exe and perlglob.exe both crashing. I was able to work
>> around that today by copying those executables from a build of a later
>> version of perl, but at the time BUILD_STATIC was added it may very well
not
>> have been tested with gcc because of this. (I also note that the change
>> which added it (4e036e4bbb) only touched the nmake Makefile which is only
>> used for VC++ builds; I subsequently added the same changes to the dmake
>> makefile.mk in commit ed2eab3fc8 but would probably still only have
tested
>> that with VC++ since the gcc build was broken.)
>>
>> So it seems very likely that BUILD_STATIC and ALL_STATIC have never
worked
>> with gcc since the time they were first added, regardless of which
version
>> of gcc is being used.
>>
>> I am CCing the author of the original BUILD_STATIC and ALL_STATIC patches
>> (Vadim) in case he has any input here, and also one of the StrawberryPerl
>> maintainers (kmx) in case he has encountered any such issue in the
course of
>> working with gcc in StrawberryPerl.
>
>
> It's a bit odd. I see in the build process:
>
> ar rc  ..\libperl518s.a \
>        ..\lib\auto\B\B.a ..\lib\auto\Compress\Raw\Bzip2\Bzip2.a
..\lib\auto\Compress\Raw\Zlib\Zlib.a ..\lib\auto\Cwd\Cwd.a
..\lib\auto\Data\Dumper\Dumper.a ..\lib\auto\Devel\PPPort\PPPort.a
..\lib\auto\Devel\Peek\Peek.a ..\lib\auto\Digest\MD5\MD5.a
..\lib\auto\Digest\SHA\SHA.a ..\lib\auto\Fcntl\Fcntl.a
..\lib\auto\File\DosGlob\DosGlob.a ..\lib\auto\File\Glob\Glob.a
..\lib\auto\Filter\Util\Call\Call.a ..\lib\auto\Hash\Util\Util.a
..\lib\auto\Hash\Util\FieldHash\FieldHash.a ..\lib\auto\IO\IO.a
..\lib\auto\List\Util\Util.a ..\lib\auto\MIME\Base64\Base64.a
..\lib\auto\Math\BigInt\FastCalc\FastCalc.a ..\lib\auto\Opcode\Opcode.a
..\lib\auto\POSIX\POSIX.a ..\lib\auto\PerlIO\encoding\encoding.a
..\lib\auto\PerlIO\mmap\mmap.a ..\lib\auto\PerlIO\scalar\scalar.a
..\lib\auto\PerlIO\via\via.a ..\lib\auto\Socket\Socket.a
..\lib\auto\Storable\Storable.a ..\lib\auto\Sys\Hostname\Hostname.a
..\lib\auto\Text\Soundex\Soundex.a
..\lib\auto\Tie\Hash\NamedCapture\NamedCapture.a
..\lib\auto\Time\HiRes\HiRes.a ..\lib\auto\Time\Piece\Piece.a
..\lib\auto\Unicode\Collate\Collate.a
..\lib\auto\Unicode\Normalize\Normalize.a ..\lib\auto\Win32API\File\File.a
..\lib\auto\Win32CORE\Win32CORE.a ..\lib\auto\XS\APItest\APItest.a
..\lib\auto\XS\Typemap\Typemap.a ..\lib\auto\arybase\arybase.a
..\lib\auto\attributes\attributes.a ..\lib\auto\mro\mro.a
..\lib\auto\re\re.a ..\lib\auto\threads\threads.a
..\lib\auto\threads\shared\shared.a  \
>
> This would suggest that those missing boot symbols should *not* be
missing (as they're to be found in those various .a files specified in the
above command).
>
> However, if I do an 'objdump -t' on the libperl518s.a that was built, I
get:
>
> C:\_32>objdump -t C:/comp/perl-5.18.0/libperl518s.a >libperl518s.dump
> objdump: B.a: File format not recognized
> objdump: Bzip2.a: File format not recognized
> objdump: Zlib.a: File format not recognized
> objdump: Cwd.a: File format not recognized
> objdump: Dumper.a: File format not recognized
> objdump: PPPort.a: File format not recognized
> objdump: Peek.a: File format not recognized
> objdump: MD5.a: File format not recognized
> objdump: SHA.a: File format not recognized
> objdump: Fcntl.a: File format not recognized
> objdump: DosGlob.a: File format not recognized
> objdump: Glob.a: File format not recognized
> objdump: Call.a: File format not recognized
> objdump: Util.a: File format not recognized
> objdump: FieldHash.a: File format not recognized
> objdump: IO.a: File format not recognized
> objdump: Util.a: File format not recognized
> objdump: Base64.a: File format not recognized
> objdump: FastCalc.a: File format not recognized
> objdump: Opcode.a: File format not recognized
> objdump: POSIX.a: File format not recognized
> objdump: encoding.a: File format not recognized
> objdump: mmap.a: File format not recognized
> objdump: scalar.a: File format not recognized
> objdump: via.a: File format not recognized
> objdump: Socket.a: File format not recognized
> objdump: Storable.a: File format not recognized
> objdump: Hostname.a: File format not recognized
> objdump: Soundex.a: File format not recognized
> objdump: NamedCapture.a: File format not recognized
> objdump: HiRes.a: File format not recognized
> objdump: Piece.a: File format not recognized
> objdump: Collate.a: File format not recognized
> objdump: Normalize.a: File format not recognized
> objdump: File.a: File format not recognized
> objdump: Win32CORE.a: File format not recognized
> objdump: APItest.a: File format not recognized
> objdump: Typemap.a: File format not recognized
> objdump: arybase.a: File format not recognized
> objdump: attributes.a: File format not recognized
> objdump: mro.a: File format not recognized
> objdump: re.a: File format not recognized
> objdump: threads.a: File format not recognized
> objdump: shared.a: File format not recognized
>
> That must surely be part of the problem ? I wonder why those file formats
would be unrecognized.
>
> (Btw, this was with a 32-bit build using a mingw.org port of gcc-4.7.0.)

It seems that creates an archive of archives, instead of an archive of
object files.

Leon

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About