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]

Re: libc.so GROUP Statement


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]