i386-elf-gcc error while compiling: cannot find crt0.o

[waves_no.13@…]

Hello,

I'm trying to cross compile a simple helloworld.c program on my Mac for an embedded Linux OS. Evrytime I try i get the following error:

xxxxx-MacBook-Pro:Hallo_Welt f0xy$ i386-elf-gcc -g -Wall -o test main.c
/opt/local/lib/gcc/i386-elf/4.7.2/../../../../i386-elf/bin/ld: cannot find crt0.o: No such file or directory
collect2: Fehler: ld gab 1 als Ende-Status zurück 

As far as I understand crt0.o is the C runtime libraray and ld the linker, so it's a missing file?...

Is there a workaround to fix this? It's my first time working with cross compilers and on an unix based OS.

Thanks a lot for any responds that might help!

[mf2k (Frank Schima)]

In the future, please use WikiFormatting and Cc the port maintainers (port info --maintainers i386-elf-gcc).

[ryandesign (Ryan Carsten Schmidt)]

Mojca, does this port work for you? You committed updates to this port last year, but I am also encountering the problem reported in the problem description six years ago; I cannot compile a simple hello world program.

[mojca (Mojca Miklavec)]

While I did try to clean up some gcc-related mess every now and then, I strongly suspect that I only ever tried building the port, while I didn't actually try using the generated binary to compile a hello-world program. I use some other cross-compilers, just not this one. (I'm not currently on my mac.)

[ryandesign (Ryan Carsten Schmidt)]

Reading through the crossgcc-1.0 portgroup, it looks like it just runs ./configure and make once. Reading various documents*, I don't think that's enough to build a functional cross compiler. We run ./configure with --target set to the cross-compiling target, which is indeed what we need to do to build gcc. But we apparently also need to run ./configure with --build set to the build machine target and --host set to the cross-compiling target in order to build a proper glibc.

*
​https://rtime.felk.cvut.cz/hw/index.php/How_to_build_GNU_cross-compilers
​https://crossgcc.s0ufcgwqre.narkive.com/5dDCu94I/cross-compiled-native-compiler-ld-can-t-find-crt1-o
​https://www.gnu.org/software/libc/manual/html_node/Configuring-and-compiling.html
​https://preshing.com/20141119/how-to-build-a-gcc-cross-compiler/

[ryandesign (Ryan Carsten Schmidt)]

Replying to mojca:

I use some other cross-compilers, just not this one.

Ports in MacPorts? Which ones? I'll try one.

[mojca (Mojca Miklavec)]

x86_64-w64-mingw32-gcc, for example. But that one is probably a particularly bad example as it has 3 stages of building (and probably still didn't even get rid of circular dependencies).

[ryandesign (Ryan Carsten Schmidt)]

x86_64-w64-mingw32-gcc does work but that port is structured completely differently from i386-elf-gcc. For one thing there are a bunch of subports, including x86_64-w64-mingw32-crt which contains the crtn.o files whose equivalents i386-elf-gcc is missing.

[mojca (Mojca Miklavec)]

As I told you, this was probably the worst possible example. I remember working with one of the arm cross-compilers and I seem to remember that it worked ok, but I'm not absolutely sure which one.

[ryandesign (Ryan Carsten Schmidt)]

What I'm getting at is: why are the different cross-compiler ports so different from another? Why is x86_64-w64-mingw32-gcc set up with so many different dependency ports whereas i386-elf-gcc is self-contained? Is it just that different maintainers have been interested in only some of the cross-compiler ports, and so some of them have evolved in ways that others haven't? Intuitively, I had expected all of the cross-compiler ports to be set up more or less identically, and the existence of the crossgcc-1.0 portgroup reinforced that expectation for me. But now that I look into it I see that 4 of the 5 arm-*-gcc* ports, for example, don't even use that portgroup. And i386-elf-gcc, the port I'm interested in and which uses the portgroup in what looks like an extremely straightforward way and which I had hoped would be the way that all of the cross-compiler ports would be set up, is one of the ones that doesn't actually work.

Rainer, it looks like you're the one developed the crossgcc-1.0 portgroup and switched i386-elf-gcc over to using it in [791eb1dd78775905d3614bff20303d9fb6005ecd/macports-ports] (#37260). Do you remember whether the port still worked correctly after this change back then? Do you have any suggestions on how to fix it now?

[mojca (Mojca Miklavec)]

I hope that Rainer answers, I can only tell you why x86_64-w64-mingw32-gcc is so much different from the others.

If you look at #40174, you'll notice that it took us some 2.5-3.5 years to even figure out how to build & package it (and that's after we already had a functional albeit abandoned i386-mingw32 port), and we still don't even have the dependencies sorted out correctly (they are still cyclic after all these years).

I have no clue how to properly test some random arch-platform-gcc short of having some special hardware available, but I really needed to build some binaries for Windows that would eventually run on the same machine (MacBook) where I built them. And if things didn't work, I had to keep trying.

At least the MinGW-w64 cross-compiler requires a bunch of special Windows libraries that come from special packages, and there's a separate project devoted just to that. Lots of other boards need special support files to work.

It might make sense to check how other distributions are addressing the problem.

[raimue (Rainer Müller)]

i386-elf is not targeting any operating system, it is meant for development on bare metal. I think the original reporter would be looking for i386-linux-gnu-gcc, but MacPorts does not provide a port for that.

[cooljeanius (Eric Gallager)]

Replying to raimue:

I think the original reporter would be looking for i386-linux-gnu-gcc, but MacPorts does not provide a port for that.

Is there a separate ticket for that? If not, I'll open one.