Leveraging gcc in a cross-compilation environment

Leveraging gcc in a cross-compilation environment

[Philip A. Prindeville]

Hi.

I'm using "gcc" with an old version of buildroot, and I'm trying to figure out a few best practices for having the cross-compiler look at the target's header files and libraries, and not the build host's.

For instance,

* how (on a somewhat hinky, tweaked compiler) do I figure out where it looks for system headers by default?

* and when additional arguments get added (--sysroot, -isysroot, -isystem, -iquote, etc) how do I figure out where the compiler is looking for headers and libraries (short of "strace -f -e trace=open,stat,fstat,lstat,access gcc ...")?

Is there a good document that covers all of these options and more (maybe -stdinc, etc. as well)?

Thanks,

-Philip

Re: Leveraging gcc in a cross-compilation environment

[Ian Lance Taylor]

"Philip A. Prindeville" <philipp_subx@redfish-solutions.com> writes:

> * how (on a somewhat hinky, tweaked compiler) do I figure out where it looks for system headers by default?

gcc -v will show you this when compiling a file.

> * and when additional arguments get added (--sysroot, -isysroot, -isystem, -iquote, etc) how do I figure out where the compiler is looking for headers and libraries (short of "strace -f -e trace=open,stat,fstat,lstat,access gcc ...")?

Same answer.

Ian

Re: Leveraging gcc in a cross-compilation environment

[Philip A. Prindeville]

On 01/12/2010 07:19 AM, Ian Lance Taylor wrote:
> "Philip A. Prindeville" <philipp_subx@redfish-solutions.com> writes:
> 
>> * how (on a somewhat hinky, tweaked compiler) do I figure out where it looks for system headers by default?
> 
> gcc -v will show you this when compiling a file.
> 
>> * and when additional arguments get added (--sysroot, -isysroot, -isystem, -iquote, etc) how do I figure out where the compiler is looking for headers and libraries (short of "strace -f -e trace=open,stat,fstat,lstat,access gcc ...")?
> 
> Same answer.
> 
> Ian

Ok, so I'm invoking the compiler as:

$ /home/philipp/kernel/build_i586/staging_dir/bin/i586-linux-uclibc-gcc -Os -pipe -fomit-frame-pointer -march=k6-2 -fno-align-functions -fno-align-loops -fno-align-jumps -fno-align-labels --sysroot=/home/philipp/kernel/build_i586/staging_dir -isystem /usr/include -Wall -O2 -D_REENTRANT -fPIC -Isrc/include -I/usr/include/openssl -I- '-DPROXY_VERSION="NOVER"' '-DCDIR="/etc"' '-DCFILE="astmanproxy.conf"' '-DMDIR="/usr/lib/astmanproxy/modules"' '-DPDIR="/etc/asterisk"' '-DPFILE="astmanproxy.users"' -cb -o ssl.o src/ssl.c -v

and it's telling me:

...

gcc version 4.2.5 20090325 (prerelease)
 /home/philipp/kernel/build_i586/staging_dir/bin-ccache/../libexec/gcc/i586-linux-uclibc/4.2.5/cc1 -quiet -v -Isrc/include -I/usr/include/openssl -I- -iprefix /home/philipp/kernel/build_i586/staging_dir/bin-ccache/../lib/gcc/i586-linux-uclibc/4.2.5/ -isysroot /home/philipp/kernel/build_i586/staging_dir -D_REENTRANT -DPROXY_VERSION="NOVER" -DCDIR="/etc" -DCFILE="astmanproxy.conf" -DMDIR="/usr/lib/astmanproxy/modules" -DPDIR="/etc/asterisk" -DPFILE="astmanproxy.users" -isystem /usr/include src/ssl.c -quiet -dumpbase ssl.c -march=k6-2 -auxbase ssl -Os -O2 -Wall -version -fomit-frame-pointer -fno-align-functions -fno-align-loops -fno-align-jumps -fno-align-labels -fPIC -o - |
 /home/philipp/kernel/build_i586/staging_dir/bin-ccache/../lib/gcc/i586-linux-uclibc/4.2.5/../../../../i586-linux-uclibc/bin/as -V -Qy -o /tmp/ccTjdxIN.o -
GNU assembler version 2.17.50.0.14 (i586-linux-uclibc) using BFD version (Linux/GNU Binutils) 2.17.50.0.14.20070322
cc1: note: obsolete option -I- used, please use -iquote instead
ignoring duplicate directory "/home/philipp/kernel/build_i586/staging_dir/lib/gcc/i586-linux-uclibc/4.2.5/include"
ignoring duplicate directory "/home/philipp/kernel/build_i586/staging_dir/lib/gcc/i586-linux-uclibc/4.2.5/../../../../i586-linux-uclibc/sys-include"
ignoring duplicate directory "/home/philipp/kernel/build_i586/staging_dir/lib/gcc/i586-linux-uclibc/4.2.5/../../../../i586-linux-uclibc/include"
#include "..." search starts here:
 src/include
 /usr/include/openssl
#include <...> search starts here:
 /usr/include
 /home/philipp/kernel/build_i586/staging_dir/bin-ccache/../lib/gcc/i586-linux-uclibc/4.2.5/include
 /home/philipp/kernel/build_i586/staging_dir/bin-ccache/../lib/gcc/i586-linux-uclibc/4.2.5/../../../../i586-linux-uclibc/sys-include
 /home/philipp/kernel/build_i586/staging_dir/bin-ccache/../lib/gcc/i586-linux-uclibc/4.2.5/../../../../i586-linux-uclibc/include
End of search list.


My question is, why is it saying:

#include <...> search starts here:
 /usr/include

and not applying the --sysroot argument to look for /sysroot-prefix/usr/include instead?

If I specify -isystem /usr/include then it doesn't find the appropriate files.

If I specify -isystem /home/philipp/kernel/build_i586/staging_dir/usr/include then it does.

This contradicts what the man page says the --sysroot argument does:

       --sysroot=dir
           Use dir as the logical root directory for headers and libraries.
           For example, if the compiler would normally search for headers in
           /usr/include and libraries in /usr/lib, it will instead search
           dir/usr/include and dir/usr/lib.

           If you use both this option and the -isysroot option, then the
           --sysroot option will apply to libraries, but the -isysroot option
           will apply to header files.

Using -isysroot yields the same.

Re: Leveraging gcc in a cross-compilation environment

[Ian Lance Taylor]

"Philip A. Prindeville" <philipp_subx@redfish-solutions.com> writes:

> Ok, so I'm invoking the compiler as:
>
> $ /home/philipp/kernel/build_i586/staging_dir/bin/i586-linux-uclibc-gcc -Os -pipe -fomit-frame-pointer -march=k6-2 -fno-align-functions -fno-align-loops -fno-align-jumps -fno-align-labels --sysroot=/home/philipp/kernel/build_i586/staging_dir -isystem /usr/include -Wall -O2 -D_REENTRANT -fPIC -Isrc/include -I/usr/include/openssl -I- '-DPROXY_VERSION="NOVER"' '-DCDIR="/etc"' '-DCFILE="astmanproxy.conf"' '-DMDIR="/usr/lib/astmanproxy/modules"' '-DPDIR="/etc/asterisk"' '-DPFILE="astmanproxy.users"' -cb -o ssl.o src/ssl.c -v

You explicitly passed -isystem /usr/include, so gcc searches
/usr/include.

As of gcc 4.3 you would -isystem =/usr/include to apply the sysroot to
your -isystem parameter.

Ian

Re: Leveraging gcc in a cross-compilation environment

[Philip A. Prindeville]

On 01/12/2010 10:43 AM, Ian Lance Taylor wrote:
> "Philip A. Prindeville" <philipp_subx@redfish-solutions.com> writes:
> 
>> Ok, so I'm invoking the compiler as:
>>
>> $ /home/philipp/kernel/build_i586/staging_dir/bin/i586-linux-uclibc-gcc -Os -pipe -fomit-frame-pointer -march=k6-2 -fno-align-functions -fno-align-loops -fno-align-jumps -fno-align-labels --sysroot=/home/philipp/kernel/build_i586/staging_dir -isystem /usr/include -Wall -O2 -D_REENTRANT -fPIC -Isrc/include -I/usr/include/openssl -I- '-DPROXY_VERSION="NOVER"' '-DCDIR="/etc"' '-DCFILE="astmanproxy.conf"' '-DMDIR="/usr/lib/astmanproxy/modules"' '-DPDIR="/etc/asterisk"' '-DPFILE="astmanproxy.users"' -cb -o ssl.o src/ssl.c -v
> 
> You explicitly passed -isystem /usr/include, so gcc searches
> /usr/include.
> 
> As of gcc 4.3 you would -isystem =/usr/include to apply the sysroot to
> your -isystem parameter.
> 
> Ian

I have to say, the overloading of '=' *plus* the fact that some arguments use '=' (like --sysroot=) while others don't (-isystem xxx) is confusing.

Ok, what about how 'ld' interprets --sysroot?  If I have "ld --sysroot /xyzzy -L/a/b/c" will it look in /xyzzy/a/b/c?

Re: Leveraging gcc in a cross-compilation environment

[Ian Lance Taylor]

"Philip A. Prindeville" <philipp_subx@redfish-solutions.com> writes:

> I have to say, the overloading of '=' *plus* the fact that some arguments use '=' (like --sysroot=) while others don't (-isystem xxx) is confusing.

Yes.

> Ok, what about how 'ld' interprets --sysroot?  If I have "ld --sysroot /xyzzy -L/a/b/c" will it look in /xyzzy/a/b/c?

No.  ld uses --sysroot for very few things, really just to set the
default library search path.  Generally the compiler passes the
library paths to search as -L options.

Ian

Re: Leveraging gcc in a cross-compilation environment

[Philip A. Prindeville]

On 01/12/2010 02:04 PM, Ian Lance Taylor wrote:
> "Philip A. Prindeville" <philipp_subx@redfish-solutions.com> writes:
> 
>> I have to say, the overloading of '=' *plus* the fact that some arguments use '=' (like --sysroot=) while others don't (-isystem xxx) is confusing.
> 
> Yes.
> 
>> Ok, what about how 'ld' interprets --sysroot?  If I have "ld --sysroot /xyzzy -L/a/b/c" will it look in /xyzzy/a/b/c?
> 
> No.  ld uses --sysroot for very few things, really just to set the
> default library search path.  Generally the compiler passes the
> library paths to search as -L options.
> 
> Ian

Any chance of filing an enhancement request that -L =path expand to -L <sysroot>/path?

Re: Leveraging gcc in a cross-compilation environment

[Ian Lance Taylor]

"Philip A. Prindeville" <philipp_subx@redfish-solutions.com> writes:

> On 01/12/2010 02:04 PM, Ian Lance Taylor wrote:
>> "Philip A. Prindeville" <philipp_subx@redfish-solutions.com> writes:
>> 
>>> I have to say, the overloading of '=' *plus* the fact that some arguments use '=' (like --sysroot=) while others don't (-isystem xxx) is confusing.
>> 
>> Yes.
>> 
>>> Ok, what about how 'ld' interprets --sysroot?  If I have "ld --sysroot /xyzzy -L/a/b/c" will it look in /xyzzy/a/b/c?
>> 
>> No.  ld uses --sysroot for very few things, really just to set the
>> default library search path.  Generally the compiler passes the
>> library paths to search as -L options.
>> 
>> Ian
>
> Any chance of filing an enhancement request that -L =path expand to -L <sysroot>/path?

Actually, now that I look at the linker code, I think that already
works.

Ian