On Jan 27, 2005, at 4:48 PM, Greg A. Woods wrote:

> The "on all ELF systems" part simply is simply not true AT ALL.  =
Indeed
> NetBSD is one of the few loners on this front.

Hm... let's see... NetBSD uses the same tools as Linux... so I would=20
say that we are, in fact, not loners on this front.

> All AT&T UNIX System V Release 4 ports used only '-L', and they're the
> _true_ origin of ELF, even as admited by NetBSD's elf(5) manual;
>
> SunOS-5 also defaults the runtime path to the '-L' path(s) of course,
> and I seem to remember others too, but my memory of which actually =
used
> anything like ELF is now rather fuzzy.

Oh, yah, these same tools that NetBSD uses also work on ancient SVR4=20
systems, as well as Solaris.

> In fact the only still-running non-Sun, non-BSD, true ELF-based system=20=

> I
> have access to which does behave in the way NetBSD now does, with its
> own native toolchain, is IRIX-6.5, but it's so far off the beaten path
> that I don't and cannot expect anything better from it.

Actually, the fact of the matter is, compiler/linker options are not=20
really standardized across platforms, and there are (subtle and=20
not-to-subtle) differences that application developers have to account=20=

for in any case.

In any case, setting the RPATH is something that all ELF systems have=20
to do.

> And also note that '-R' is _not_ a documented option for cc(1) on
> NetBSD, so I still don't know how anybody, der Mouse included, but
> especially anyone truly more na=EFve, is supposed to intuit a =
requirement
> for its use.  (and let's not even begin with the damn '-W,l' magic!)

So file a bug report.  We probably ought to maintain our own cc(1)=20
manual page anyway.  The GCC folks care mostly about the info pages,=20
and the info pages don't often document target-specific flags (such as=20=

"cc -R" or "cc -rpath").

> So, on all "proper" ELF implementations that I've ever used the=20
> run-time
> search path for shared objects defaults to the '-L' path(s) they were
> initially ``linked'' with, AS WELL AS to the default run-time search
> path.

There are good reasons for NOT setting the RPATH based on -L.  Consider:

	cc -o foo -L ../foolib -lfoosup

Do you really want the RPATH set that way?  Answer: no.

-- thorpej