perl-5.14.2 switch

perl-5.14.2 switch

[Reini Urban]

I'll be switching perl from 5.10 to 5.14 in the next days.
These are the packages which need to be switched also:

perl-net-libproxy               Yaakov S
perl-locale-gettext             Yaakov S
perl-dbd-mysql                  Yaakov S
perl-dbi                        Yaakov S
perl-tk                         Yaakov S

perl-win32-gui                  Reini Urban (ready as test)
perl-libwin32                   Reini Urban

subversion-perl                 David Rothenberger (ready as test)

perl-ming                           Volker Zell

perl-image-magick               Marco Atzeri (ready as test)
perl-graphics-magick            Marco Atzeri (ready as test)

I'll change the setup.hints from the one marked as ready as test by myself,
no action from your side needed. Just adjust your private hints also please.

I just need Yaakov and Volker to followup with rebuilt packages. Can
you please confirm?
You can do it earlier with the perl test package or later. If later,
you need to update perl
and rebuild your packages.
-- 
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

Re: perl-5.14.2 switch

[Yaakov (Cygwin/X)]

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.

Your rebase pure_install changes in EU::MM_Cygwin do not take DESTDIR
into account, breaking cygport.  Line 195 of said module needs to be
changed to (as one long line):

$s =~ s|^(pure_install ::
pure_\$\(INSTALLDIRS\)_install\n\t)\$\(NOECHO\)
\$\(NOOP\)\n|$1\$(CHMOD) \$(PERM_RWX) \$(DESTDIR)$dll\n\ttest -n
"\$(DESTDIR)\" \|\| /bin/rebase -s $dll\n|m;

I have fixed my local copy in the meantime and am continuing to work
on the upgrade, but this is a blocker for 5.14.


Yaakov

--
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

Re: perl-5.14.2 switch

[Reini Urban]

On Tue, Jul 10, 2012 at 3:56 PM, 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.
>
> Your rebase pure_install changes in EU::MM_Cygwin do not take DESTDIR
> into account, breaking cygport.  Line 195 of said module needs to be
> changed to (as one long line):
>
> $s =~ s|^(pure_install ::
> pure_\$\(INSTALLDIRS\)_install\n\t)\$\(NOECHO\)
> \$\(NOOP\)\n|$1\$(CHMOD) \$(PERM_RWX) \$(DESTDIR)$dll\n\ttest -n
> "\$(DESTDIR)\" \|\| /bin/rebase -s $dll\n|m;
>
> I have fixed my local copy in the meantime and am continuing to work
> on the upgrade, but this is a blocker for 5.14.

Great find!

I've completed my remaining deps also, so only Volker is missing with one.
I'll fix this and do the switch ASAP.
Thanks.

Then we can improve rebasing with Achim's patch.
-- 
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

Re: perl-5.14.2 switch

[Yaakov (Cygwin/X)]

On Tue, Jul 10, 2012 at 5:36 PM, Reini Urban wrote:
> On Tue, Jul 10, 2012 at 3:56 PM, Yaakov (Cygwin/X) wrote:
>> Your rebase pure_install changes in EU::MM_Cygwin do not take DESTDIR
>> into account, breaking cygport.  Line 195 of said module needs to be
>> changed to (as one long line):
>>[snip]
>
> Great find!
>
> I've completed my remaining deps also, so only Volker is missing with one.

I doubt perl-ming is used by many, so if Volker is busy, let's not wait for it.

> I'll fix this and do the switch ASAP.
> Thanks.

Found another problem which breaks gtk2-perl modules (which link
against each other).  The following change needs to be made in
ExtUtils::Liblist::Kid::_unix_os2_ext(), line 135:

-                 && -f ($fullname="$thispth/lib$thislib.$Config_dlext")) {
+                 && -f ($fullname="$thispth/$thislib.$Config_dlext")) {

I have made this change locally and am continuing the rebuild for Ports.


Yaakov

--
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

Re: perl-5.14.2 switch

[Reini Urban]

On Tue, Jul 10, 2012 at 6:10 PM, Yaakov (Cygwin/X) wrote:
> On Tue, Jul 10, 2012 at 5:36 PM, Reini Urban wrote:
>> On Tue, Jul 10, 2012 at 3:56 PM, Yaakov (Cygwin/X) wrote:
>>> Your rebase pure_install changes in EU::MM_Cygwin do not take DESTDIR
>>> into account, breaking cygport.  Line 195 of said module needs to be
>>> changed to (as one long line):
>>>[snip]
>>
>> Great find!
>>
>> I've completed my remaining deps also, so only Volker is missing with one.
>
> I doubt perl-ming is used by many, so if Volker is busy, let's not wait for it.
>
>> I'll fix this and do the switch ASAP.
>> Thanks.
>
> Found another problem which breaks gtk2-perl modules (which link
> against each other).  The following change needs to be made in
> ExtUtils::Liblist::Kid::_unix_os2_ext(), line 135:
>
> -                 && -f ($fullname="$thispth/lib$thislib.$Config_dlext")) {
> +                 && -f ($fullname="$thispth/$thislib.$Config_dlext")) {
>
> I have made this change locally and am continuing the rebuild for Ports.

I do not really understand. A few lines below we check for this case
            elsif ( -f ( $fullname = "$thispth/$thislib.dll" ) ) {
            }
and skip then.
Is there a corner-case case where you have a lib<name>.dll and no <name>.dll,
and lib<name>.dll should not be linked against?

I've also found one more, so I will switch tomorrow. It needs more tests.

--- ./usr/lib/perl5/5.14/ExtUtils/MM_Cygwin.pm~	2012-07-10
18:24:11.977053200 -0500
+++ ./usr/lib/perl5/5.14/ExtUtils/MM_Cygwin.pm	2012-07-10
18:29:50.461428200 -0500
@@ -189,8 +189,8 @@
     my ($rebasever) = $rebaseverstr =~ /rebase version ([0-9.]+)/;
     $rebasever =~ s/(\d\.\d+)\./$1/;
     if ($rebasever > 3.01) {  # new rebase 3.0.2 with database
	my $INSTALLDIRS = $self->{INSTALLDIRS};
-      my $INSTALLLIB = $self->{"INSTALL".uc($INSTALLDIRS)."ARCH"};
+      my $INSTALLLIB = $self->{"INSTALL". ($INSTALLDIRS eq 'perl' ?
'ARCHLIB' : uc($INSTALLDIRS)."ARCH")};
       my $dll =
"$INSTALLLIB/auto/$self->{FULLEXT}/$self->{BASEEXT}.$self->{DLEXT}";
       $s =~ s|^(pure_install ::
pure_\$\(INSTALLDIRS\)_install\n\t)\$\(NOECHO\)
\$\(NOOP\)\n|$1\$(CHMOD) \$(PERM_RWX) \$(DESTDIR)$dll\n\t/bin/rebase
-s \$(DESTDIR)$dll\n|m;
     }

-- 
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

Re: perl-5.14.2 switch

[Yaakov (Cygwin/X)]

On Tue, Jul 10, 2012 at 6:51 PM, Reini Urban wrote:
> On Tue, Jul 10, 2012 at 6:10 PM, Yaakov (Cygwin/X) wrote:
>> Found another problem which breaks gtk2-perl modules (which link
>> against each other).  The following change needs to be made in
>> ExtUtils::Liblist::Kid::_unix_os2_ext(), line 135:
>>
>> -                 && -f ($fullname="$thispth/lib$thislib.$Config_dlext")) {
>> +                 && -f ($fullname="$thispth/$thislib.$Config_dlext")) {
>>
>> I have made this change locally and am continuing the rebuild for Ports.
>
> I do not really understand. A few lines below we check for this case
>             elsif ( -f ( $fullname = "$thispth/$thislib.dll" ) ) {
>             }
> and skip then.

I don't see that line in my file.  Perhaps this is a newer version or
local modification on your part?


Yaakov

--
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

Re: perl-5.14.2 switch

[Reini Urban]

On Tue, Jul 10, 2012 at 9:19 PM, Yaakov (Cygwin/X) wrote:
> On Tue, Jul 10, 2012 at 6:51 PM, Reini Urban wrote:
>> On Tue, Jul 10, 2012 at 6:10 PM, Yaakov (Cygwin/X) wrote:
>>> Found another problem which breaks gtk2-perl modules (which link
>>> against each other).  The following change needs to be made in
>>> ExtUtils::Liblist::Kid::_unix_os2_ext(), line 135:
>>>
>>> -                 && -f ($fullname="$thispth/lib$thislib.$Config_dlext")) {
>>> +                 && -f ($fullname="$thispth/$thislib.$Config_dlext")) {
>>>
>>> I have made this change locally and am continuing the rebuild for Ports.
>>
>> I do not really understand. A few lines below we check for this case
>>             elsif ( -f ( $fullname = "$thispth/$thislib.dll" ) ) {
>>             }
>> and skip then.
>
> I don't see that line in my file.  Perhaps this is a newer version or
> local modification on your part?

Not that I know of.
Can you please check the perl-5.14.2-2 test version I just uploaded?
-- 
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

Re: perl-5.14.2 switch

[Yaakov (Cygwin/X)]

On Tue, Jul 10, 2012 at 9:31 PM, Reini Urban wrote:
> Not that I know of.
> Can you please check the perl-5.14.2-2 test version I just uploaded?

My patch is still required.

Another problem: libwww-perl in perl_vendor requires at least
HTTP-Date and HTTP-Message to be added.


Yaakov

--
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

Re: perl-5.14.2 switch

[Dr. Volker Zell]

>>>>> Reini Urban writes:

    > I'll be switching perl from 5.10 to 5.14 in the next days.
    > These are the packages which need to be switched also:

    > perl-ming                           Volker Zell

I'll do after my vacation.

Ciao
  Volker
  

--
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

Re: perl-5.14.2 switch

[Yaakov (Cygwin/X)]

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.

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.


Yaakov

--
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

Re: perl-5.14.2 switch

[Reini Urban]

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

Re: perl-5.14.2 switch

[Steven Hartland]

Just been trying the 5.14.2 that's was available in setup.exe as of
6th June 2012 and the dependencies for LWP are quite broken.

So far I found the following missing dependencies for libwww:-
Warning: prerequisite File::Listing 6 not found.
Warning: prerequisite HTTP::Daemon 6 not found.
Warning: prerequisite WWW::RobotRules 6 not found.
Warning: prerequisite HTTP::Negotiate 6 not found.

Although this may be expected behaviour, I wanted to highlight
the fact that quite a few packages require perl yet have hardcoded
dependencies on 5.10.x so setup ends up messing up the install
when ever its used if you let it "correct" dependencies :(

    Regards
    Steve


--
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

Re: perl-5.14.2 switch

[Achim Gratz]

Steven Hartland writes:
> Just been trying the 5.14.2 that's was available in setup.exe as of
> 6th June 2012 and the dependencies for LWP are quite broken.

I have recompiled all Perl modules in perl_vendor as separate packages
due to (among other things) problems with LWP.

> Although this may be expected behaviour, I wanted to highlight
> the fact that quite a few packages require perl yet have hardcoded
> dependencies on 5.10.x so setup ends up messing up the install
> when ever its used if you let it "correct" dependencies :(

This can be rectified by making perl-5.10 "prev" and move perl-5.14 from
"test" to current in setup.ini — since setup doesn't support version
directed dependencies unless the package name includes the version
somehow, I actually recreate setup.ini when pulling from a (local)
mirror for Cygwin plus my local package and patch archive.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs


--
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

Re: perl-5.14.2 switch

[Steven Hartland]

----- Original Message ----- 
From: "Achim Gratz" 

> Steven Hartland writes:
>> Just been trying the 5.14.2 that's was available in setup.exe as of
>> 6th June 2012 and the dependencies for LWP are quite broken.
> 
> I have recompiled all Perl modules in perl_vendor as separate packages
> due to (among other things) problems with LWP.

Cool looking forward to it the new update :)

    Regards
    Steve


--
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

Re: perl-5.14.2 switch

[Achim Gratz]

Steven Hartland writes:
>> I have recompiled all Perl modules in perl_vendor as separate packages
>> due to (among other things) problems with LWP.
>
> Cool looking forward to it the new update :)

I don't think that Reini will switch from perl_vendor to unbundled
module packages, at least not for this release.  I've posted a link to
my cygport package definitions over in cygwin-apps if you want to
compile those packages yourself.  If you don't create your own setup.ini
files, it's probably not much use.  You can always use cpanminus to
bootstrap LWP to a newer version locally.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables


--
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

Re: perl-5.14.2 switch

[Steven Hartland]

----- Original Message ----- 
From: "Achim Gratz" 

> Steven Hartland writes:
>> Cool looking forward to it the new update :)
> 
> I don't think that Reini will switch from perl_vendor to unbundled
> module packages, at least not for this release.  I've posted a link to
> my cygport package definitions over in cygwin-apps if you want to
> compile those packages yourself.  If you don't create your own setup.ini
> files, it's probably not much use.  You can always use cpanminus to
> bootstrap LWP to a newer version locally.

