1

Topic: no libgcc & friends in arm-unknown-linux-gnueabi-gcc package

Hi, I've been trying to cross-compile glibc for arm and failed because of missing libgcc. This is the linker error thrown:

/usr/arm-unknown-linux-gnueabi/bin/ld: cannot find -lgcc

I'm sure it's not just the matter of configuring library paths. Arm version of libgcc is really missing.
I have both arm-unknown-linux-gnueabi-gcc-6.3.0-2 and arm-unknown-linux-gnueabi-binutils-2.28.0-2 installed (versions from Hyperbola stable repo). None of them actually contains libgcc.a or libgcc_s.so.

Any suggestions? smile

2

Re: no libgcc & friends in arm-unknown-linux-gnueabi-gcc package

koszko wrote:

Hi, I've been trying to cross-compile glibc for arm and failed because of missing libgcc. This is the linker error thrown:

/usr/arm-unknown-linux-gnueabi/bin/ld: cannot find -lgcc

I'm sure it's not just the matter of configuring library paths. Arm version of libgcc is really missing.
I have both arm-unknown-linux-gnueabi-gcc-6.3.0-2 and arm-unknown-linux-gnueabi-binutils-2.28.0-2 installed (versions from Hyperbola stable repo). None of them actually contains libgcc.a or libgcc_s.so.

Any suggestions? smile

I think if I reply here maybe someone will help you. So here's hoping that works.

HyperbolaBSD: The Future of Secure Libre Lightweight Operating Systems!

3 (edited by koszko 2019-08-13 13:56:39)

Re: no libgcc & friends in arm-unknown-linux-gnueabi-gcc package

zapper wrote:

I think if I reply here maybe someone will help you. So here's hoping that works.

Thanks. I think I might be able to actually solve the issue on my own. When starting this topic, I was already suspecting what the problem is.

In case some less-technical ppl come across this - here's the problem:

Gcc interacts closely with the C library (not just the libc, but also libpthread and many others bundled with it). Aside from explicit calls to libc functions in C programs, compiler often has to generate calls on its own. But to be able to do this, the compiler needs a lot of information about libc & friends. It gets it from their header files and shared libs (and ar archives?). Unfortunately, all those must be available when gcc is being built. It causes a bit of a problem when building a cross-compiler. Development libraries for architecture X are a build dependency (often called make dependency in Arch world) of a cross-gcc targeting X. But to build these libraries (libc & friends) for architecture X, you need an already working cross-compiler. So we have a circular dependency (chicken and egg problem): cross-gcc requires libraries, that require cross-gcc, and so on.

The solution to boostrapping this is to first build a minimal cross-gcc (called 'base' or 'pass1'), that has no information about c library for the target architecture and is unable to build programs against it. It is, however, able to build the libc (& friends), which, when built, can be used for building the actual fully-working cross-compiler (called 'pass2') with all extra features and languages enabled.

Different tutorials/wikias/scripts give a bit different order of cross-toolchain bootstrapping, but it's something like:
binutils → gcc (pass1) → linux api headers and glibc → gcc (pass2)

