| Summary: | sys-libs/ss and sys-fs/e2fsprogs should honour ${ROOT} | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Ryan Tandy <ryan> |
| Component: | New packages | Assignee: | Gentoo's Team for Core System packages <base-system> |
| Status: | RESOLVED INVALID | ||
| Severity: | normal | CC: | alsroot, bertrand, codehero, Jochen.Trumpf, john.holland, sean.harmer |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
Ryan, if these files aren't binary (ie. when adding ${ROOT} fixes that reliably and even for real cross-compiles), fix is trivial.
However, if the build system requires already-generated files (libraries, executables,...) later, this would be tricky to implement.
ROOT is the merge target, not the build target. make the libraries available in your compiler's sysroot and the linker scripts will locate things properly. *** Bug 217118 has been marked as a duplicate of this bug. *** *** Bug 220023 has been marked as a duplicate of this bug. *** Ryan's fix worked for me in ss, com_err and e2fs, go with it. (In reply to comment #2) > ROOT is the merge target, not the build target. make the libraries available > in your compiler's sysroot and the linker scripts will locate things > properly. SpanKY: I think the rationale behind Ryan's suggestion is that e2fsprogs RDEPENDs on ss and com_err, hence it is reasonable to assume that they have been merged into the same merge target previously. What you are suggesting works as well, but only as a temporary hack *) that needs to be reverted manually after xmerging e2fsprogs, or the host system will break. *) e.g. symlinking the correct libraries in /usr/lib after moving the host system's versions out of the way no. you're redefining ROOT incorrectly. while it may work much of the time, it's still wrong and not what ROOT is for. it will also break configurations where ROOT is being used correctly. your statement about /usr/lib is also incorrect. all Gentoo cross-compilers as sysroot based which means that "/usr/lib" in a linker script is not actually pointing to /usr/lib, it's pointing to the sysroot/usr/lib. (In reply to comment #7) > all Gentoo cross-compilers as > sysroot based which means that "/usr/lib" in a linker script is not actually > pointing to /usr/lib, it's pointing to the sysroot/usr/lib. I understand that that's how it's supposed to work; for some reason, though, it still doesn't quite seem to be doing it. GEN_LIB libss.a GEN_ELF_SOLIB libss.so.2.0 /usr/libexec/gcc/armv5tejl-softfloat-linux-gnueabi/ld: skipping incompatible /usr/lib/libcom_err.so when searching for /usr/lib/libcom_err.so /usr/libexec/gcc/armv5tejl-softfloat-linux-gnueabi/ld: cannot find /usr/lib/libcom_err.so collect2: ld returned 1 exit status make: *** [libss.so.2.0] Error 1 But I installed com_err to the correct sysroot, so the library exists there: -rwxr-xr-x 1 root root 331 2008-05-31 00:49 /usr/armv5tejl-softfloat-linux-gnueabi/usr/lib/libcom_err.so* What am I still not getting? i think i see what you mean, but did you cheat and just create the linker script in that directory ? or did you actually do: ROOT=/usr/armv5tejl-softfloat-linux-gnueabi emerge com_err ss (In reply to comment #9) > i think i see what you mean, but did you cheat and just create the linker > script in that directory ? or did you actually do: > ROOT=/usr/armv5tejl-softfloat-linux-gnueabi emerge com_err ss The emerge. Just had another look at this. The cause of the problem is definitely the echo "GROUP ( /usr/$(get_libdir)/libcom_err.so )" > lib/libcom_err.so etc. lines in the ebuild. I am cross compiling for an arm-softfloat-linux-gnu target and using (mostly) stable arm packages. This pulls in ss-1.40.6 and e2fsprogs-1.40.6. ss cross compiles and installs fine, e2fsprogs doesn't (fails with the error described here). On checking the ebuilds, I realized that ss-1.40.6 does not contain the fake lib stuff, while e2fsprogs-1.40.6 does. In later versions, both ebuilds have those lines. So, these lines do not work as expected. Another difference is that ss-1.40.6 sets LDCONFIG=/bin/true in a separate env_setup() section in the ebuild while e2fsprogs-1.40.6 sets LDCONFIG=: at the beginning of the src_compile() section. Not sure if this is relevant, but it leads to different LDCONFIG entries in the generated Makefiles (/bin/true vs. /sbin/ldconfig on my machine). Some other relevant(?) parameters on my system: cross-arm-softfloat-linux-gnu/binutils-2.18-r1 cross-arm-softfloat-linux-gnu/gcc-4.1.2 cross-arm-softfloat-linux-gnu/glibc-2.5-r4 cross-arm-softfloat-linux-gnu/linux-headers-2.6.23-r3 ARCH=arm CBUILD=i686-pc-linux-gnu CHOST=arm-softfloat-linux-gnu ROOT=/usr/arm-softfloat-linux-gnu SYSROOT=/usr/arm-softfloat-linux-gnu I am happy to run further tests on this if somebody tells me what to do. Further test done: let the emerge process die as described in this bug, then change into the directory where it occurs (for me this is /var/tmp/portage/sys-fs/e2fsprogs-1.40.6/work/e2fsprogs-1.40.6/lib/ext2fs/) Running make repeats the error /usr/libexec/gcc/arm-softfloat-linux-gnu/ld: skipping incompatible /usr/lib/libcom_err.so when searching for /usr/lib/libcom_err.so /usr/libexec/gcc/arm-softfloat-linux-gnu/ld: cannot find /usr/lib/libcom_err.so collect2: ld returned 1 exit status make: *** [libext2fs.so.2.4] Error 1 After removing the fake libs ../libcom_err.*, a rerun of make succeeds. > your statement about /usr/lib is also incorrect. all Gentoo cross-compilers as > sysroot based which means that "/usr/lib" in a linker script is not actually > pointing to /usr/lib, it's pointing to the sysroot/usr/lib. No. See bug #210145. This would only be the case if the local linker script was somewhere in sysroot. When cross compiling with the usual xmerge script (http://www.gentoo.org/proj/en/base/embedded/handbook/index.xml), this is not the case. I have no idea which part should be fixed here, but as it stands this can't work. Are you saying that the ebuild should install the local linker scripts somewhere in sysroot, or that a cross compiling emerge command should place it's work directories somewhere in sysroot? Why are the local linker scripts needed anyway? For me the ebuilds work without them, but break with them. Just to reiterate: the libs referenced in the local linker scripts are installed in sysroot/usr/lib. They are not searched for because the cross compiling emerge command places the local linker scripts somewhere in /var/lib/portage/[...]/work (as it should), which is not under sysroot, and hence ld does not try the sysroot location (not sure why it does that). Maybe ld's behavior is not good? I'm having the problem. As a work-around I include the following in the SYSROOT's make.conf
LD_FLAGS="-L${SYSROOT}/lib -L${SYSROOT}/usr/lib"
|
The ebuilds for ss and e2fsprogs each contain a variation on this block: # since we've split out com_err/ss into their own ebuilds, we # need to fake out the local files. let the toolchain find them. echo "GROUP ( /usr/$(get_libdir)/libcom_err.a )" > lib/libcom_err.a echo "GROUP ( /usr/$(get_libdir)/libcom_err.so )" > lib/libcom_err.so When cross compiling the libcom_err.so in /usr/lib may not necessarily be a valid one. This needs to take a modified ROOT into account, e.g.: echo "GROUP ( ${ROOT}/usr/$(get_libdir)/libcom_err.so )" > lib/libcom_err.so which makes both ss and e2fsprogs cross compile cleanly for me.