2008/5/9 Yaakov (Cygwin Ports): > Reini Urban wrote: > | I see. To summarize: > | DynaLoader.o is contained in libperl.dll.a, > | Win32CORE.a not. > | ExtUtils::Embed ldopts is correct, but not libtool compatible. > > So far, correct. > > | Note: the next -e 'cmd' looks weird, but is needed for the -e one-liner. > | $ perl5.10.0d -MExtUtils::Embed -e'ccflags; print ldopts(1)' > | > | -DPERL_USE_SAFE_PUTENV -U__STRICT_ANSI__ -mms-bitfields -DDEBUGGING > | -fno-strict-aliasing -pipe -I/usr/local/include -Wl,--enable-auto-import > | -Wl,--export-all-symbols -Wl,--stack,8388608 > | -Wl,--enable-auto-image-base -L/usr/local/lib > | /usr/lib/perl5/5.10/i686-debug-cygwin/auto/Win32CORE/Win32CORE.a > | -L/usr/lib/perl5/5.10/i686-debug-cygwin/CORE -lperl -ldl -lcrypt > | -lgdbm_compat > > That -mms-bitfields flag doesn't belong; it's only for MSVC.
Not really. It's required for linking MSVC dll's which share a struct with such bitfields. Because MSVC has a larger bitfield alignment than gcc. Unfortunately perl-5.10 switched to use the structs op and sv with bitfields, so we had to add -mms-bitfields to CORE for the MSWin32 and cygwin ports. The blead patch was done Robert May to work around that, but 5.10 needs -mms-bitfields. Win32::GUI requires it. > | libtool will not link a dynamic lib with a static lib, but ld does. Hmm. > | Is this really true? > > Absolutely. Look at ltmain.sh (2.2) starting at line ~5268 (grep "Not a > shared"). > > | Do you have an example? > > http://cygwin-ports.cvs.sourceforge.net/*checkout*/cygwin-ports/ports/kde/kdevelop/kdevelop-3.5.1-1.src.patch > http://cygwin-ports.cvs.sourceforge.net/*checkout*/cygwin-ports/ports/media/vlc/vlc-0.8.6d-1.cygport > http://cygwin-ports.cvs.sourceforge.net/*checkout*/cygwin-ports/ports/ocaml/ocamlnet/ocaml-ocamlnet-2.2.9-1.cygport > http://cygwin-ports.cvs.sourceforge.net/*checkout*/cygwin-ports/ports/python/pygobject/python-gobject2-2.14.1-1.cygport I see. This will need more testing time, but I will make the test public so I'll upload -4 tomorrow. > | perl-5.8.8 had the very same issue, there was even DynaLoader.a needed. > > Correct, this is not a regression. > > | I would rather complain at libtool, because it inspects the libs and > | should know to get the -Wl,--Bstatic <staticlibs> -Wl,--Bdynamic > | <dynamiclibs> cmdline right in such a case. > > As you said, the linker doesn't care, and doesn't need those flags > unless you're specifically trying to link against a static library where > a .dll.a also exists. I'm not sure if libtool's behaviour is by design > (for fear of undefined symbols), or simply an oversight. Chuck? mod_perl is a shared library and libtool does not detect the static_pic .a > | And I'm more afraid to break some perl packages by defining static_ext, > | but leaving out Win32CORE.a. > > AFAICS, that's what we have now with -3. :-) Only with the very few libtoolized packages you listed above. I have to check if other cpan packages will have problems with your suggestions. Or I'll propose it upstream, putting all cygwin static_ext's in one lib (moving Win32CORE into libperl) and remove the static_ext need for Win32CORE. Hmm. This was done for DynaLoader recently and this required a few dirty exceptions. But for all platforms generally, so I don't think that our hack is acceptable. Anyway, I'll try and I have another a -Uusedl patch for Win32CORE sitting in the queue and the make install problems is also not fixed yet. I hacked around it in the build script so far. > It should only affect those packages using EU::Embed (mod_perl and a > few libtoolized packages). But mod_perl is a bummer. Your suggestion makes a lot of sense. -- Reini Urban