set global gcc default search paths

前端 未结 2 1443
一个人的身影
一个人的身影 2021-02-02 00:37

when running

arm-none-linux-gnueabi-gcc -print-search-dirs | grep libraries | sed \'s/:/\\n/g\'

I get the following output:

li         


        
相关标签:
2条回答
  • 2021-02-02 01:12

    Your cross-compiling glibc is configured in a wrong way.

    In -Wl,-verbose linker says:

    attempt to open /usr/arm-unknown-linux-gnueabi/usr/lib/libc.so succeeded
    opened script file /usr/arm-unknown-linux-gnueabi/usr/lib/libc.so
    

    So, it used your -L option and was able to open libc.so. But this is not a real .so dynamic library, it is a script (linker script).

    Telepathic mode on: Last line of this libc.so script is

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

    Telepathic mode off

    This line contains absolute pathes hardcoded and redirects linker from arm-...abi to the system's libc ignoring most of search-dirs (may be there is some secret option of ld).

    Just edit this file (with doing a backup) with any text editor and replace all /lib with /usr/arm-unknown-linux-gnueabi/lib. (My good cross-compiler environment has all pathes in this script replaced with prefix.)

    The original script should be used on native compile, native run, but not on cross compiling.

    UPDATE: bytesex says http://linux.bytesex.org/cross-compiler.html that there is the same problem with /usr/lib/libpthread.so, do the replace in this file too.

    To check other libs, do file -skL *.so|grep text in the lib dir.

    0 讨论(0)
  • 2021-02-02 01:14

    As explained by @osgx, gcc is looking in the wrong path for its libraries. I hit a similar issue when trying to cross-compile a program for arm on x86_64. As editing the root-owned files was not an option, I searched further and discovered the --sysroot option:

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

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

    The GNU linker (beginning with version 2.16) has the necessary support for this option. If your linker does not support this option, the header file aspect of --sysroot still works, but the library aspect does not.

    Example usage:

    ./configure --host=arm-unknown-linux-gnueabi \
        CFLAGS='-g -O2 --sysroot=/tmp/rpi-root'
    
    0 讨论(0)
提交回复
热议问题