NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: kern/42420: $ORIGIN undefined on NetBSD



On Thu, Jul 12, 2012 at 11:25 AM, David Holland
<dholland-bugs%netbsd.org@localhost> wrote:
> The following reply was made to PR kern/42420; it has been noted by GNATS.
>
> From: David Holland <dholland-bugs%netbsd.org@localhost>
> To: gnats-bugs%netbsd.org@localhost
> Cc:
> Subject: Re: kern/42420: $ORIGIN undefined on NetBSD
> Date: Thu, 12 Jul 2012 18:22:44 +0000
>
>  On Thu, Jul 12, 2012 at 06:10:06PM +0000, David Holland wrote:
>   >   >  > On Jul 10,  9:25pm, austinenglish%gmail.com@localhost (Austin 
> English) wrote:
>   >   >  > -- Subject: Re: kern/42420: $ORIGIN undefined on NetBSD
>   >   >  >
>   >   >  > Look for #ifdef notyet in kern_exec.c and get rid of them
>   >
>   >  It still won't always work, though.
>   >
>   >  Since the wine people apparently believe they don't need to check for
>   >  the feature before using it, only checking if the linker understands
>   >  how to try, perhaps it should be disabled in binutils until we can
>   >  come up with a complete solution.
>
>  Actually, I take it back, the only thing the cited Wine configure test
>  actually checks for is whether rpaths are accepted (which should be
>  the case on any ELF system) and whether they're allowed to contain $.
>
>  Since rpaths are apparently allowed to contain anything (even control
>  characters) the configure test is absolutely worthless. There's no
>  point attempting to disable $ORIGIN in binutils since it looks as if
>  binutils doesn't know or need to know anything about it.
>
>  As I said some time back, the configure test should be changed
>  upstream to actually test for the feature, in which case the problem
>  goes away.
>
>  --
>  David A. Holland
>  dholland%netbsd.org@localhost
>

From http://bugs.winehq.org/show_bug.cgi?id=20907:
Like I explained in that bug, we don't care if $ORIGIN doesn't work, but it
shouldn't cause the binary to fail to load, and that's a NetBSD bug. It should
just ignore an invalid rpath and continue with the normal library search.

-- 
-Austin


Home | Main Index | Thread Index | Old Index