Perl 5.10 stabilization

Reini Urban rurban@x-ray.at
Fri May 9 09:09:00 GMT 2008


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



More information about the Cygwin-apps mailing list