libc.so GROUP Statement

libc.so GROUP Statement

[Doug Kehn]

Hi All,

I'm building arm-cortex_a8-linux-gnueabi with crosstool-ng-1.5.2.  The resulting libc.so contains:

/* GNU ld script
   Use the shared library, but some functions are only in
   the static library, so try that secondarily.  */
OUTPUT_FORMAT(elf32-littlearm)
GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a  AS_NEEDED ( /lib/ld-linux.so.3 ) )

Cross compiling some applications I receive the following error:

.../arm-cortex_a8-linux-gnueabi/bin/ld: cannot find /usr/lib/libc_nonshared.a
collect2: ld returned 1 exit status

If I manually change the GROUP statement in libc.so to:

GROUP ( libc.so.6 libc_nonshared.a  AS_NEEDED ( ld-linux.so.3 ) )

the applications cross compile without error.

Am I doing something wrong when cross compiling the applications?

The arm-cortex_a8-linux-gnueabi crosstool.config has CT_USE_SYSROOT=y (and CT_SYSROOT_DIR_PREFIX=""). I thought the path in the libc.so GROUP statement would be pointing to the toolchain's sysroot directory.  I'm basing this on glibc.sh running make with install_root=$(CT_SYSROOT_DIR).  Am I not reading the script correctly?

Is there a way to configure the toolchain to alter the paths in the libc.so GROUP statement?

Thanks,
...doug



      

--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: libc.so GROUP Statement

[Yann E. MORIN]

Hello Doug!
Hello All!

On Tuesday 29 December 2009 18:28:10 Doug Kehn wrote:
> I'm building arm-cortex_a8-linux-gnueabi with crosstool-ng-1.5.2.
> The resulting libc.so contains: 
> 
> /* GNU ld script
>    Use the shared library, but some functions are only in
>    the static library, so try that secondarily.  */
> OUTPUT_FORMAT(elf32-littlearm)
> GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a  AS_NEEDED ( /lib/ld-linux.so.3 ) )

This is (should be!) black magic used by glibc, and is to be interpreted
relative to the sysroot.

> Cross compiling some applications I receive the following error:
> .../arm-cortex_a8-linux-gnueabi/bin/ld: cannot find /usr/lib/libc_nonshared.a
> collect2: ld returned 1 exit status

How do you call your compiler? If you did set CT_PREFIX_DIR to (eg.):
  /opt/toolchain

Then you call the compiler with :
  /opt/toolchain/bin/arm-cortex_a8-linux-gnueabi-gcc

Ot you set PATH="${PATH}:/opt/toolchain/bin" and you call:
  arm-cortex_a8-linux-gnueabi-gcc

Do *not* call gcc like that:
  /opt/toolchain/arm-cortex_a8-linux-gnueabi/bin/gcc

> If I manually change the GROUP statement in libc.so to:
> GROUP ( libc.so.6 libc_nonshared.a  AS_NEEDED ( ld-linux.so.3 ) )
> the applications cross compile without error.

This is an error. As I said, the paths in GROUP are relative to the
sysroot, and gcc should find them (if called as above).

> Am I doing something wrong when cross compiling the applications?
> 
> The arm-cortex_a8-linux-gnueabi crosstool.config has CT_USE_SYSROOT=y
> (and CT_SYSROOT_DIR_PREFIX=""). I thought the path in the libc.so GROUP
> statement would be pointing to the toolchain's sysroot directory.

Hehe! glibc's black magic. See:
  http://www.gnu.org/software/libc/manual/html_node/Linux.html
around the end of the page.

> I'm basing this on glibc.sh running make with install_root=$(CT_SYSROOT_DIR).
> Am I not reading the script correctly?

Yes, that in the end is telling glibc to strip 'install_root' from the
paths, so that when you move the toolchain around, the sysroot stuff
continues to work. The toolchain is thus relocatable.

> Is there a way to configure the toolchain to alter the paths in the
> libc.so GROUP statement?

