I unpacked a stage3 inside a chroot (as well as portage), emerged gcc-4.8.1 and trying to test also glibc-2.18 (I know it is missing keywork, I think it is not related) When doing emerge -e world I realized sandbox fails to build, because it is trying to compile itself as a static lib and it says in configure stage: configure: error: dont be a Kumba, building a libsandbox.a is stupid I'll attach both, emerge --info and full buildlog Reproducible: Always
Created attachment 356988 [details] Build log
Created attachment 356990 [details] emerge --info
!!! Please attach the following file when seeking support: !!! /var/tmp/portage/sys-apps/sandbox-2.6-r1/work/build-x86/config.log Please attach that.
Created attachment 357054 [details] config.log Attached config.log as requested by dev.
Note: By clean stage3 I mean no other software installed yet, and only gcc, glibc and linux-headers upgraded, but tweaked /etc/portage/make.conf (by copying the one that works in my current install), but I think it can be seen in emerge --info output.
More tests: I am doing more tests to try to track down the culprit. All these tests are done by unpacking stage3, binding /usr/portage from current running gentoo, rbinding /sys /dev and mounted proc. Entered chroot and env-update and source /etc/profile was entered: Compile/install status: - Just unpack (no upgrades, no config files touched): OK - Just unpack (copying my current make.conf (attached): FAIL So the culprit seems only to do the changes in /etc/portage/make.conf without being related neither to gcc, neither to glibc nor any other software, just config file.
Created attachment 357056 [details] make.conf /etc/portage/make.conf
Note2: The same make.conf file is the one I use in my current running gentoo, and there, it compiles with no issues, so only seems to affect when you are starting from a fresh stage3
Found the culprit line on my make.conf, but only in this scenario (again, this is working on a full running Gentoo) Commenting out #LDFLAGS_x86="${LDFLAGS_x86} ${LDFLAGS}" line, makes sandbox compile in early times (otherwise I guess that I would need to update the full system in order to make it compile again (?))
It would be nice to see the environment file, too, since it isn't obvious where --enable-static is coming from (unless enable_static=foo is set in the environment).
Created attachment 357182 [details] environment file /var/tmp/portage/sys-apps/sandbox-2.6-r1/temp/environment file
I must say, that I can reproduce this only when using a downloaded version of stage3, because with a full updated system, I can not reproduce anymore, but it is still annoying to don't know why it happens and forcing update before rebuilding all as I usually do.
this is why it's failing: configure:9448: checking whether the x86_64-pc-linux-gnu-gcc -m32 -O2 -pipe -march=core2 -msse4.1 linker (x86_64-pc-linux-gnu-ld -m elf_i386 -Wl,-O1 -Wl,--as-needed -Wl,--sort-common) supports shared libraries configure:10601: result: no how do you reproduce ? unpack a stage3 and try to build sandbox ?
Sorry for the late response. I could reproduce when I posted the bug, by following installation handbook until the chroot part (yes, that include a stage3 unpacking), after that, I usually emerge sync, emerge gcc 4.8.2 and latest glibc (don't know if the latter is relevant). Then, update system prior to install anything more (without leaving chroot environment). I guess you can simply try emerge -1 sandbox directly after all that. It has passed some time until the last time I checked though, so I'll retry with a more detailed procedure in a few days. Finally, I want to remark that, on running system I can not reproduce it, it seem only to happen only in chroot environment.
And another remark is the line LDFLAGS_x86="${LDFLAGS_x86} ${LDFLAGS}" from attached make.conf... But it is strange because on running system with same line do not trigger the fail.
It is probably caused by setting CFLAGS_X86 and CXXFLAGS_x86 in make.conf, as it also created weird bugs in other places, I can't reproduce anymore without that flags, which I was advised anyway not to set as their purpose is internal.
