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 Yann, --- On Tue, 12/29/09, Doug Kehn <rdkehn@yahoo.com> wrote: > > --- On Tue, 12/29/09, Yann E. MORIN <yann.morin.1998@anciens.enib.fr> > wrote: > > > > > Please, confirm the way you are calling the compiler, > and > > if you indeed > > call it the way I explained above, then we'll see for > a > > proper fix. > > > > I'll keep investigating. > > The proper fix is to fix my build environment. My build environment creates a staging directory so I can execute configure/make/make install for most software packages. The target rootfs is then constructed from the staging directory contents. I was a little over zealous in copying libraries from the toolchain sysroot directory to staging directory: libc_nonshared.a was inadvertently copied to the staging directory. Applications that were failing with the 'cannot find /usr/lib/libc_nonshared.a' error had a -L<staging_dir>/usr/lib option in the gcc command-line. Somehow having libc_nonshared.a in <staging_dir>/usr/lib and in <toolchain_sysroot>/usr/lib is irritating the linker. Removing libc_nonshared.a from <staging_dir>/usr/lib resolved the issue. Note that the linker didn't have a problem with libc_nonshared.a existing in <staging_dir>/usr/lib and <toolchain_sysroot>/usr/lib if the gcc command-line didn't contain the -L<staging_dir>/usr/lib option. Sorry for trouble. Thanks for the help! Regards, ...doug -- For unsubscribe information see http://sourceware.org/lists.html#faq
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |