This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Hi Dan, > Chuck Meade wrote: > >>I have a quick crosstool question. The generated ${PREFIX}/${TARGET}/usr/lib/libc.so > >>file still has the absolute "/lib" prefixes in the GROUP line. I thought that > >>crosstool took care of making these relative. > >> > >>I am looking at an email that you wrote here: > >>http://sources.redhat.com/ml/crossgcc/2003-05/msg00097.html, > >>which addresses this topic. > >> > >>Bill Gatliff's page here http://billgatliff.com/~bgat/twiki/bin/view/Crossgcc/BuildGlibC > >>references replacing the generated ${PREFIX}/${TARGET}/lib/libc.so file, > >>but I thought that crosstool took care of this already. Am I doing something > >>wrong here (i.e. should I be seeing crosstool change the libc.so file, > >>such that it does not have the absolute /lib path)? > > > > I see the logic in crosstool.sh where these absolute paths should be removed, > > but it is conditional on $USE_SYSROOT, which I am using. My libc.so in my > > generated sysroot has the absolute /lib path in it. Is there a reason that > > the sed logic in crosstool.sh is not used to clean up the /lib prefixes in > > libc.so when $USE_SYSROOT is set? > > I'm not sure. I wrote that, and said in a comment > > # But won't need to do this at all once we use --with-sysroot (available in gcc-3.3.3 and up) > > but I don't remember the issues. It could be that > this never bothered me because I only use --with-sysroot on > x86_64, and my development systems lack a /lib64, making > any confusion harmless. > What symptoms are you running into? Thanks for the reply. I am building on an x86 host for a PowerPC 860 target, and am using the USE_SYSROOT logic in crosstool. Under the sysroot, the created /usr/lib/libc.so and /usr/lib/libpthread.so files have GROUP lines that have absolute paths. For example here is libc.so: /* GNU ld script Use the shared library, but some functions are only in the static library, so try that secondarily. */ OUTPUT_FORMAT(elf32-powerpc) GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a ) This causes problems later when cross-compiling packages if you include <my sysroot>/usr/lib with the -L option in your LDFLAGS. The linker complains that /lib/libc.so.6 is incompatible, which it is -- the ppc cross linker is looking at the host's /lib directory. Crosstool normally handles this by removing the leading absolute paths in the GROUP line -- but *only* when not using the USE_SYSROOT option. If you are using USE_SYSROOT, you do not get the absolute paths removed. I have worked around this for now by removing the test of USE_SYSROOT from crosstool.sh in the "path cleanup" logic. Any idea why crosstool.sh does not clean the absolute paths when using USE_SYSROOT? Thanks, Chuck ------ Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/ Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |