Perl 5.8.0 will be released on Thursday (http://www.iki.fi/jhi/VVIIIN). Has there been any work to include it in Gentoo? Want some help?
Created attachment 2601 [details] Initial proposed ebuild for perl 5.8.0 My first attempt at an ebuild, basicly just a hack of the rc-5 ebuild with a correction for the url, and a correction for the SRC_URI path on perl.org. *NOT AN OFFICIAL EBUILD*, i.e. it really is just a hack, I haven't checked this against repoman yet, haven't verified that it has all of the appropriate flags, I'm still learning the ropes of ebuild submissions. It installed without errors on a 686 with gcc 2.95
repoman states (and I happily quote): "If everyone were like you, I'd be out of business!"
Couple of things: KEYWORDS: only add $arch if the revision has been shown to build on that arch. This probably inherited from perl-5.6.1-r4.ebuild, but it's a good thing to know (esp at present as the ppc ppl are wading through ebuilds tagging KEYWORDS etc). At a release, especially a core package release, ask a ppc/sparc dev to test (and remember portage-2.0.20 uses KEYWORDS now). I ran lintool --show-details on the ebuild, pretty much ok, though there are spaces instead of tabs (again proably inherited).
I'll clean both items up today. Thanks!
I've committed your ebuild as perl-5.8.0.ebuild (currently masked). I've also removed "ppc" from KEYWORDS as suggested by xselkirk.
Any chance of getting -Dusethreads added to the ebuild? This was the feature request made under 5727.
Created attachment 2682 [details] perl 5.8.0-r1 - Threads enabled Threading is a stable feature as of perl 5.8.0. Altered the perl-5.8.0 ebuild I put together to include threading support. Compiled and test successfully on a i686, gcc 2.95.3
Working out bugs in the ebuild. Nohup'd a merge and noticed some errors/problems around the point that installhtml is invoked.
I also noticed that the -march flag was NOT being passed to gcc on the second round of compiling [right after the test suite].
Oh yes, one additional thing: I'm getting a "missing separator" error during the manpage install phase.
There appear to be many, many problems with this ebuild (both versions). Tested with the 5.6.1 ebuild and it had the same issues. Will be rewriting the ebuild from scratch to avoid using the bad bits again.
Sorry, I discovered YA problem.Since I was having trouble with e-building the modules, I decided to use CPAN instead. Unfortunately, it appears that the MANPATHPREFIX(?) set in MakeMaker points to /var/.../portage/perl-5.../man3pm/ instead of the prefix. I manually set the prefix in CPAN, and it seemed to work. However, the man package needs to be pached to recognize /usr/share/man/man3pm as a valid man directory. One other thing I noticed is that perl-5.8.0 should "inject" ebuilds for the modules which came with it, but not with perl-5.6.1 [so as not to confuse people]. Also, I tried out your new perl-module eclass, it works great!!! Thanks!
5.8.0-r1 will be masked this evening. -Dusethreads has been added, the ebuild itself has been cleaned up (but I need testers to tell me it isn't too cleaned), and there have been a few tweaks made to the ebuild itself that should make it a better install. This is not the same -r1 that was posted to this bug, but a complete rewrite of the ebuild. I've noticed that when trying to build applications against the new perl, the builds fail. It appears that some apps may not be compatible with the new libperl.so, so I wanted to throw that out there as a warning. Thanks all, Mike
-r1 is now masked in portage. It is not the same -r1 that I posted to this page originally, this is a complete rewrite of the ebuild.
You said "I've noticed that when trying to build applications...It appears that some apps may not be compatible with the new libperl.so". I was under the impression that there were binary incompatibilities, but module source could be rebuilt. Can you give some examples of which apps failed to build properly? I noticed some ebuilds have the perl directory hardcoded to a specific version, perhaps that might be the cause of some headaches? I'll check on CPAN to see if the ebuilds for certain modules are out of date. I noticed a few which fit into this category. Then I'll update the ebuilds in a new bugreport.
Perhaps I'm misreading this then.I do know on my perl 5.8.0 box, apps that I try to compile that take advantage of use=perl will no longer compile when before they did. I have not tested this in full yet, though. ~snip~ B<Perl 5.8 is not binary compatible with earlier releases of Perl.> B<You have to recompile your XS modules.> (Pure Perl modules should continue to work.) The major reason for the discontinuity is the new IO architecture called PerlIO. PerlIO is the default configuration because without it many new features of Perl 5.8 cannot be used. In other words: you just have to recompile your modules containing XS code, sorry about that. In future releases of Perl, non-PerlIO aware XS modules may become completely unsupported. This shouldn't be too difficult for module authors, however: PerlIO has been designed as a drop-in replacement (at the source code level) for the stdio interface. ~snip~ AIX Dynaloading The AIX dynaloading now uses in AIX releases 4.3 and newer the native dlopen interface of AIX instead of the old emulated interface. This change will probably break backward compatibility with compiled modules. The change was made to make Perl more compliant with other applications like mod_perl which are using the AIX native interface. ~snip~ http://dev.perl.org/perl5/news/2002/07/18/580ann/perldelta.podb
The last one, I promise. While trying to install the URI ebuild, I noticed that the build is unable to sed perllocal.pod in the temporary install directory. The offshoot of this is that it installs it's own perllocal.pod, clobbering the one which was originally there. This file, as you are undoubtably aware, is very important because it tracks every install done my MakeMaker. It is not supposed to be overwritten, rather it is supposed to be appended with the appropriate information. Since the URI ebuild uses the perl-module eclass to do everything, I have to assume this is a bug in the eclass. These are the files potentially affected: /usr/lib/perl5/5.8.0/i686-linux-thread-multi/perllocal.pod /usr/lib/perl5/site_perl/5.8.0/i686-linux-thread-multi/perllocal.pod --------------------------------------------------------------------------------- As for the article, I interpreted this to mean all that you should have to do is rebuild any modules which contained c code [a.k.a. XS modules]: "...In other words: you just have to recompile your modules containing XS code, sorry about that." But this shouldn't affect someone who is starting from scratch and building everything from source, should it? As for those apps, I can't say for sure...
Nicholas, I just tried to recompile a module that uses c code and it fails (Crypt::OpenSSL::RSA) - the problem is that the C code doesn't know how to talk to the new perl. The problem is with the c code that comes with the module. Sorry, Mike
Just for the record, so others know what we've discovered in our discussion outside of the buglist and have a method to tide themselves over... The problems Mike was experiencing was due to a guarded char statement in /usr/include/openssl/des.h being triggered when it wasn't supposed to. Basically, on line 192 of said file [which precedes the offending statement], there is a guard which states "#if !defined(PERL5)...". Well, for some reason, perl-5.8.0 is no longer defining PERL5 when compiling XS modules. Therefore the guard returns true and the char statement is defined. To get around this, you must pass -DPERL5 to the compiler during the module build phase. There are many ways in which this can be done, but to keep it simple, edit your perl-module eclass and add the following (omitting the outer quotes): Change at line 30: "PREFIX=${D}/usr" to "PREFIX={D}/usr \" Add a new line right after that which is "DEFINE="${DEFINE} -DPERL5"" I must stress 2 things: 1)This change will get wiped out everytime you rsync. 2)This may not be the best solution as some perl modules *may* actually use the DEFINE macro and my attempts to inherit the existing DEFINE value may not work. That being said, Mike is working on an ebuild which should fix this problem by including this define in the link line without the need for defining that macro. So, to tide you over until the new ebuild is released, try doing this when compiling any Crypto modules.
It looks like the solution is either going to need to be in the perl ebuild itself, or a patch option for openssl. This problem shows up with perl modules, but it shows up elsewhere also. For instance, I just emerged vim with perl 5.8.0, no problem. But both xchat and gaim use openssl with perl, and both fail at the same part as the openssl perl modules. Ideally, the fix needs to be in the perl ebuild, since that would be the common point. I'm working on it though :)
The fix will be in the Config.pm file - it's an addition to the cc and ccp flags for compiling. Working on it now, but it works :)
Created attachment 3007 [details] -r2 Wanted to pass this through here before I attempted to commit it to CVS. Didn't want to get caught with mistakes again namely. This revision corrects the cc and ccp flags in Config.pm, allowing the -DPERL5 to be included in gcc flags used during perl integration with c code (modules or apps). I also added a sym link from $PARCH-thread-multi to $PARCH - namely because it looks like there's at least a few modules that don't like the new naming schema that perl uses. I've test installed a few apps that were failing before (gaim, xchat, and vim), as well as a few modules that weren't working right, and all looks good on my end. But that's on my end. Please send feedback if you can before I put this in the tree (still masked, of course).
Here's another major annoyance fix for perl-5.8.0 (cross platform). Apparently gtk-perl is /not/ compiling properly. However, once this fix is done, it builds without a hitch: http://mail.gnome.org/archives/gtk-perl-list/2002-July/msg00014.html
Created attachment 3360 [details] nohup.out Debug build log requested by Mike.
*** Bug 6799 has been marked as a duplicate of this bug. ***
perl 5.8 is in portage now, ~arch masked until confirmed as good for all platforms. Threading is not enabled by default, but is available if you pass it USE=threads (or add it to your make.conf, I suppose). Threading does cause problems for apps that can't handle a threaded perl. Since perl 5.8 is now out of package.mask and into the main stream, this bug can be closed.
