Summary: | sys-apps/sandbox-2.6-r1 - configure: error: dont be a Kumba, building a libsandbox.a is stupid | ||
---|---|---|---|
Product: | Portage Development | Reporter: | David Carlos Manuelda <StormByte> |
Component: | Sandbox | Assignee: | Sandbox Maintainers <sandbox> |
Status: | RESOLVED INVALID | ||
Severity: | normal | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
Build log
emerge --info config.log make.conf environment file |
Description
David Carlos Manuelda
2013-08-25 17:34:59 UTC
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. |