Perl 5.10 stabilization

Yaakov (Cygwin Ports)
Thu May 8 03:14:00 GMT 2008

Hash: SHA256

Reini Urban wrote:
| I tried both ways.
| The standard perl way with Win32CORE.a explicitly added to
| the linker line via $Config{static_ext}, and

Of course, but that makes things difficult when linking *other packages*
against libperl with libtool.  libtool won't link a shared library
against a static one on Cygwin, so if DynaLoader.a and Win32CORE.a are
among LIBS, libtool will complain, drop them, and the link will fail due
to undefined symbols boot_{DynaLoader,Win32CORE).

Adding these both to libperl would allow this to work.

| the hackish way by adding Win32CORE.o to cygperl5_10.dll + libperl.dll.a
| to have everything in one piece.

True, it's hackish; I only thought of it because of what you said about

| The bug was that installperl via make_ext forgot to copy Win32CORE.a
| to the archlib so the linker could not pick it up.

That would do it.

| We never use libtool when compiling and linking to perl, just g++ with
| ccflags and
| ld with ldflags and the libs.

Oh, I know that.

| Then I decided to got the standard perl way and use
| $Config{static_ext} with the extra Win32CORE.a
| EU::Embed and perlcc uses it like this.
| Do you want to change over to libtool for cc and ld?
| It's only useful if we want to link against .la files with complicated

I don't want, nor need, perl to be built with libtool.  All I want is to
link other packages against libperl with libtool.

| But so far all perl libs know their deps by hand.

True for CPAN packages, but the problem is with EU::Embed code.

Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla -


More information about the Cygwin-apps mailing list