In article <4.1.20000425133323.00bdb160@mailhost.hq.freegate.com>,
Chuck McManis <cmcmanis@mcmanis.com> wrote:
>At 01:08 PM 4/25/00 -0700, you wrote:
>>I'm in the same boat, here (minus the VAX boat anchor).  I've had some
>>stuff come up and evaluate to '-Wl,-R/lib'...hmm, maybe a different
>>boat after all.
>
>That would be one bsd.prog.mk version out of date relative to -current :-)

Actually, that would be one _bsd.pkg.mk_ version out of date.  That was a
problem of using an unset MOTIFBASE variable (pr pkg/9914, fixed today in
rev 1.429)

>I fixed it by changing it to -Wl,"-rpath-link $DESTDIR/usr/lib" since "-Wl"
>is "pass this to the linker" but in order to pass an option that itself
>takes and argument you have to protect it by quotes.
>
>Don't know if this is the correct fix but it works for now. What is pretty
>clear is that the system won't build as it is currently written. Anyone can
>verify this by using -m /usr/src/share/mk to their build command. (Which I
>do by default now in my build script since this kind of thing isn't exactly
>rare :-))

The problem is as follows:

In bsd.prog.mk 1.110 and before, the linker failed to get interlibrary
dependencies right when using DESTDIR.

In bsd.prog.mk 1.111 mycroft added '-R${DESTDIR}/usr/lib' to the link line.
This fixed the interlibrary dependencies, but broke other things, since
-R (passed to the linker) is also used for run-time shared library paths,
and now at run-time the resulting programs looked for their shared libraries
in ${DESTDIR}/usr/lib.  Sometimes this resulted in subtle failures during
the next build process, when as soon as a new (and possibly incompatible)
library went into place in DESTDIR, the build tools stopped working, due
to running with that new library.

In bsd.prog.mk 1.112 mrg changed the -R to -rpath-link, which sets _only_
the interlibrary depend path, but not the run-time linker path.  This fixed
both problems on ld.new platforms.

Unfortunately, the old gnu ld was never hacked to support -rpath-link (the
way it was for -R/-rpath) and as a result, ports using the old linker fail
during DESTDIR builds.  However, the only machines using said linker (in
current) are arm32, ns32k, vax, and any i386, m68k, or sparc still running
a.out, and as a result the breakage didn't show up until someone tried
building using one of these platforms.

I don't know whether or not a.out has the same interlibrary issues as the
-rpath-link is meant to fix.  I have a feeling it doesn't or else there
would have probably been complaints a long time ago.  In that case, it
should be sufficient to modify gnusrc/gnu/ld/ld/ld.c to detect the
-rpath-link option and just ignore it and its value:

Index: /var/src/gnu/usr.bin/ld/ld/ld.c
===================================================================
RCS file: /source/cvs/netbsd/current/src/gnu/usr.bin/ld/ld/ld.c,v
retrieving revision 1.68
diff -u -r1.68 ld.c
--- ld.c	2000/01/13 16:22:44	1.68
+++ ld.c	2000/04/26 01:16:52
@@ -693,6 +693,8 @@
 		/* Ignore "-rpath" and hope ld.so.conf will cover our sins. */
 		if (!strcmp(&arg[1], "rpath"))
 			return 2;
+		if (!strcmp(&arg[1], "rpath-link"))
+			return 2;
 		return 1;
 
 	case 's':
@@ -921,6 +923,11 @@
 		if (warn_forwards_compatible_inexact)
 			warnx("%s %s ignored", swt, arg);
 		goto do_rpath;
+	}
+	if (strcmp(swt + 1, "rpath-link") == 0) {
+		if (warn_forwards_compatible_inexact)
+			warnx("%s %s ignored", swt, arg);
+		return;
 	}
 #endif /* GNU_BINUTIL_COMPAT */

=====
Then rebuild ld and things should work.  I haven't tested this patch as I
don't have any of said machines available, though...

Of course, the Right thing to do is get all ports moved over to ld.new, but
that'll require more than a one-minute coding hack :)

jdarrow

-- 
John Darrow - Senior Technical Specialist               Office: 630/752-5201
Computing Services, Wheaton College, Wheaton, IL 60187  Fax:    630/752-5968
Alphapage: 6303160707@alphapage.airtouch.com            Pager:  630/316-0707
Email:     John.P.Darrow@wheaton.edu