[sent to both lists, I'll watch both and summarize then]
I'm quite unhappy with my recent PERL_SUBVERSION stripping from the dll.
It's a long time since the gnu linker can directly link to a .dll.
On cygwin I have more and more problems in the toolchain with the dll
naming.
installperl has weird hacks, ExtUtils::Embed, the B Compiler.
I want to change back the stripping of the last version digit (from
5_11_0 to 5_11) that it does this only if usedevel is undefined.
With usedevel one should be able to have multiple versions in parallel.
Anyway, it should be a user choice in Configure, and not a vendor and
now even core choice.
So I want to switch the cygwin libperl to the name of the shared lib, as
on most other platforms. This will require a change in Configure for the
cygwin specific part. In fact I want to get rid of most of the cygwin
specialities.
The remaining only quirks should be that Win32CORE.o should be linked
into libperl also, to work around libtool problems when building
mod_perl and other libtool projects linking to perl. (I'll propose in
another thread).
The importlib should stay in archlib/CORE for older modules searching it
there - ExtUtils::CBuilder apparently does not care about
$Config{libperl}. See lib/ExtUtils/CBuilder/Platform/cygwin.pm hardcoded
against libperl.dll.a which fails on older perls < 5.8.
Opinions?
I have such a patch in work and tested for a month or so, but it's still
not good enough.
I haven't yet checked against the ld version, if the old linker supports
direct dll linkage.
--
Reini Urban
http://phpwiki.org/ http://murbreak.at/
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
