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

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

Thread Previous | Thread Next
From:
sisyphus1
Date:
June 2, 2013 12:15
Subject:
Re: dmake can't find config.h, and collector throws error when trying to compile perl-static.exe (perl-5.18.0 / mingw / 32b)
Message ID:
9DA00169B70A4FABA74F6A59B6D6D8B1@OwnerPC311012

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.)


Cheers,
Rob



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