Unfortunately the current perl_vendor install is so broken cpan
won't allow you to fix it with simple "install" unless you know
the exact missing modules and just breaks in some very strange
and random ways. Like missing protocol for ftp in LWP

However the perl_vendor was created it resulted in many missing
dependencies. I don't mind a block install via perl_vendor but
each module installed by that option should include all of its
dependencies otherwise its worse than having nothing at all.

We'd already updated Bundle::LWP via CPAN but its the dependencies
of the dependencies which are missing so they didn't get fixed.

Our fix in the end, so others know, was to use:-
force install LWP::Protocol::ftp

This seemed to force all dependencies in the hierarchy to be
rechecked and hence picked up and installed the missing modules.

    Regards
    Steve


--
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

Re: perl-5.14.2 switch

[Achim Gratz]

Steven Hartland writes:
> Unfortunately the current perl_vendor install is so broken cpan
> won't allow you to fix it with simple "install" unless you know
> the exact missing modules and just breaks in some very strange
> and random ways. Like missing protocol for ftp in LWP

I suggested to use cpanminus — not cpan — for a reason.  It is possible
to get things to eventually work as you want via CPAN, but it is much
less effort to do so via cpanminus.  You can then continue using CPAN
for new modules if you wish.  Remove perl_vendor first, in the end this
is much easier than papering over it via site-perl.

