Peculiar configure behavior

[Randy Chung]

That's actually precisely the problem I've been talking about through 
the course of the thread :)

Given that LDFLAGS was set to -L/usr/local/xfce4/lib 
-R/usr/local/xfce4/lib, it should have generated a makefile which also 
had -L/usr/local/xfce4/lib and -R/usr/local/xfce4/lib set.  What's 
peculiar about the state of things is -L gets set properly, but -R for 
some kooky reason gets set to /usr/lib, but only for a few packages 
(xfcalendar, xffm, and xfrun, as far as edscott and I have been able to 
tell).

I'm sure this would be trivial to fix if I was an experienced autoconf 
toolchain user, but as it is I still need to do an amount of reading on 
the subject.  To my shaky knowledge, Makefiles are generated via the 
configure script, using the Makefile.[in.am]'s, so it seems like there 
would be a simple fix amongst those files.

--

Randy

Brian J. Tarricone wrote:
> in this case, -R is actually passed the the linker (usually ld), and not 
> gcc, as it's using the -Wl option.  for the GNU linker on linux-x86, ld 
> says that -R is actually for passing a filename for ld to read symbol 
> names from, but, for compatibility, if you give -R(directory) instead of 
> -R(file), it'll act as if you gave it the -rpath option.  interesting.  
> that _should_ hardcode those directories in the executable's library 
> search path such that they get searched before other lib paths 
> (including the standard system lib path).  of course, in your example 
> above, -R/usr/lib is given first, so it'll just duplicate the search in 
> the standard location, and it'll look there first, BEFORE it searches 
> /usr/local/xfce4/lib (given in the -rpath options at the end of the 
> line).  i haven't been following this thread as closely as i meant to, 
> but i suspect that this may be related to your problem.
> 
>    -brian