Hi, rangerpb said, that stage building fails on libstdc++. regardsless of 2005.0 or 2005.1. I've just confirmed that behaviour using default-linux/ppc64/dev/2005.1/970/pmac profile. Here comes the output: /var/tmp/portage/libstdc++-v3-3.3.4/work/build/gcc/xgcc -B/var/tmp/portage/libstdc++-v3-3.3.4/work/build/gcc/ -B/usr/powerpc64-unknown-linux-gnu/bin/ -B/usr/powerpc64-unknown-linux-gnu/lib/ -isystem /usr/powerpc64-unknown-linux-gnu/include -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -isystem ./include -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -shared -nodefaultlibs -Wl,--soname=libgcc_s.so.1 -Wl,--version-script=libgcc/./libgcc.map -o libgcc_s.so.1 libgcc/./_muldi3.o libgcc/./_negdi2.o libgcc/./_lshrdi3.o libgcc/./_ashldi3.o libgcc/./_ashrdi3.o libgcc/./_ffsdi2.o libgcc/./_clz.o libgcc/./_cmpdi2.o libgcc/./_ucmpdi2.o libgcc/./_floatdidf.o libgcc/./_floatdisf.o libgcc/./_fixunsdfsi.o libgcc/./_fixunssfsi.o libgcc/./_fixunsdfdi.o libgcc/./_fixdfdi.o libgcc/./_fixunssfdi.o libgcc/./_fixsfdi.o libgcc/./_fixxfdi.o libgcc/./_fixunsxfdi.o libgcc/./_floatdixf.o libgcc/./_fixunsxfsi.o libgcc/./_fixtfdi.o libgcc/./_fixunstfdi.o libgcc/./_floatditf.o libgcc/./_clear_cache.o libgcc/./_trampoline.o libgcc/./__main.o libgcc/./_exit.o libgcc/./_absvsi2.o libgcc/./_absvdi2.o libgcc/./_addvsi3.o libgcc/./_addvdi3.o libgcc/./_subvsi3.o libgcc/./_subvdi3.o libgcc/./_mulvsi3.o libgcc/./_mulvdi3.o libgcc/./_negvsi2.o libgcc/./_negvdi2.o libgcc/./_ctors.o libgcc/./_divdi3.o libgcc/./_moddi3.o libgcc/./_udivdi3.o libgcc/./_umoddi3.o libgcc/./_udiv_w_sdiv.o libgcc/./_udivmoddi4.o libgcc/./_pack_sf.o libgcc/./_unpack_sf.o libgcc/./_addsub_sf.o libgcc/./_mul_sf.o libgcc/./_div_sf.o libgcc/./_fpcmp_parts_sf.o libgcc/./_compare_sf.o libgcc/./_eq_sf.o libgcc/./_ne_sf.o libgcc/./_gt_sf.o libgcc/./_ge_sf.o libgcc/./_lt_sf.o libgcc/./_le_sf.o libgcc/./_unord_sf.o libgcc/./_si_to_sf.o libgcc/./_sf_to_si.o libgcc/./_negate_sf.o libgcc/./_make_sf.o libgcc/./_sf_to_df.o libgcc/./_sf_to_tf.o libgcc/./_thenan_sf.o libgcc/./_sf_to_usi.o libgcc/./_usi_to_sf.o libgcc/./_pack_df.o libgcc/./_unpack_df.o libgcc/./_addsub_df.o libgcc/./_mul_df.o libgcc/./_div_df.o libgcc/./_fpcmp_parts_df.o libgcc/./_compare_df.o libgcc/./_eq_df.o libgcc/./_ne_df.o libgcc/./_gt_df.o libgcc/./_ge_df.o libgcc/./_lt_df.o libgcc/./_le_df.o libgcc/./_unord_df.o libgcc/./_si_to_df.o libgcc/./_df_to_si.o libgcc/./_negate_df.o libgcc/./_make_df.o libgcc/./_df_to_sf.o libgcc/./_df_to_tf.o libgcc/./_thenan_df.o libgcc/./_df_to_usi.o libgcc/./_usi_to_df.o libgcc/./ppc64-fp.o libgcc/./unwind-dw2.o libgcc/./unwind-dw2-fde-glibc.o libgcc/./unwind-sjlj.o libgcc/./unwind-c.o -lc && rm -f libgcc_s.so && ln -s libgcc_s.so.1 libgcc_s.so /usr/powerpc64-unknown-linux-gnu/bin/ld: crti.o: No such file: No such file or directory collect2: ld returned 1 exit status make[2]: *** [libgcc_s.so] Error 1 make[2]: *** Waiting for unfinished jobs.... if [ -f ranlib ] || ( [ powerpc64-unknown-linux-gnu = powerpc64-unknown-linux-gnu ] && [ -f /usr/bin/ranlib -o -f /bin/ranlib ] ) ; then \ ranlib ./libgcc.a ; \ else true; fi; make[2]: *** Waiting for unfinished jobs.... make[2]: Leaving directory `/var/tmp/portage/libstdc++-v3-3.3.4/work/build/gcc' make[1]: *** [stmp-multilib] Error 2 make[1]: Leaving directory `/var/tmp/portage/libstdc++-v3-3.3.4/work/build/gcc' make: *** [all-gcc] Error 2 !!! ERROR: sys-libs/libstdc++-v3-3.3.4 failed. !!! Function src_compile, Line 232, Exitcode 2 !!! (no error message) !!! If you need support, post the topmost build error, NOT this status message. Regards, Markus
btw: libstdc++-v3-3.3.4 builds fine, when not doing a stage build (normal emerge)
As corsair stated, I am also seeing this problem exactly as his output is too. With the encouragement of those on irc, I also tried the following: Using the same stage1 built from catalyst, I unpacked, and chrooted to it; once in, I ran gcc-config and fix_libtool_files.sh hoping it would fix the linking problem, but alas it didn't.
I masked sys-libs/libstdc++-v3-3.3.4 and tried with libstdc++-v3-3.3.3-r1 but it still failed.
Ok, here's what I know and speculate is going on. Talked with the releng and amd64 as well, as amd64 saw this problem too. It looks like the move to multilib is the culprit here. With only the ppc64 arch available, a symlink between usr/lib and usr/lib64 used to get created in baselayout. that no longer is being done. therefore, parts of the toolchain are being installed in each of the above lib directories, so when compilation of things like libstdc++ occurs, it fails. For example, libcrti.o is actually in the stage, just not in the directory its looking in. kugelfang, of amd64, believes this is all controlled by the profiles. He gave me a bunch of variables to add to our profile to fix the problem. I had him check it and it still failed. Since we lack a 2005.1 profile in portage, I used dev/2005.1/power5 to test. My profile looks like: ARCH="ppc64" DEFAULT_ABI="ppc64" MULTILIB_ABIS="ppc64" CFLAGS_ppc64="-m64 -O2 -pipe -mtune=power5 -mcpu=power5" LDFLAGS_ppc64="-m elf_ppc64" #CHOST_amd64="x86_64-pc-linux-gnu" CHOST="powerpc64-unknown-linux-gnu" CDEFINE_ppc64="__ppc64__" LIBDIR_ppc64="lib64" SYMLINK_LIB="yes" #CFLAGS="-O2 -pipe -mtune=power5 -mcpu=power5" CXXFLAGS=${CFLAGS} ACCEPT_KEYWORDS="ppc64" STAGE1_USE="unicode" GRP_STAGE23_USE="unicode ipv6 pam tcpd readline nls ssl gpm perl python berkdb ncurses" USE="unicode pam berkdb bitmap-fonts emboss gif jpeg nls ncurses perl png python readline ssl tcpd truetype truetype-fonts type1-fonts zlib ibm nptl" FEATURES="autoconfig sandbox sfperms" As I said, it still failed. So either we dont have the right stuff in the profile yet, or maybe there is some packages we need to unmask, or maybe there is some arch foo in the ebuilds. Things we should prolly do to understand whats going on more is: * examine the amd64 profiles * understand what the multilib eclass is doing * define a 2005.1 generic ppc64 profile and get it into portage
I created the multilib profile which makes only 64-bit environment. It operates like baselayout-1.9.4-r6 by using this profile. (/lib becomes the Symbolic Link of /lib64. also the lib directory of /usr...) When it is used, it succeeds in creation of stages. ranger, Would you try the following profiles ? /usr/portage/default-linux/ppc64/dev/2005.1/no-multilib
Created attachment 62167 [details, diff] patch for profiles/default-linux/packages.build This patch is required, if you hope to use stage3 of 2005.0 release when you make new stage1. It avoids the problem by which dev-python/python-fchksum is installed in /usr/lib. [NOTE] This patch is unnecessary when using stage3 made using the no-multilib profile which I made. It is because multilib support of dev-lang/python functions and a problem is fixed.
I can provide more information if required but in trying to build the stage, I got a the following: checking size of long double... configure: error: cannot compute sizeof (long do uble), 77 See `config.log' for more details. !!! ERROR: sys-libs/glibc-2.3.4.20041102-r1 failed. !!! Function glibc_do_configure, Line 709, Exitcode 1 !!! failed to configure glibc !!! If you need support, post the topmost build error, NOT this status message. I think that was a known, common problem but cannot remember the fix. Anyone or do you need more info?
The message seems to be the error which I often looked at, when I add full-multilib (32/64bit) support. I think that the error that libc cannot be linked is probably outputted to config.log. Please try the following. 1. Please make the snapshot of the current Portage tree. 2. And please download stage3-ppc64-20050628.tar.bz2 [2] and make stage1. This stage3 does not need the above-mentioned patch. If the problem is unsolvable also by the above-mentioned way, please tell me the following thing. 1. Which profile did you use ? 2. Does this problem occur, while making which stage ? 3. What was the configure option of glibc ? The example of my environment is the following [1] . 4. If possible, please attach config.log which configure of glibc outputted. Thanks. [1] <snip> >>> Source unpacked. * Configuring GLIBC for linuxthreads with: --disable-nls --disable-dev-erandom --with-tls --without-__thread --enable-add-ons=linuxthreads,c_stubs,libidn --enable-kernel=2.4.1 --without-cvs --enable-bind-now --build=powerpc64-unknown-linux-gnu --host=powerpc64-unknown-linux-gnu --disable-profile --without-gd --with-headers=/tmp/stage1root//usr/include --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --libexecdir=/usr/lib/misc checking build system type... powerpc64-unknown-linux-gnu checking host system type... powerpc64-unknown-linux-gnu <snip> [2] http://dev.gentoo.org/~nigoro/ppc64/stage3-ppc64-20050628.tar.bz2
Created attachment 62227 [details] FYI, my stage1_template.spec
Ok, was able to build a stage1 and stage2. Stage3 failed on dev-python/python-fchksum-1.7.1 . It looks like maybe sandbox errors. >> Unpacking source... >>> Unpacking python-fchksum-1.7.1.tar.gz to /var/tmp/portage/python-fchksum-1.7.1/work >>> Source unpacked. ACCESS DENIED unlink: /usr/lib64/python2.3/distutils/__init__.pyc ACCESS DENIED open_wr: /usr/lib64/python2.3/distutils/__init__.pyc ACCESS DENIED unlink: /usr/lib64/python2.3/distutils/core.pyc ACCESS DENIED open_wr: /usr/lib64/python2.3/distutils/core.pyc ACCESS DENIED unlink: /usr/lib64/python2.3/distutils/debug.pyc ACCESS DENIED open_wr: /usr/lib64/python2.3/distutils/debug.pyc and so forth. --------------------------- ACCESS VIOLATION SUMMARY --------------------------- LOG FILE = "/tmp/sandbox-dev-python_-_python-fchksum-1.7.1-6263.log" unlink: /usr/lib64/python2.3/distutils/__init__.pyc open_wr: /usr/lib64/python2.3/distutils/__init__.pyc unlink: /usr/lib64/python2.3/distutils/core.pyc open_wr: /usr/lib64/python2.3/distutils/core.pyc unlink: /usr/lib64/python2.3/distutils/debug.pyc and so forth...
(In reply to comment #10) > Ok, was able to build a stage1 and stage2. Stage3 failed on > dev-python/python-fchksum-1.7.1 . It looks like maybe sandbox errors. I added the code which investigates the profile of AMD64 and avoids this problem to no-multilib profile. And, I have noticed that the code which I added is unnecessary on the environment where portage-2.0.51.22-r1 and sandbox-1.2.9 were installed. It seems that the code which avoids this problem is contained in sandbox-1.2.9. [memo] This patch is already merged into the Portage tree.
Created attachment 62335 [details, diff] FYI, patch for profile.bashrc
seems to be fixed
