Front page | perl.perl5.porters |
Postings from June 2013
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. LeonThread Previous | Thread Next