Summary: | sys-libs/uclibc-0.9.30.1: packages fail to compile with "Can't modify application's text section; use the GCC option -fPIE for position-independent executables" | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Tom Lloyd <napalmllama> |
Component: | [OLD] Core system | Assignee: | Embedded Gentoo Team <embedded> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | blueness |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Tom Lloyd
2009-03-14 11:38:54 UTC
OK, it isn't just compilations: sed says it, too: muttley ~ # sed Can't modify application's text section; use the GCC option -fPIE for position-independent executables. Of course I can't recompile it to find out if it's just badly linked because it's one of the things that doesn't compile... Hmm, do you think that maybe some of these configure scripts use sed and that's the root of the problem? I will cross-compile sed with the new uclibc and qpkg it and see if that works. OK, this is interesting. I cross-compiled sed on my x86 box and put it in /usr/local/bin, and it worked fine. I then recompiled sed natively, (it seems that the dodgy binary was the thing preventing the compilation from going ahead), but the result of the native compilation still exhibits the same problem. When a binary is compiled with the exact same toolchain, why would the cross-compiled one work, while the natively compiled one doesn't? I encountered a similar (same?) error when doing emerge -e world on i386 with uclibc-0.9.30.1 where gzip behaved as sed in comment #1. The workaround was to statically link it: USE="static" emerge gzip. Oh hey, this is still open. I think I solved it ages ago. It was binaries being called by their full path causing the difficulties - things like /usr/powerpc-gentoo-linux-uclibc/binutils-bin/2.18/ar. I don't remember quite how I rooted out all the bad binaries, (I don't think revdep-rebuild helped), but I seem to recall temporarily replacing them with cross-compiled versions until everythiong worked properly, then recompiling the packages that provided them so that everything was native again. (The last step was needed because my cross-compiler doesn't make hardened binaries as far as I know.) I guess for the "rooting-out" process I must have looked at the unpacked Makefile (Ctrl-Z the emerge process and look at the files in /var/tmp/portage/) and emulated its action line-by-line, editing scripts to make them more verbose, until I traced the error message back to a specific command. Or something. I know I've done that sort of thing before :P To the Gentoo bugsquashers: Should I close this sort of bug myself, or always leave it for one of you to do? Closing it ... finally. |