Re: perl-5.14.2 switch

[Reini Urban <rurban@x-ray.at>]

On Wed, Jul 11, 2012 at 4:53 AM, Yaakov (Cygwin/X)  wrote:
> On Tue, Jul 10, 2012 at 1:01 PM, Reini Urban wrote:
>> I'll be switching perl from 5.10 to 5.14 in the next days.
>
> Another issue:
>
> $Config{static_ext} is defined as Win32CORE.  The problem is that any
> use of ExtUtils::Embed then requires Win32CORE; its bootstrap call is
> included by xsinit and the static library added to ldopts, resulting
> in the w32_* functions being exported by any EU::E module.

Yes, same as for the Cygwin:: functions.

> Where this really breaks things is where a EU::E module is linked with
> libtool (as in gnumeric's perl-loader plugin): the xsinit-generated
> code calls boot_Win32CORE() but libtool will drop any static link
> libraries when creating a shared library/module, meaning the link
> fails with an unresolved reference to said function.
>
> AFAICS, static_ext should be empty; packages which actually need the
> w32_* symbols can add Win32CORE as an argument to the EU::E functions.

I see the problem, but I'm afraid that I cannot move Win32CORE from
static to dynamic now.
Generally we must have the ability to support both types of exts,
static and dynamic. Some internal exts are also static, such as
Cygwin, Internals, utf8, UNIVERSAL, DynaLoader, PerlIO, mro and
partially version, attributes, Tie::Hash::NamedCapture. But they are
included in libperl.

Previously I solved this by adding Win32CORE.o to libperl itself.
Should I do that?
-- 
Reini Urban
http://cpanel.net/   http://www.perl-compiler.org/

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple