As discussed and debugged tonight with az and solar, to let GCC work fine on Gentoo/FreeBSD we need to change the specs for it. The attached patch between the specs provided and the ones that works allows us to have it working fine finally. Can someone please update GCC 3.4.5 so that we can use it? It's a blocker bug for Gentoo/FreeBSD 6.0 release. Thanks :)
Created attachment 79810 [details, diff] specs.diff
so you need someone to write a real patch for the gcc-3.4.5 source code ?
Diego, could you supply a description of the problem caused by the original specs? We should understand why it's a problem here but presumably not for FreeBSD itself.
Well the problem manifested itself when building things that linked against openssl: libgcc_s was pulled in with a NEEDED line in libcrypto.so and libssl.so, but the linker didn't know where to look for it. When added -lgcc_s to the flags, it was working fine instead. The same happened to openssh. Basically the same problem would happen on normal FreeBSD system, but there libgcc_s.so is in the search path of the linker (because they load ld's search path using ld.so.conf, or rather the ld-elf.so.hints file). Probably if I was still using binutils 2.15 with the fbsd patch the problem wasn't appearing. That was the reason why we actually added that patch, but it's just a workaround to this problem, I'd say. With that change to the specs, the linking works right (libgcc_s is pulled in for every binary a happening for original FreeBSD afaict). And yeah Mike, I have no clue how to change the sources to have that change in the specs :)
ok, that isnt going to happen ... those specs are generated by generic gcc code that has nothing to do with arch/os/etc... try using --disable-shared
(In reply to comment #4) > libgcc_s was pulled in with a NEEDED line in libcrypto.so and > libssl.so, but the linker didn't know where to look for it. When added -lgcc_s > to the flags, it was working fine instead. Surely the solution is to add the compiler's support library directory to the library search list in ld.so.conf (or equivalent). That's what we do on Gentoo Linux.
I thought that ld doesn't look into that when looking for libraries. If that's not the case yeah I need to forward port the 2.15 patch.
The directory containing libgcc_s.so should be the first place gcc looks for libraries it needs - try "gcc -v <something.c>" to see the options the compiler driver passes to the linker (collect2). If HAVE_LD_AS_NEEDED is set, gcc/gcc.c (function init_gcc_specs) generates: default: -lgcc --as-needed -lgcc_s%M --no-as-needed -static: -lgcc -lgcc_eh -shared: -lgcc --as-needed -lgcc_s%M --no-as-needed -shared-libgcc: -lgcc_s%M -lgcc -shared-libgcc -shared: -lgcc_s%M whereas if HAVE_LD_AS_NEEDED is not set, you get what you see on FreeBSD: default: -lgcc -lgcc_eh -static: -lgcc -lgcc_eh -shared: -lgcc_s%M -shared-libgcc: -lgcc_s%M -lgcc -shared-libgcc -shared: -lgcc_s%M so the problem is the default configuration which is static on FreeBSD but shared for Linux. Why provision of AS_NEEDED should make such a difference I'm not sure. A question therefore; does the binutils you build for FreeBSD support AS_NEEDED? If so, why did gcc think it didn't?
(btw I meant to say that my comment #6 was rubbish - ignore it :) )
--as-needed on FreeBSD does not work, I'm not quite sure why, but that's the case. Regard bug #6... seems like ld does look in the ld.so cache file on Linux, so we should do the same on FreeBSD, and then reappear the binutils patch that broke 2.16... I've cut it down and trying it now... I'm going to work on it more so that I can make it acceptable on upstream this time, too.
Okay the actual problem is fixed by the binutils patches I submitted now. Still, I'm wondering about the way binutils works on glibc/uclibc loader, because I'm now seeing something that might be broken there. I want to check that more before having a false allarm, tho.
