Cross-compiler fails to locate of libc.so.6

[daveroyal]

I am attempting to compile Audacious media player on Leap 42.3 to run on a headless banana pi (armv7) running armbian (like debian). (The published packages contain lots of GUI stuff but there are compile-time options to exclude both GTK and Qt: https://audacious-media-player.org/download.)

I have installed these unstable packages from
http://download.opensuse.org/reposit...USE_Leap_42.3/

cross-arm-linux-gnueabi-binutils-2.29.1-18.1.x86_64
cross-arm-linux-gnueabi-gcc-7.2.0-29.1.x86_64
cross-arm-linux-gnueabi-glibc-2.26-37.1.noarch

When compiling hello-world I got 3 errors like this:

/opt/cross/lib/gcc/arm-linux-gnueabi/7.2.0/../../../../arm-linux-gnueabi/bin/ld: cannot find /opt/cross/arm-linux-gnueabi/lib/libc.so.6 inside /opt/cross/arm-linux-gnueabi/bin/../../arm-linux-gnueabi
(And similar for libc_nonshared.a and ld-linux.so.3)

/opt/cross/arm-linux-gnueabi/lib/libc.so.6 etc do exist

I solved that by adding --sysroot=/ so that it would find /opt/cross/arm-linux-gnueabi/lib/libc.so.6 within sysroot - which I felt wrong but made it compile OK.

So I moved on to compiling audacious
./configure --disable-qt --disable-gtk --build i686-pc-linux-gnu --host arm-linux-gnueabi

This fails with the same errors:
configure:2913: arm-linux-gnueabi-gcc conftest.c >&5
/opt/cross/lib/gcc/arm-linux-gnueabi/7.2.0/../../../../arm-linux-gnueabi/bin/ld: cannot find /opt/cross/arm-linux-gnueabi/lib/libc.so.6 inside /opt/cross/arm-linux-gnueabi/bin/../../arm-linux-gnueabi

Why is it looking in /opt/cross/arm-linux-gnueabi/bin/../../arm-linux-gnueabi ?
Can I fix it by inserting my earlier workaround somewhere?

Any ideas or suggestions?

Here is some info about the compiler:

>arm-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/opt/cross/libexec/gcc/arm-linux-gnueabi/7.2.0/lto-wrapper
Target: arm-linux-gnueabi
Configured with: ../configure --prefix=/opt/cross --enable-bootstrap=no --build=x86_64-suse-linux --target=arm-linux-gnueabi --enable-languages=c,c++ --with-float=soft --disable-libmudflap --disable-multilib --with-cpu=arm7tdmi --with-float=soft
Thread model: posix
gcc version 7.2.0 (GCC)

> arm-linux-gnueabi-gcc -print-search-dirs
install: /opt/cross/lib/gcc/arm-linux-gnueabi/7.2.0/
programs: =/opt/cross/libexec/gcc/arm-linux-gnueabi/7.2.0/:/opt/cross/libexec/gcc/arm-linux-gnueabi/7.2.0/:/opt/cross/libexec/gcc/arm-linux-gnueabi/:/opt/cross/lib/gcc/arm-linux-gnueabi/7.2.0/:/opt/cross/lib/gcc/arm-linux-gnueabi/:/opt/cross/lib/gcc/arm-linux-gnueabi/7.2.0/../../../../arm-linux-gnueabi/bin/arm-linux-gnueabi/7.2.0/:/opt/cross/lib/gcc/arm-linux-gnueabi/7.2.0/../../../../arm-linux-gnueabi/bin/
libraries: =/opt/cross/lib/gcc/arm-linux-gnueabi/7.2.0/:/opt/cross/lib/gcc/arm-linux-gnueabi/7.2.0/../../../../arm-linux-gnueabi/lib/arm-linux-gnueabi/7.2.0/:/opt/cross/lib/gcc/arm-linux-gnueabi/7.2.0/../../../../arm-linux-gnueabi/lib/

[arvidjaar]

Why is it looking in /opt/cross/arm-linux-gnueabi/bin/../../arm-linux-gnueabi ?

I suspect the reason is the binutils are built with --with-sysroot=/opt/cross/arm-linux-gnueabi and gcc - without. My hunch is that these must match.

Can I fix it by inserting my earlier workaround somewhere?

./configure CFLAGS===sysroot=/ LDFLAGS=--syroot=/ ...

[daveroyal]

Many thanks.

./configure CFLAGS=--sysroot=/ LDFLAGS=--sysroot=/ --disable-qt --disable-gtk --build i686-pc-linux-gnu --host arm-linux-gnueabi

completes OK.

There is a warning:
config.status: WARNING: 'audacious.pc.in' seems to ignore the --datarootdir setting
but I think that's unrelated.

On to the compile:

/opt/cross/arm-linux-gnueabi/include/bits/sigcontext.h:30:11: fatal error: asm/sigcontext.h: No such file or directory
# include <asm/sigcontext.h>

There is indeed no asm directory anywhere in this cross compiler tree. I'll investigate and post a new thread if I can't solve it.

[daveroyal]

I'm now using a different cross-compiler from Linaro. This has two advantages over the one in my OP:
- it's up to date
- it's for arm-linux-gnueabihf like the target

I've got a lot further with this but I'm stuck on a problem with linking. I'm pretty sure this is not a problem with SuSE. I doubt if it's a problem with Audacious - it compiles fine natively here on SuSE. It may be a problem with the cross-compiler or the debian target libraries (e.g. libc) or it mat just be I've missed setting a parameter.

Full details are on my post on the Audacious forum here
https://redmine.audacious-media-play...6#message-2246

The problem is at the end of that post:

/opt/linaro/bin/../lib/gcc/arm-linux-gnueabihf/7.2.1/../../../../arm-linux-gnueabihf/bin/ld: /opt/linaro/usr/lib/arm-linux-gnueabihf//libglib-2.0.a(libglib_2_0_la-gstrfuncs.o): undefined reference to symbol 'strtoull_l@@GLIBC_2.4'
/opt/linaro/bin/../arm-linux-gnueabihf/libc/lib/libc.so.6: error adding symbols: DSO missing from command line

Any ideas of possible causes of this?

[arvidjaar]

Any ideas of possible causes of this?

Apart from suggestion to open new discussion for new problem? Well, the obvious thing to check - which version of glibc you have. May be libglib was compiled against different version.

[daveroyal]

@arvidjaar Thanks for your reply.

I decided this didn't justify a new thread. Mainly because it's clearly not a SuSE problem, but also the context of the OP is still relevant.

I have 2 sources of packages in my cross-compiler tree:
- The Linario Cross compiler - one big tgz
- Several Debian Stretch (stable) packages. I added them as I hit unmet dependencies during compile.

The Debian packages should be compatible with each other and are identical to ones installed in Armbian on the Banana Pi - which is obviously essential. e.g. libglib2.0-0_2.50.3-2_armhf.deb

The Linaro package contains libraries too - for example libc-2.25.so. So there is scope for duplication and incompatibility between libraries from the two sources. And there /are/ duplicates - but in different paths.

I see that the error refers to 'strtoull_l@@GLIBC_2.4' but I don't think that 2.4 refers to a version of glibc itself but a function within it. It also refers to liblib-2.0.a: that comes from Debian, but whatever requires that function probably came from Linaro. That may be the only function link that's wrong, or it may just be the first of many.

Debian Stretch stable dates from 5/2017. I tried a contemporary version of Linaro, but got the same error.

I think I may need to find a cross-compiler built on the Debian libraries, rather than whatever Linaro use.

Or maybe my diagnosis of the problem is entirely wrong!

[arvidjaar]

In another forum where you gave more lines of output it clearly identifies the problem - you need to list library after any reference to this library. Another possibility is that you try static build and have no static libc.

[daveroyal]

In another forum where you gave more lines of output it clearly identifies the problem - you need to list library after any reference to this library.

No, I don't think that is the problem. All the libraries are present, and I've tried adding paths to all the duplicates (though not in every possible sequence.) You will have seen on that other thread that there is - I'm fairly sure - an error in their configure script which appears not to allow for cross-compiling. But I don't think that is actually causing this issue. From googling similar messages I think it's probably incompatible items as I wrote in my last post. I think I need to have every module exactly once.

Another possibility is that you try static build and have no static libc.

Yes, I tried that out of curiosity. Hundreds of 'missing' errors - unsurprising as I've not installed any audio libararies yet. But I don't want to go that way.

Giving up for now. Thanks for your thoughts.