Perl 5.10 stabilization

Perl 5.10 stabilization

[Yaakov (Cygwin Ports)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Reini,

My perl packages are now ready for 5.10, as soon as you're ready to
stabilize:

ftp://sunsite.dk/projects/cygwinports/release/help2man/help2man-1.36.4-2-src.tar.bz2
ftp://sunsite.dk/projects/cygwinports/release/help2man/help2man-1.36.4-2.tar.bz2
ftp://sunsite.dk/projects/cygwinports/release/help2man/setup.hint

ftp://sunsite.dk/projects/cygwinports/release/perl/perl-ExtUtils-Depends/perl-ExtUtils-Depends-0.300-1-src.tar.bz2
ftp://sunsite.dk/projects/cygwinports/release/perl/perl-ExtUtils-Depends/perl-ExtUtils-Depends-0.300-1.tar.bz2
ftp://sunsite.dk/projects/cygwinports/release/perl/perl-ExtUtils-Depends/setup.hint

ftp://sunsite.dk/projects/cygwinports/release/perl/perl-ExtUtils-PkgConfig/perl-ExtUtils-PkgConfig-1.11-1-src.tar.bz2
ftp://sunsite.dk/projects/cygwinports/release/perl/perl-ExtUtils-PkgConfig/perl-ExtUtils-PkgConfig-1.11-1.tar.bz2
ftp://sunsite.dk/projects/cygwinports/release/perl/perl-ExtUtils-PkgConfig/setup.hint

ftp://sunsite.dk/projects/cygwinports/release/perl/perl-Locale-gettext/perl-Locale-gettext-1.05-3-src.tar.bz2
ftp://sunsite.dk/projects/cygwinports/release/perl/perl-Locale-gettext/perl-Locale-gettext-1.05-3.tar.bz2
ftp://sunsite.dk/projects/cygwinports/release/perl/perl-Locale-gettext/setup.hint

ftp://sunsite.dk/projects/cygwinports/release/perl/perl-Tk/perl-Tk-804.028-1-src.tar.bz2
ftp://sunsite.dk/projects/cygwinports/release/perl/perl-Tk/perl-Tk-804.028-1.tar.bz2
ftp://sunsite.dk/projects/cygwinports/release/perl/perl-Tk/setup.hint

IMPORTANT on the Tk setup.hint:  s/libX11_6/xorg-x11-bin-dlls/


Yaakov
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEAREIAAYFAkgGAX0ACgkQpiWmPGlmQSPtgQCg4tRElvzF2goUjwKJmmwJjr9F
1JwAoNSPBGiiMaLoBJDPJNItw1dgrxbT
=rhHt
-----END PGP SIGNATURE-----

Re: Perl 5.10 stabilization

[Reini Urban]

2008/4/16, Yaakov (Cygwin Ports) <yselkowitz@users.sourceforge.net>:
>  My perl packages are now ready for 5.10, as soon as you're ready to
>  stabilize:
>
> ftp://sunsite.dk/projects/cygwinports/release/help2man/help2man-1.36.4-2-src.tar.bz2
> ftp://sunsite.dk/projects/cygwinports/release/help2man/help2man-1.36.4-2.tar.bz2
> ftp://sunsite.dk/projects/cygwinports/release/help2man/setup.hint
>
> ftp://sunsite.dk/projects/cygwinports/release/perl/perl-ExtUtils-Depends/perl-ExtUtils-Depends-0.300-1-src.tar.bz2
> ftp://sunsite.dk/projects/cygwinports/release/perl/perl-ExtUtils-Depends/perl-ExtUtils-Depends-0.300-1.tar.bz2
> ftp://sunsite.dk/projects/cygwinports/release/perl/perl-ExtUtils-Depends/setup.hint
>
> ftp://sunsite.dk/projects/cygwinports/release/perl/perl-ExtUtils-PkgConfig/perl-ExtUtils-PkgConfig-1.11-1-src.tar.bz2
> ftp://sunsite.dk/projects/cygwinports/release/perl/perl-ExtUtils-PkgConfig/perl-ExtUtils-PkgConfig-1.11-1.tar.bz2
> ftp://sunsite.dk/projects/cygwinports/release/perl/perl-ExtUtils-PkgConfig/setup.hint
>
> ftp://sunsite.dk/projects/cygwinports/release/perl/perl-Locale-gettext/perl-Locale-gettext-1.05-3-src.tar.bz2
> ftp://sunsite.dk/projects/cygwinports/release/perl/perl-Locale-gettext/perl-Locale-gettext-1.05-3.tar.bz2
> ftp://sunsite.dk/projects/cygwinports/release/perl/perl-Locale-gettext/setup.hint
>
> ftp://sunsite.dk/projects/cygwinports/release/perl/perl-Tk/perl-Tk-804.028-1-src.tar.bz2
> ftp://sunsite.dk/projects/cygwinports/release/perl/perl-Tk/perl-Tk-804.028-1.tar.bz2
> ftp://sunsite.dk/projects/cygwinports/release/perl/perl-Tk/setup.hint
>
>  IMPORTANT on the Tk setup.hint:  s/libX11_6/xorg-x11-bin-dlls/

Great!

I started now the latest perl-5.10.0-4 build on my 2nd machine, but my
connection seems to be very bad today.
So it will be at the end of this week finished testing the latest build.

BTW: I finished building a static perl (single exe), and a non-threaded perl
(much faster), but I still have to find the cause for the two missing
static libs.
Maybe I'll a non-X11 perl-Tk ready also.
-- 
Reini Urban

Re: Perl 5.10 stabilization

[Reini Urban]

Reini Urban schrieb:
> 2008/4/16, Yaakov (Cygwin Ports) <yselkowitz@users.sourceforge.net>:
>>  My perl packages are now ready for 5.10, as soon as you're ready to
>>  stabilize:
 >
> Great!
> 
> I started now the latest perl-5.10.0-4 build on my 2nd machine, but my
> connection seems to be very bad today.
> So it will be at the end of this week finished testing the latest build.
> 
> BTW: I finished building a static perl (single exe), and a non-threaded perl
> (much faster), but I still have to find the cause for the two missing
> static libs.

I've found and fixed those linker problems and some more -Uusedl 
problems (static libperl only), but I'm still not happy with cornercases 
and certain hardcore packages. Maybe we should really wait for a 5.10.1 
to go stable. But I don't think that the new regex engine will get much 
faster with 5.10.1.

Current changes from -3 to -4:
No API changes, just one added DynaLoader.o in libperl and added one 
missing Win32CORE.a, so your packages will be fine.
And I've removed -Dusesitecustomize for performance reasons.

The packages are already at my setup site.

Anyway, I hope to finish testing until next weekend.
The current 5.10.0-4 version has the same test errors as 5.8.9, which is 
one more test failure than 5.8.8.
ext/Time/HiRes/t/HiRes......................FAILED--non-zero wait status: 15

The upcoming 5.8.9 is also keeping me steady smoking and adjusting build 
scripts, and I still have no time for fixing icu to be able to ITP parrot.

A perl-debug (perl5.10.0d.exe) and perl-nonthreaded package 
(perl5.10.0-nt.exe) for raw speed is also in consideration. (side-by 
side install), since I need that anyway, and packaging is quite easy 
with the changed build framework.
-- 
Reini Urban
http://phpwiki.org/  http://murbreak.at/

Re: Perl 5.10 stabilization

[Yaakov (Cygwin Ports)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Reini Urban wrote:
| Current changes from -3 to -4:
| No API changes, just one added DynaLoader.o in libperl and added one
| missing Win32CORE.a, so your packages will be fine.

I'll admit that I know nothing of Perl internals, but could Win32CORE.a
be added to libperl as well?  As I mentioned on the list, EU::Embed
creates dependencies on both DynaLoader and Win32CORE, and linking a
shared library/module against Win32CORE.a (or DynaLoader.a) doesn't work
OOTB when using libtool.  This would be helpful if it's possible.


Yaakov

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEAREIAAYFAkgg4AYACgkQpiWmPGlmQSNDQQCgh/9Fnkms7ANR4oKF646r0dAV
otUAni9uQrhuEKYmpsXDDw4/adWY0PrO
=0E0o
-----END PGP SIGNATURE-----

Re: Perl 5.10 stabilization

[Reini Urban]

2008/5/7 Yaakov (Cygwin Ports):
>  Reini Urban wrote:
>  | Current changes from -3 to -4:
>  | No API changes, just one added DynaLoader.o in libperl and added one
>  | missing Win32CORE.a, so your packages will be fine.
>
>  I'll admit that I know nothing of Perl internals, but could Win32CORE.a
>  be added to libperl as well?  As I mentioned on the list, EU::Embed
>  creates dependencies on both DynaLoader and Win32CORE, and linking a
>  shared library/module against Win32CORE.a (or DynaLoader.a) doesn't work
>  OOTB when using libtool.  This would be helpful if it's possible.

I tried both ways.
The standard perl way with Win32CORE.a explicitly added to
the linker line via $Config{static_ext}, and
the hackish way by adding Win32CORE.o to cygperl5_10.dll + libperl.dll.a
to have everything in one piece.

The bug was that installperl via make_ext forgot to copy Win32CORE.a
to the archlib so the linker could not pick it up.
We never use libtool when compiling and linking to perl, just g++ with
ccflags and
ld with ldflags and the libs.

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 deps.
But so far all perl libs know their deps by hand.
-- 
Reini Urban
http://phpwiki.org/ http://murbreak.at/

Re: Perl 5.10 stabilization

[Yaakov (Cygwin Ports)]

-----BEGIN PGP SIGNED MESSAGE-----
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
DynaLoader.

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

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.


Yaakov
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEAREIAAYFAkgib/YACgkQpiWmPGlmQSPJdwCgpu6dMh6D5zQ4X8wx5r2GdCS5
EVMAoLccwxtXZ1oWy45xX2eCnBeyilS4
=G8IS
-----END PGP SIGNATURE-----

Re: Perl 5.10 stabilization

[Reini Urban]

Yaakov (Cygwin Ports) schrieb:
> 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).
> 
> I don't want, nor need, perl to be built with libtool.  All I want is to
> link other packages against libperl with libtool.

I see. To summarize:
   DynaLoader.o is contained in libperl.dll.a,
   Win32CORE.a not.
   ExtUtils::Embed ldopts is correct, but not libtool compatible.

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

libtool will not link a dynamic lib with a static lib, but ld does. Hmm.
Is this really true?
Do you have an example?
perl-5.8.8 had the very same issue, there was even DynaLoader.a needed.

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.

And I'm more afraid to break some perl packages by defining static_ext, 
but leaving out Win32CORE.a.
-- 
Reini Urban
http://phpwiki.org/  http://murbreak.at/

Re: Perl 5.10 stabilization

[Yaakov (Cygwin Ports)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

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.

| 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

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

| 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. :-)  It should only affect
those packages using EU::Embed (mod_perl and a few libtoolized packages).


Yaakov
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEAREIAAYFAkgjq/4ACgkQpiWmPGlmQSMXSQCgj3e+ScH4hBz1sC6JjGmUrwrp
8GcAn34Xh/nWGorSt8QQCp9tmk78ZrX4
=wj8D
-----END PGP SIGNATURE-----

Re: Perl 5.10 stabilization

[Brian Dessent]

"Yaakov (Cygwin Ports)" wrote:

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

The part of ltmain.sh you're referring to is where it refuses to link to
a static library when *creating* a shared library.  It refuses to do
that because it cannot be done portably -- for example on most ELF
platforms (with the exception of i386) shared libraries must contain
only PIC code, and normally static libs are not built PIC.

Libtool should have no problem linking a final executable against a
combination of shared and static libs.

Brian

Re: Perl 5.10 stabilization

[Reini Urban]

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