native binutils doesn't understand .a files?

[mariuszp]

I have a difficult problem with binutils under my OS and so I'm asking for some pointers. My binutils (including ld, ar and ranlib) fail to understand any .a files (including libgcc.a !!), complaining that the "File format is not recognized". Obviously, this prevents anything C programs from being linked.

I built binutils using a cross-compiling on the host x86_64-linux-gnu, and targetting x86_64-glidix.

At first I noticed that the native libgcc.a is slightly smaller than the cross-compiler libgcc, so I thought it was broken, and copied over the cross-compiler's libgcc for use by the native compiler. This changed nothing; it still fails to recognise the format.

Can anyone see any possible explanation for why that mgiht be the case? Please note that i can successfully link .o files into executables (and in the cases where libgcc is not needed, I can call ld directly to create the final executable).

[mariuszp]

Some more testing: the "ar" utility running under glidix is capable of PRODUCING .a files, but it then all tools (ar, ranlib, ld) fails to recognise their format. However, those files produced by "ar" are readable under Linux. So clearly, my native binutils is capable of producing .a files but for some reason fails to read them.

[gerryg400]

I don't I've every tried to build a .a on my OS. I'll try today.

[gerryg400]

Some more testing: the "ar" utility running under glidix is capable of PRODUCING .a files, but it then all tools (ar, ranlib, ld) fails to recognise their format. However, those files produced by "ar" are readable under Linux. So clearly, my native binutils is capable of producing .a files but for some reason fails to read them.

Can you link with .a files produced on Linux ?

This seems odd
Linux can read Glidix libraries. ==> the libraries themselves are okay.
Can Glidix read Linux libraries? I guess it can because you link against a cross-compiled libc.

[mariuszp]

Glidix can link against DYNAMIC libraries, but not STATIC. And no, it cannot link against static libraries produced by Linux either.
(Hence, it cannot link against libgcc)

[gerryg400]

My guess is a subtle stdio bug...

[mariuszp]

My guess is a subtle stdio bug...

This is likely, but it seems to work for everything else, are you aware of what's different with how it processes .a files?
Or any idea of how this could be debugged? At least which functions i should trace?

[mariuszp]

Ah.. looks like my libc does not like fscaf()ing %lu.

[gerryg400]

Ah.. looks like my libc does not like fscaf()ing %lu.

I hope that fixes it.

[mariuszp]

Ah.. looks like my libc does not like fscaf()ing %lu.

I hope that fixes it.

Indeed, there was a really stupid bug in the *scanf() implementation which caused it to skip the "u" part and attempt to interpret "%l\0".

Right now it has problems invoking "nm" because dup2() fails because of a really bad way in which my kernel handles file descriptors, but that's about to be fixed.