Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #148067 > unrolled thread

Cross-compiling with shared libraries

Back to article view | Back to comp.lang.c

Contents

  Cross-compiling with shared libraries Frederick Gotham <cauldwell.thomas@gmail.com> - 2019-11-20 01:07 -0800
    Re: Cross-compiling with shared libraries David Brown <david.brown@hesbynett.no> - 2019-11-20 11:07 +0100
      Re: Cross-compiling with shared libraries Frederick Gotham <cauldwell.thomas@gmail.com> - 2019-11-20 03:23 -0800
        Re: Cross-compiling with shared libraries David Brown <david.brown@hesbynett.no> - 2019-11-20 15:17 +0100
      Re: Cross-compiling with shared libraries Ian Collins <ian-news@hotmail.com> - 2019-11-21 07:50 +1300

#148067 — Cross-compiling with shared libraries

Typically, when a cross-compiler is installed properly on a computer, do you need to explicitly invoke it with "--sysroot=/opt/targetfs", or is this parameter already implied if the cross-compiler is properly installed?

Right now I'm working on an embedded Linux project, and I'm using Buildroot to produce a minimalistic Linux installation with only the programs and libraries I need.

I see that some 3rd party packages, (i.e. NOT the one's built into Buildroot), invoke the correct cross-compiler but they don't give the "--sysroot" parameter.

For example, a normal native compilation would be:

    gcc main.c -o prog

And a correct cross-compilation would be:

    CC = /opt/src/build/output/host/bin/x86_64-buildroot-linux-gnu-gcc
    SYSROOT = /opt/src/build/output/host/x86_64-buildroot-linux-gnu/sysroot

    $(CC) --sysroot=$(SYSROOT) main.c -o prog

I see however that some packages are leaving out the sysroot parameter, and so they're just doing:

    $(CC) main.c -o prog

This predictably fails if the host and the target have different CPU's, for example if my office PC is x86_64 and my target is embedded Linux ARM aarch64.

On my current project though, the host and the target have the same CPU, and so if you leave out the "--sysroot" parameter then the program ends up linking with shared libraries installed on the host. Sometimes this happens without any compiler warning or error!

So how are cross-compilers supposed to work? If they are installed properly, do you need to give them the "--sysroot" parameter?

[toc] | [next] | [standalone]

#148070

On 20/11/2019 10:07, Frederick Gotham wrote:
> 
> Typically, when a cross-compiler is installed properly on a computer, do you need to explicitly invoke it with "--sysroot=/opt/targetfs", or is this parameter already implied if the cross-compiler is properly installed?
> 
> Right now I'm working on an embedded Linux project, and I'm using Buildroot to produce a minimalistic Linux installation with only the programs and libraries I need.
> 
> I see that some 3rd party packages, (i.e. NOT the one's built into Buildroot), invoke the correct cross-compiler but they don't give the "--sysroot" parameter.
> 
> For example, a normal native compilation would be:
> 
>     gcc main.c -o prog
> 
> And a correct cross-compilation would be:
> 
>     CC = /opt/src/build/output/host/bin/x86_64-buildroot-linux-gnu-gcc
>     SYSROOT = /opt/src/build/output/host/x86_64-buildroot-linux-gnu/sysroot
> 
>     $(CC) --sysroot=$(SYSROOT) main.c -o prog
> 
> I see however that some packages are leaving out the sysroot parameter, and so they're just doing:
> 
>     $(CC) main.c -o prog
> 
> This predictably fails if the host and the target have different CPU's, for example if my office PC is x86_64 and my target is embedded Linux ARM aarch64.
> 
> On my current project though, the host and the target have the same CPU, and so if you leave out the "--sysroot" parameter then the program ends up linking with shared libraries installed on the host. Sometimes this happens without any compiler warning or error!
> 
> So how are cross-compilers supposed to work? If they are installed properly, do you need to give them the "--sysroot" parameter?
> 

The answer here is very much "it depends".

In particular, it depends on the way the gcc was built.  It is common
for cross-compiler builds of gcc to have their key directories
(containing include files, libraries, linker files, etc.) configured so
that you have a single directory tree with the toolchain binaries and
all related build files held together.  The compiler finds the files
using relative paths from the gcc binary, so that this directory tree
can be moved around.  So when I run the "arm-none-eabi-gcc" compiler
with a C file that has "#include <stdlib.h>", it finds that include file
by looking in the path "../arm-none-eabi/include/".

This is particularly common for freestanding gcc builds - the compiler
used for building the kernel, uboot, libraries, etc.  Freestanding
implementations are more self-contained, and do not use dynamic
libraries or deal with other files on the target filesystem.

For user-mode software on the target, you need to have sysroot correct.
 Often that will be handled by a build system like Buildroot.  But
third-party software, such as the ones you are looking at now, can be
more difficult.

If you are using the user-mode cross-compiler built as part of the
Buildroot (or other system), it might have the sysroot set up correctly
already.  Sometimes you can do it with environment variables before
starting "make".  Sometimes it might be most efficient with a chroot
environment.  There are various ways, and it's not always easy to know
which is the best method.

You can get some information about the configuration by running "gcc
-dumpspecs" (for the appropriate "gcc", of course).  The configured
specs use a lot of macros - you'll have to read the documentation or
google for help there.


So no simple answer from me, I'm afraid - but perhaps that gives you
some ideas.

[toc] | [prev] | [next] | [standalone]

#148073

On Wednesday, November 20, 2019 at 10:07:15 AM UTC, David Brown wrote:
 
> You can get some information about the configuration by running "gcc
> -dumpspecs"


Here's what I get:

/opt/src/build/output/host/bin/x86_64-buildroot-linux-gnu-gcc -dumpspecs

*sysroot_spec:
--sysroot=%R

I don't know what the "%R" is.

I note that I get the same output when I do it for my native compiler "gcc -dumpspecs"

[toc] | [prev] | [next] | [standalone]

#148078

On 20/11/2019 12:23, Frederick Gotham wrote:
> On Wednesday, November 20, 2019 at 10:07:15 AM UTC, David Brown wrote:
>  
>> You can get some information about the configuration by running "gcc
>> -dumpspecs"
> 
> 
> Here's what I get:
> 
> /opt/src/build/output/host/bin/x86_64-buildroot-linux-gnu-gcc -dumpspecs
> 
> *sysroot_spec:
> --sysroot=%R
> 
> I don't know what the "%R" is.
> 
> I note that I get the same output when I do it for my native compiler "gcc -dumpspecs"
> 

That's what I meant about dumpspecs having macros that you would have to
look up online.  (Unless someone else here can tell you, of course.)

[toc] | [prev] | [next] | [standalone]

#148080

On 20/11/2019 23:07, David Brown wrote:
> On 20/11/2019 10:07, Frederick Gotham wrote:libraries installed on the host. Sometimes this happens without any compiler warning or error!
>>
>> So how are cross-compilers supposed to work? If they are installed properly, do you need to give them the "--sysroot" parameter?
>>
> 
> The answer here is very much "it depends".
> 
> In particular, it depends on the way the gcc was built.  It is common
> for cross-compiler builds of gcc to have their key directories
> (containing include files, libraries, linker files, etc.) configured so
> that you have a single directory tree with the toolchain binaries and
> all related build files held together.  The compiler finds the files
> using relative paths from the gcc binary, so that this directory tree
> can be moved around.  So when I run the "arm-none-eabi-gcc" compiler
> with a C file that has "#include <stdlib.h>", it finds that include file
> by looking in the path "../arm-none-eabi/include/".
> 
> This is particularly common for freestanding gcc builds - the compiler
> used for building the kernel, uboot, libraries, etc.  Freestanding
> implementations are more self-contained, and do not use dynamic
> libraries or deal with other files on the target filesystem.

It's also worth nothing that when gcc is built this way (with baked in 
sysroot), the "--sysroot"  will not work as I found to my cost a while back!

-- 
Ian.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c

csiph-web