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 attachment 36479 [details, diff] Fixes libperl on OSX
Created attachment 36480 [details, diff] Fixes perl on OSX
*** Bug 62334 has been marked as a duplicate of this bug. ***
Created attachment 41338 [details] List of files blocking the merge
Created attachment 41339 [details, diff] Unified diff for libperl
Created attachment 41340 [details, diff] 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 attachment 65240 [details, diff] Provides the correct lib ending for .so or .dylib
Created attachment 65241 [details, diff] Fix for latest libperl using the get_libname patch
Created attachment 65242 [details, diff] Fix for latest perl using the get_libname patch
Created attachment 65257 [details, diff] Fix for latest libperl using the get_libname patch add userland conditional and fix install_name
Created attachment 65259 [details, diff] 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 attachment 65463 [details, diff] Fix for latest perl using the get_libname patch changed extra if block
Created attachment 65464 [details, diff] eutils patch to provide the correct lib suffix for .so or .dylib s/ppc-macos/userland_Darwin
Comment on attachment 65464 [details, diff] eutils patch to provide the correct lib suffix for .so or .dylib 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 attachment 65764 [details, diff] libperl-5.8.7.ebuild.patch Almost there...
Created attachment 65765 [details, diff] perl-5.8.7.ebuild.patch
patches posted
working great. Thanks mcummings!