Arm development libraries package doesn't exist in Hyperbola/Arch. The arm-unknown-linux-gnueabi-gcc package in Hyperbola is built without these libs (as would a minimal pass1 compiler be), but has "the features" enabled in arguments to configure script (as would a pass2 compiler). It also doesn't depend on its respective arm binutils (it does depend on standard binutils, which won't do). All summed up, this build of gcc can't be used for cross-compiling arm glibc. This topic shows what happens.

Gcc PKGBUILDs in the AUR/Arch seem to also have similar problem(s). arm-linux-gnueabi-gcc is only a pass1 compiler, no PKGBUILD for later steps (maintainer is aware of it). arm-linux-gnueabihf-gcc has a bootstrap chain with 3 builds of gcc instead of 2. arm-none-eabi-gcc has a circular dependency with arm-none-eabi-newlib. It works, but cannot be easily bootstrapped. mingw-w64-gcc seems ok. Its pass1 gcc package has a -base suffix. It's a bit different, however, because it targets Microbugs' Windows instead of a GNU/Linux platform (in fact arm-none-eabi mentioned above isn't a GNU/Linux target either). 

It seems that debian does it a better way. It has the cross-toolchain-base source package, from which target platform libraries and headers packages are built. No separate pass1 gcc package exists - looks like it gets built in a temporary directory as part of the cross-libc build. Sources of gcc, binutils, etc. are provided as separate packages, so packaging tools don't attempt to download them every time.

I'm going to open an issue about that in a few hours.

EDIT: I opened an issue. It has all the fields (severity, category, etc.) set wrong, because when I first clicked to submit, I got an error (regarding too long tags field for an sql datatype), had to refill the form and forgot to set the fields again... Now I can't edit it ;_;
EDIT2: Turns out when I first got the error, the issue actually got uploaded, just without tags. https://issues.hyperbola.info/index.php … sk_id=1399. I can't edit/delete this one either sad Sorry for that. Some1 please delete the duplicate.

4 (edited by koszko 2019-08-13 13:57:21)

Re: no libgcc & friends in arm-unknown-linux-gnueabi-gcc package

Duplicate posts got sent accidently because of forum name resolution problems. Some1 please delete these 2.

5 (edited by koszko 2019-08-13 13:57:32)

Re: no libgcc & friends in arm-unknown-linux-gnueabi-gcc package

Duplicate posts got sent accidently because of forum name resolution problems. Some1 please delete these 2.

6

Re: no libgcc & friends in arm-unknown-linux-gnueabi-gcc package

After quite a lot of fighting I seem to have produced working (though maybe missing some detailing like putting right stuff in conflicts arrays) PKGBUILDs using debian patches for: binutils-source, glibc-source, gcc-source, linux-libre-lts-source, arm-linux-gnueabi-linux-libre-lts-api-headers, arm-linux-gnueabi-binutils and arm-linux-gnueabi-glibc (inside which a temporary pass1 gcc is built).

This means right now I am only missing arm-linux-gnueabi-gcc PKGBUILD for full arm toolchain (provided those made so far are correct).

Once full arm toolchain builds, modifying the PKGBUILDs to target other arches should be trivial smile

Once I finish this, I am going to share the PKGBUILDs with every1. If You would like to see the PKGBUILDs for unfinished toolchain as they are right now, let me know and I will put them on some git repo.

7

Re: no libgcc & friends in arm-unknown-linux-gnueabi-gcc package

This thread reminds me gnueabihf is still missing from repo. It would be great to add it, to be able to cross compile for beaglebone for example.

8 (edited by koszko 2019-09-16 15:52:03)

Re: no libgcc & friends in arm-unknown-linux-gnueabi-gcc package

I had the PKGBUILDs for the cross-toolchain ready for some time now. Tried asking pekman about details of contributing PKGBUILDs as directed here, but received no response. Perhaps I found wrong email address or something?

Anyways, I decided to just push the PKGBUILDs to my git repo. I have only tested the toolchain by compiling a hello-world arm binary and running it through qemu. I might have also missed some files when adding everything to git, so please tell me if something doesn't work.

I made things a bit different (and, I believe, cleaner) from what they usually look like in arch - I created packages 'gcc-source', 'linux-libre-lts-source', etc. and made them makedepends of packages like 'arm-linux-gnueabi-gcc', 'arm-linux-gnueabi-linux-libre-lts-api-headers', etc. That way makepkg won't be trying to download sources multiple times when, e.g., building a bunch of gcc cross-compilers targeting different arches... It could probably be improved even further to avoid code repetition inside PKGBUILDs of the same cross-tool with different targets... Anyways, I believe my current solution not to be against the packaging guidelines. I sth's wrong, please tell me and I will try to fix it.

To Hyperbola devs: please, consider using my PKGBUILDs to improve cross-compiler support in Hyperbola. As of now, Arch family is terribly behind Debian in this field hmm

To Aether: if you want an armhf cross-compiler, you could start by adding:     

--with-float=hard \
--with-fpu=vfp

to gcc's configure in my PKGBUILDs (gcc gets configure'd 2 times: first in the build() of arm-linux-gnueabi-glibc (as pass1 compiler) and later in build() of arm-linux-gnueabi-gcc (as a full compiler). It would be interesting to get this work smile