Re: [Bug-gnulib] Re: bug in dummy.c

[Bruno Haible]

Simon Josefsson wrote:
> I tracked it down, and when I follow your procedure, but use GNU ar,
> it fails:
>
> address@hidden:~$ ar cru empty.a dummy.o
> address@hidden:~$ gcc hello.c empty.a
> ld: fatal: file empty.a: unknown file type
> ld: fatal: File processing errors. No output written to a.out
> collect2: ld returned 1 exit status
> address@hidden:~$ /usr/local/bin/ar  --version
> GNU ar 2.12.1
>
> I'm now using /usr/ccs/bin/ar instead, and it works.

OK, thangs for digging into that. I've reported it as a binutils bug.

> Perhaps it is libtool that should check for this broken GNU ar?  Right
> now configure just print:
>
> checking for ar... ar
>
> It could locate and find /usr/ccs/bin/ar instead, which it already
> does for 'ld'.
>
> On the other hand, /usr/ccs/bin/ar might have other bugs...

Yes, _usually_ we prefer the GNU tools, because the vendor tools have
many other bugs. (If you once had the opportunity to compare a vendor's
linker with the GNU linker, on a machine where the total size of
the input is roughly the same as the physical RAM size of the machine,
you'll use the GNU linker forever.)

But we can tell people "use the next version of the binutils, the current
one breaks gnulib".

Bruno