Also, make sure you have removed all remnants from perl-5.10 (including
locally installed modules).  The ability of 5.14 to fall back to modules
that were installed for 5.10 is a double-edged sword, the two versions
are sufficiently different so that I would not want to mix them at the
module level.

Last but not least, Reini has asked for testers of the new perl quite a
while back and didn't get all that many responses.  Even with those
kinks in perl_vendor (which I'm sure he'll fix) the 5.14 to me is the
least problematic perl version on Cygwin so far.  I have only a glimpse
of how much work that must have been and I really appreciate it.  I'm
sure Reini wouldn't mind if someone just took the sources for
perl_vendor and fixed whatever needs fixing and feed back the changes to
him...


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada


--
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

Re: perl-5.14.2 switch

[Reini Urban]

On Thu, Jul 12, 2012 at 12:19 AM, Achim Gratz wrote:
> Steven Hartland writes:
>> Unfortunately the current perl_vendor install is so broken cpan
>> won't allow you to fix it with simple "install" unless you know
>> the exact missing modules and just breaks in some very strange
>> and random ways. Like missing protocol for ftp in LWP

You are right. Back when I managed the _vendor list LWP was still
pre-6.0 and had different deps. I needed LWP to get CPAN and then
CPAN::TestReporter to work (at least bootstrap), so people can manage
their own packages, and do not rely on cygwin packages.
And the upstream maintainers get windows reports about failures, which
they need to fix their stuff. They always complain not getting any
windows reports, so they rather bitch. At least they get cygwin
reports for some time now.

