[MacPorts] #22423: radlib doesn't use MacPorts libraries

[M. Brooks Clark]

I don't see why raddebug is linking with /usr/lib/libsqlite3.dylib.

The libtool line looks like this:

/bin/sh ../libtool --tag=CC   --mode=link /usr/bin/gcc-4.2  -O2 -arch x86_64 -L../src/.libs   -L/usr/lib -L/usr/local/lib  -L/opt/local/lib -o raddebug raddebug.o -lc -lm -lrad   -lsqlite3 -lm -lc 

libtool: link: /usr/bin/gcc-4.2 -O2 -arch x86_64 -o .libs/raddebug raddebug.o  -L/opt/local/var/macports/build/_Users_mbclark_Dropbox_ports_devel_radlib/work/radlib-2.8.4/src/.libs -L/usr/lib -L/usr/local/lib -L/opt/local/lib /opt/local/var/macports/build/_Users_mbclark_Dropbox_ports_devel_radlib/work/radlib-2.8.4/src/.libs/librad.dylib -lsqlite3 -lm -lc

Maybe I'm wrong here, but I thought the -L option added directories to the *beginning* of the search path, so shouldn't /opt/local/lib be first in the search path?



On Nov 10, 2009, at 6:34 PM, Ryan Schmidt wrote:

> 
> On Nov 9, 2009, at 22:32, Thomas de Grivel wrote:
> 
>> 2009/11/10 M. Brooks Clark <brooks at clarksonline.net>:
>>> Any suggestions for how I can get it to look for the libs in /opt/local/lib
>>> before it finds the ones in /usr/lib?
>> 
>> Would adding something like this be sufficient ?
>> 
>> configure.cflags-append   -I${prefix}/include
> 
> MacPorts already puts -I${prefix}/include into cppflags. The above would only be useful for software that doesn't respect cppflags.
> 
>> configure.ldflags-append  -L${prefix}/lib
> 
> MacPorts already sets this. Perhaps the software ignores ldflags.
>