On Tue, 21 Feb 2012 21:11:13 -0800 Tim Kientzle <t...@kientzle.com> wrote:
> > On Feb 21, 2012, at 3:39 PM, Daniel Eischen wrote: > > > On Tue, 21 Feb 2012, Steve Kargl wrote: > > > >> 3) Add a new option to ldconfig to prepend new libraries to > >> the hints files and fix the ports to use this option instead > >> of -m. > > > > You don't want system binaries that want /lib/libgcc_s.so.1 > > to use /usr/local/lib/gccXX/libgcc_s.so.1, though. Wouldn't > > your option 3 do that? > > Why not? Would it cause problems? > > Is libgcc from GCC 4.6 incompatible with /lib/libgcc? > > If I understand correctly, the libgcc in base is pretty stripped > down compared to "regular" libgcc, because most of that > stuff is in our libc instead. So if there were compatibility > problems, I'd expect those to show up when GCC 4.6 linked > programs against /usr/local/.../libgcc and /lib/libc. > You understand it a bit wrong, but your conclusions are correct. libgcc in base is not stripped in any way and is supposed to be identical to one coming from upstream. As long as upstream maintains backward compatibility, their library should be a perfect replacement for ours. There was a time period while FreeBSD used dynamic unwind into search using dl_iterate_phdr while upstream GCCs didn't, but that was fixed by GCC folks switching GCC to use dl_iterate_phdr on Linux and FreeBSD by default quite while ago. I am not aware of any other incompatibilities at this time. -- Alexander Kabaev
signature.asc
Description: PGP signature
