Created attachment 301685 [details]
dev-lang/perl build failure log
This causes dev-lang/perl to fail during bootstrapping.
It looks like what it wants is $EPREFIX/lib/libbz2.1.dylib, but the only libb2* file in $EPREFIX/usr/lib is libbz2.dylib.
Created attachment 301687 [details]
Summary log from install
It looks like the issue started with app-arch/bzip2's postinst phase.
Created attachment 301689 [details]
Script used to install Gentoo Prefix
I used a script to do the installation. The install command was:
env MAKEOPTS=-j3 EPREFIX=/tmp/test CHOST=x86_64-apple-darwin10 ./prefix-install.sh
Created attachment 301691 [details]
Install emerge.log file
The script was on "emerge --oneshot sys-apps/grep" according to the emerge.log file.
I think the /usr/local thing is scary to start with
gen_usr_ldscript: unable to read install_name from libbz2.dylib
indicates you do something in the wrong order (scanmacho isn't there, pax-utils not installed)
(In reply to comment #4)
> I think the /usr/local thing is scary to start with
> gen_usr_ldscript: unable to read install_name from libbz2.dylib
> indicates you do something in the wrong order (scanmacho isn't there, pax-utils
> not installed)
The Solaris bootstrap guide puts "emerge --oneshot pax-utils" after "emerge --oneshot sys-apps/grep" while it seems that the Mac OS X guide has the order reversed.
I will experiment to see if changing the other causes regressions on other platforms. Also, I am adding where I currently have the latest version of my script hosted to the bug's URL field.
I see. I think it might actually work to have the OSX order on Solaris as well. If so, that should be fixed.
Created attachment 304497 [details]
app-misc/pax-utils-0.2.1 failure from Mac OS X order
Bug #407217 delayed regression tests on sparc64-solaris. I have now worked around it and unfortunately, app-misc/pax-utils-0.2.1 fails to build with the Mac OS X location. However, the Mac OS X position works for both ppc64-linux (Fedora 16) and amd64-linux (Gentoo Linux Stable).
When I have more time, I will try to see if there is an intermediate position that makes all platforms happy.
ah, the solaris problem is most likely because you need a fix-included version of stdbool.h that gcc creates, and you didn't emerge it yet
I moved app-misc/pax-utils so that it is installed immediately before sys-apps/grep. This resolves the original Mac OS X issue with the Solaris order and the Solaris issue with the Mac OS X order.
This bug seems to have reappeared. I am seeing this on the 20120808 tree with the new stage based bootstrap script as well as the older one and a latest_tree from 20120802 on Mountain Lion as well as Snow Leopard. srcerer from #gentoo-prefix has tried with the original script and 20120630 tree and it also happens there even though it clearly didn't happen to me with that setup 10 days ago. Something must have changed in the guide or someplace that causes this?
It happens consistently in the following step from the OS X guide:
env FEATURES="-collision-protect" emerge --oneshot sys-apps/portage
A full log is here:
Seems something fails not just for bzip but also other packages...
pax-utils isn't installed at that point, but it's not mentioned in the entire guide. Shouldn't it be installed at that point?
I've run a bootstrap on ML using the solaris guide and figured out that you will run into endless trouble at the last 'emerge -e system step' because pax-utils seems to be emerged too late.
A previous revision emerged it directly after the first bash and now it's been completely omitted from the mac guide and the solaris guide emerges it basically as the last thing before portage which breaks things horribly down the line.
I'm running a new bootstrap over night now to test if it works with pax-utils after bash like it used to be.
might indeed be clever to move pax-utils up, or try to compile it at that stage, but don't die on its failure (stage2/3).
Seems we've fixed this particular problem at some point.