On Sun, 28 Mar 2004, Jan Schaumann wrote:

> Frederick Bruckman <fredb@immanent.net> wrote:
>
> > > Anybody know of a way to get this to work properly?
> >
> > Here's an idea... Build an "ld" from binutils>=2.14 with
> > "--with-lib-path=/usr/pkg/gcc-2.95.3/lib:/lib/usr/lib" and
> > "--prefix=/usr/pkg/gcc-2.95.3", and then build gcc with
> > "--with-ld=/usr/pkg/gcc-2.95.3/bin/ld". You could also try dumping
> > binutils and gcc in the same directory, NetBSD 1.6-toolchain-style,
> > and hope for the best.
>
> Hmm, yes, while that may work, it would indicate that until this is done
> as part of the actual package the gcc-2.95.3 package should be marked
> broken on NetBSD-current (for -current that has gcc-3.3.3).

I intended that to be taken as an idea for fixing the package, as I
thought that's what you were looking for. (By the way, gcc-2.95.3 is
broken on NetBSD 1.5* too, for similar reasons.)

If there are any takers... for the first alternative, the third step
may not even be necessary, as gcc-3.3.3, at least, does hard-code the
path to the linker automatically, but only if it finds it in
"${prefix}${target}/bin/ld". Not sure when that started. With our
present policy of "one subdirectory, one package", this solution calls
for a whole 'nother binutils package.

The second option would be simpler to implement -- mostly, add
binutils-2.14.tar.gz to lang/gcc's ${DISTFILES}, and add the binutils
binaries to the PLIST -- but longer to debug and test, as every test
will compile binutils *and* gcc. binutils is small compared to gcc,
though, so I personally like that option better.

Frederick