Re: [Gc] boehm-gc breakage between binutils 2.16.1 and 2.17 on FreeBSD[7.2]

Loren James Rittle rittle at
Tue Sep 1 10:24:27 PDT 2009

> I don't like the check "__FreeBSD__ >= 7" because it means I should
> have to copies of libgc (pre-v7 and v7+) and choose which one to use
> at runtime if I'd like to write an app running on both FreeBSD
> versions. Could the libgc itself choose the proper registration
> strategy at runtime (depending on FreeBSD release)?


First of all, I agree with you on one major point, I don't like the
check "__FreeBSD__ >= 7" either.  IMHO, it would have been better (by
some metrics) if HAVE_DL_ITERATE_PHDR was enabled by a configure-time
check.  However, (1) I know that gc maintainers don't use them (for
other good reasons: stability of a port configuration in fragile
code?) and (2) this check is no worse than the existing "is linux? is
glibc version X? is glibc actually configured to support dl?" which I
adapted for the point of inflection on the FreeBSD system (which is
exactly and concisely defined by "__FreeBSD__ >= 7" according to my
CVS research; no version of FreeBSD6 has it, all versions of FreeBSD7 do).

Given the way every other port of gc works, it would take extra code
to make this work the way you ponder.  An additional complication: How
would one produce a proper pre-FreeBSD 7 binary, that also knows about
this post-FreeBSD 7 feature, without using the compiler and headers
from a FreeBSD 7 system?  Like most unix, FreeBSD attempts to provide
backwards compatibility in the forward releases but (on FreeBSD, at
least AFAIK) you typically need to compile on the oldest (major)
version that you want to support.  Unless we taught the gc code itself
how to completely define the API of dl_iterate_phdr and the related
required stuctures used in the callback, there really is no way to
compile the code on a system that does not have it.  Once you compile
the code with (e.g.) the FreeBSD 7 compiler and its headers, then it
will only run from that point forward.  This may be different than how
glibc attempts to work.

Finally, we could make the symbol weak as glibc does, but it would buy
you absolutely nothing in the FreeBSD case since the produced binary
is already bound to FreeBSD7.  If anyone knows a practical way around
this issue, then I will gladly defer [but having been a gcc/FreeBSD
maintainer through ~4 major releases of FreeBSD and 2 major releases
of FSF gcc, I know these practical issues fairly well; it is also why
I studied and tested the proposed patch against so many different
compiler and binutils configurations].


More information about the Gc mailing list