Bugzilla Bug 58931

I didn't get too much response from the mailing list on this, so I've decided
to post a bug about this.

Below is the text from my mailing list post:

There were two major problems with the ebuilds preventing it from building:
1. The slotting system incorrectly assumed that we were dealing with
.so files, so that needed to be fixed.  I used some global variables
to get this fixed.  It looks fine on ppc as well, so I think it's okay.
2. As far as I can tell, the -soname patch basically adds versioning
to .so libraries.  With dylib, we already get versioning, so as long
as programs that depend on libperl depend on 5.8.0, we should be okay
to just drop that patch for OSX.  If any one needs more explanation,
or has concerns that this is completely wrong please let me know.

So it builds now, but there are a few issues remaining:
1. There are a few errors at the end of the ebuild, it looks like
preplib and preplib.so need to have some OSX modifications, probably
just using ranlib instead of ldconfig, but I haven't looked at it yet.
2. Perl installs to /usr, overwriting the apple install.  I didn't
even notice at first, so there's no apparent ill effects, yet I'm
still a little wary about just going ahead and doing this.  Does
anyone have any suggestions or comments on this?
3. It would be pretty easy to change the behaviour of #2 to maybe
install in /usr/local, but we would have to adapt to this.  I'm really
not sure what the "right" answer is.
4. Perl modules still don't work quite right, they get installed into
/usr instead of / like perl is expecting.  I haven't had a chance to
look at this yet.

Thanks!

Created an attachment (id=36479) [edit]
Fixes libperl on OSX

Created an attachment (id=36480) [edit]
Fixes perl on OSX

*** Bug 62334 has been marked as a duplicate of this bug. ***

Created an attachment (id=41338) [edit]
List of files blocking the merge

Created an attachment (id=41339) [edit]
Unified diff for libperl

Created an attachment (id=41340) [edit]
Unified diff for perl

This depends on bug 67162. Will take a look at it when 67162 has gotten
somewhere. Until then, this 
bug should remain frozen.

Reopening to get this in the tree for Darwin and the progressive profiles.

Created an attachment (id=65240) [edit]
Provides the correct lib ending for .so or .dylib

Created an attachment (id=65241) [edit]
Fix for latest libperl using the get_libname patch

Created an attachment (id=65242) [edit]
Fix for latest perl using the get_libname patch

Created an attachment (id=65257) [edit]
Fix for latest libperl using the get_libname patch

add userland conditional and fix install_name

Created an attachment (id=65259) [edit]
65242: Fix for latest perl using the get_libname patch

minor fixes

(In reply to comment #13)
> Created an attachment (id=65259) [edit]
> 65242: Fix for latest perl using the get_libname patch
> 
> minor fixes

Just not sure that this block is right (the rest of it looks good)

Shouldn't this be an elseif (elsif? whatever, you know what I mean :) instead of
if...else [ if ...else...]

@@ -139,10 +139,13 @@
 
 	if [[ ${KERNEL} == "FreeBSD" && "${ELIBC}" = "FreeBSD" ]]; then
 		osname="freebsd"
+	else if [[ ${USERLAND} == "Darwin" ]]; then
+		osname="darwin"
 	else
 		# Default setting
 		osname="linux"
 	fi
+	fi
 

Created an attachment (id=65463) [edit]
Fix for latest perl using the get_libname patch

changed extra if block 

Created an attachment (id=65464) [edit]
eutils patch to provide the correct lib suffix for .so or .dylib

s/ppc-macos/userland_Darwin

(From update of attachment 65464 [edit])
inCVS multilib.eclass

I have working ebuilds for both libperl(gotcha:) and perl based on the last
libname patch, but one question - userland_darwin isn't a use flag...

its a use-expanded variable set in in the profiles along with kernel and elibc.
it should be userland_Darwin 
(uppercase `D`), GNU systems have userland_gnu, elibc_glibc

/usr/portage/profiles $ grep -risl userland_dar *
/usr/portage/profiles $

hence my confusion :) But if you all say its cool, I'll go with it. 

% grep -r USERLAND . 
./make.defaults:USE_EXPAND="LINGUAS USERLAND KERNEL ELIBC"
./make.defaults:USERLAND="Darwin"

Yeah, portage adds the `userland_` part of it. You will still get some QA warnings as the use-expanded 
vars haven't been silenced in portage quite yet.

patch(variation i think) applied to libperl and perl. eat it up yum.

${coredir}/libperl$(get_libname).${PERLSLOT}

Stuff like that won't work, as dylibs need the version to come before the suffix, libfoo.1.dylib as opposed 
to the ELF convention of libfoo.so.1

That was the motivation for the get_libname function, to handle that transparently, so the version should 
be passed to the function as well:
  LIBPERL="libperl$(get_libname ${PERLSLOT}.${SHORT_PV})"

Also need to skip the regexp-nossp.patch for Darwin/OS X. 

Created an attachment (id=65764) [edit]
libperl-5.8.7.ebuild.patch

Almost there...

Created an attachment (id=65765) [edit]
perl-5.8.7.ebuild.patch

patches posted

working great. Thanks mcummings!