I never needed to do that, and most important, in my understanding, that
would break glibc.

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.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
`------------------------------^-------^------------------^--------------------'



--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: libc.so GROUP Statement

[Doug Kehn]

Hi Yann,

--- On Tue, 12/29/09, Yann E. MORIN <yann.morin.1998@anciens.enib.fr> wrote:

> From: Yann E. MORIN <yann.morin.1998@anciens.enib.fr>
> Subject: Re: libc.so GROUP Statement
> To: crossgcc@sourceware.org
> Cc: "Doug Kehn" <rdkehn@yahoo.com>
> Date: Tuesday, December 29, 2009, 1:12 PM
> Hello Doug!
> Hello All!
> 
> On Tuesday 29 December 2009 18:28:10 Doug Kehn wrote:
> > I'm building arm-cortex_a8-linux-gnueabi with
> crosstool-ng-1.5.2.
> > The resulting libc.so contains: 
> > 
> > /* GNU ld script
> >    Use the shared library, but some
> functions are only in
> >    the static library, so try that
> secondarily.  */
> > OUTPUT_FORMAT(elf32-littlearm)
> > GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a 
> AS_NEEDED ( /lib/ld-linux.so.3 ) )
> 
> This is (should be!) black magic used by glibc, and is to
> be interpreted
> relative to the sysroot.
> 
> > Cross compiling some applications I receive the
> following error:
> > .../arm-cortex_a8-linux-gnueabi/bin/ld: cannot find
> /usr/lib/libc_nonshared.a
> > collect2: ld returned 1 exit status
> 
> How do you call your compiler? If you did set CT_PREFIX_DIR
> to (eg.):
>   /opt/toolchain
> 
> Then you call the compiler with :
>   /opt/toolchain/bin/arm-cortex_a8-linux-gnueabi-gcc
> 
> Ot you set PATH="${PATH}:/opt/toolchain/bin" and you call:
>   arm-cortex_a8-linux-gnueabi-gcc
> 
> Do *not* call gcc like that:
>   /opt/toolchain/arm-cortex_a8-linux-gnueabi/bin/gcc
> 

I use the PATH method: PATH=/opt/toolchain/bin:$PATH.  Then set CC=arm-cortex_a8-linux-gnueabi-gcc

> > If I manually change the GROUP statement in libc.so
> to:
> > GROUP ( libc.so.6 libc_nonshared.a  AS_NEEDED (
> ld-linux.so.3 ) )
> > the applications cross compile without error.
> 
> This is an error. As I said, the paths in GROUP are
> relative to the
> sysroot, and gcc should find them (if called as above).
> 
> > Am I doing something wrong when cross compiling the
> applications?
> > 
> > The arm-cortex_a8-linux-gnueabi crosstool.config has
> CT_USE_SYSROOT=y
> > (and CT_SYSROOT_DIR_PREFIX=""). I thought the path in
> the libc.so GROUP
> > statement would be pointing to the toolchain's sysroot
> directory.
> 
> Hehe! glibc's black magic. See:
>   http://www.gnu.org/software/libc/manual/html_node/Linux.html
> around the end of the page.
> 
> > I'm basing this on glibc.sh running make with
> install_root=$(CT_SYSROOT_DIR).
> > Am I not reading the script correctly?
> 
> Yes, that in the end is telling glibc to strip
> 'install_root' from the
> paths, so that when you move the toolchain around, the
> sysroot stuff
> continues to work. The toolchain is thus relocatable.
> 

Ah ... I was interpreting install_root as a prefix instead of a strip.  Thanks.

> > Is there a way to configure the toolchain to alter the
> paths in the
> > libc.so GROUP statement?
> 
> I never needed to do that, and most important, in my
> understanding, that
> would break glibc.
> 
> 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.

Thanks,
...doug





--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: libc.so GROUP Statement

[Doug Kehn]

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

Re: libc.so GROUP Statement

[Yann E. MORIN]

Doug, All,

On Tuesday 29 December 2009 23:59:34 Doug Kehn wrote:
> The proper fix is to fix my build environment.

Good to see you resolved your issue. :-)

Usually, I leave the libraries and headers from the toolchain to the place
they belong: in the sysroot. gcc is smart enough to find them when needed.

Then, once my rootfs (eg. staging area) is finished, I use the 'populate'
helper from crosstool-NG to put system libraries in the rootfs (in fact
a copy of the rootfs), so the rootfs only contains stuff added by the
packages I installed in it.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
`------------------------------^-------^------------------^--------------------'



--
For unsubscribe information see http://sourceware.org/lists.html#faq