Peculiar configure behavior

[Brian J. Tarricone]

Randy Chung wrote:

> 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.

you sorta missed my point.  -R is actually for a symbol list file, but 
for backward compat, if you give it a directory, it will behave the same 
as -rpath.  looking at your gcc line again:

> gcc -g -O2 -o xfrun4 xfrun4-xfrun.o -Wl,--export-dynamic 
> -Wl,-R/usr/lib  -L/usr/local/xfce4/lib -L/usr/X11R6/lib 
> /usr/local/xfce4/lib/libxfcegui4.so /usr/lib/libgtk-x11-2.0.so 
> /usr/local/xfce4/lib/libxfce4util.so /usr/lib/libgdk-x11-2.0.so 
> /usr/lib/libatk-1.0.so /usr/lib/libgdk_pixbuf-2.0.so 
> /usr/lib/libpangoxft-1.0.so /usr/lib/libpangox-1.0.so 
> /usr/lib/libpango-1.0.so /usr/lib/libgobject-2.0.so 
> /usr/lib/libgmodule-2.0.so -ldl /usr/lib/libglib-2.0.so 
> /usr/lib/libdbh.so -lm -Wl,--rpath -Wl,/usr/local/xfce4/lib 
> -Wl,--rpath -Wl,/usr/local/xfce4/lib 

it _does_ have --rpath /usr/local/xfce4/lib at the end (remember, in 
this context, -R is the same as -rpath).  the problem is (presumably) 
that the -R/usr/lib is before the -rpath /usr/local/xfce4/lib.  libtool 
does some funky stuff when building the gcc commandline, so it may not 
be possible to get the behaviour you want.  annoying stuff like this is 
precisely why i firmly refuse to help people install xfce-stable in a 
normal system location and xfce-cvs elsewhere: you just can't get 
predictable results based on the variety of systems out there.

>   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).

my guess is that the -R/usr/lib is coming from libdbh's LDFLAGS (or some 
other related var).  not sure how/if this guess helps though...

> 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.

hehe... for starters, i'd never use the word "simple" in anywhere near 
the word "autoconf" ^_~.  the autoconf/automake stuff is arcane enough, 
but when you add libtool into the mix, things get even more convoluted, 
unfortunately.  i'm not so sure further digging will really yield you 
any useful results.  i haven't looked at the Makefile.am files in 
question, but maybe messing with the order of the @(whatever)_LDFLAGS@ 
and @(whatever)_LDADD@ lines will help.  good luck!

    -brian

>
> 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
>
> _______________________________________________
> Xfce4-dev mailing list
> Xfce4-dev at xfce.org
> http://lunar-linux.org/mailman/listinfo/xfce4-dev
>
>