I've updated the list of missing deps yesterday.

> I suggested to use cpanminus — not cpan — for a reason.  It is possible
> to get things to eventually work as you want via CPAN, but it is much
> less effort to do so via cpanminus.  You can then continue using CPAN
> for new modules if you wish.

Agreed.

> Remove perl_vendor first, in the end this is much easier than papering over it
> via site-perl.

Sorry for the missing deps conflicts. This will be fixed in 5.14.2-3.

> Also, make sure you have removed all remnants from perl-5.10 (including
> locally installed modules).  The ability of 5.14 to fall back to modules
> that were installed for 5.10 is a double-edged sword, the two versions
> are sufficiently different so that I would not want to mix them at the
> module level.

I do not agree. XS modules are not looked up from 5.10, and there is
no problem to continue using old modules if they were never updated on
CPAN.
If so, you well get new ones anyway with your next cpan or cpanm update.
It's a one-liner, but needs a lot of time to re-install everything from scratch.

$ cat ~/bin/cpanautoinstall
#!/usr/bin/env perl
use CPAN; CPAN::Shell->install(CPAN::Shell->r)

or just:
$ perl -MCPAN -e'CPAN::Shell->install(CPAN::Shell->r)'

One other remaining problem is libtool's inability to mix static Win32CORE.a
with shared, so I'll probably add Win32CORE.o to libperl instead. It's a shame.
But perl is also blame as it still does not support installing
static_ext .a libs.
I have to do that manually.

> Last but not least, Reini has asked for testers of the new perl quite a
> while back and didn't get all that many responses.  Even with those
> kinks in perl_vendor (which I'm sure he'll fix) the 5.14 to me is the
> least problematic perl version on Cygwin so far.  I have only a glimpse
> of how much work that must have been and I really appreciate it.  I'm
> sure Reini wouldn't mind if someone just took the sources for
> perl_vendor and fixed whatever needs fixing and feed back the changes to
> him...

Well, I'm not so happy with threads. They seem to be more broken than with 5.10.
But I like 5.14.2 generally at most of all also, much better than the
completely flawed 5.16.
-- 
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

Re: perl-5.14.2 switch

[Corinna Vinschen]

On Jul 12 10:24, Reini Urban wrote:
> Well, I'm not so happy with threads. They seem to be more broken than with 5.10.
> But I like 5.14.2 generally at most of all also, much better than the
> completely flawed 5.16.

Is this thread problem something Cygwin-specific, a Cygwin bug perhaps?
If so, can you nail that down into a simple C testcase?


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
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

Re: perl-5.14.2 switch

[Reini Urban]

On Thu, Jul 12, 2012 at 11:14 AM, Corinna Vinschen wrote:
> On Jul 12 10:24, Reini Urban wrote:
>> Well, I'm not so happy with threads. They seem to be more broken than with 5.10.
>> But I like 5.14.2 generally at most of all also, much better than the
>> completely flawed 5.16.
>
> Is this thread problem something Cygwin-specific, a Cygwin bug perhaps?
> If so, can you nail that down into a simple C testcase?

The failing thread tests in perls testsuite are unfortunately not so simple.
Mostly torture tests.
google's threadsanitizer might come handy.
I found a lot of perl bugs with the related addresssanitizer.

I'm pretty sure it's perls fault here, because mingw has the same problems.
And the were some subtle changes between 5.10 and 5.14. I tried to improve
it with a patch, but it didn't help much.
-- 
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

Re: perl-5.14.2 switch

[Yaakov (Cygwin/X)]

On Wed, Jul 11, 2012 at 10:07 AM, Reini Urban wrote:
> On Wed, Jul 11, 2012 at 4:53 AM, Yaakov (Cygwin/X)  wrote:
>> 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.

I'm not complaining that Win32CORE is static, if EU::E wouldn't insist
on using it all the time.

> Previously I solved this by adding Win32CORE.o to libperl itself.
> Should I do that?

I suppose so.


Yaakov

--
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