Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 216777 - sys-libs/ss and sys-fs/e2fsprogs should honour ${ROOT}
Summary: sys-libs/ss and sys-fs/e2fsprogs should honour ${ROOT}
Status: RESOLVED INVALID
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo's Team for Core System packages
URL:
Whiteboard:
Keywords:
: 217118 220023 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-04-07 21:36 UTC by Ryan Tandy
Modified: 2008-10-17 22:06 UTC (History)
6 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ryan Tandy 2008-04-07 21:36:42 UTC
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.
Comment 1 Jan Kundrát (RETIRED) gentoo-dev 2008-04-08 00:21:22 UTC
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.
Comment 2 SpanKY gentoo-dev 2008-04-08 00:57:09 UTC
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.
Comment 3 SpanKY gentoo-dev 2008-04-10 19:56:57 UTC
*** Bug 217118 has been marked as a duplicate of this bug. ***
Comment 4 SpanKY gentoo-dev 2008-05-05 03:38:19 UTC
*** Bug 220023 has been marked as a duplicate of this bug. ***
Comment 5 Dave Bender 2008-05-05 03:57:19 UTC
Ryan's fix worked for me in ss, com_err and e2fs, go with it.
Comment 6 Jochen Trumpf 2008-05-21 12:31:30 UTC
(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
Comment 7 SpanKY gentoo-dev 2008-05-31 06:32:39 UTC
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.
Comment 8 Ryan Tandy 2008-05-31 08:06:13 UTC
(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?
Comment 9 SpanKY gentoo-dev 2008-06-01 01:39:11 UTC
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
Comment 10 Ryan Tandy 2008-06-01 03:55:56 UTC
(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.
Comment 11 Jochen Trumpf 2008-06-01 04:05:42 UTC
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.
Comment 12 Jochen Trumpf 2008-06-01 04:24:04 UTC
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.
Comment 13 Jochen Trumpf 2008-06-01 06:21:56 UTC
> 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?
Comment 14 John Holland 2008-08-09 08:55:45 UTC
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"