[Top][All Lists]

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

Re: Mac OS X library path woes / issues / complaints

From: tom fogal
Subject: Re: Mac OS X library path woes / issues / complaints
Date: Thu, 28 Jul 2005 10:53:31 -0400

 <address@hidden>Bob Friesenhahn writes:
>On Wed, 27 Jul 2005, Noah Misch wrote:
>> On Tue, Jul 26, 2005 at 02:57:29PM -0400, tom fogal wrote:
>>> Of course, the user has the option of specifying
>>> LDFLAGS="/opt/local/lib" (or whatever) on their ./configure line, and
>>> then the configure script finishes. I am of the opinion (and correct me
>>> if I'm wrong) that unless the user jumped through special hoops when
>>> compiling/installing software, they should not have to jump through
>>> special hoops for other software to utilize that install. Arguably
>> The portable way to configure a package that uses another package installed 
>> with
>> --prefix=$other is `./configure CPPFLAGS=-I$other/include 
>> LDFLAGS=-L$other/lib'.
>> Perhaps INSTALL should document that invocation pattern.  Even so, the need 
>> is
>> common enough to justify providing a shorthand.  I do have a solution in 
>> mind.
>> I hope to be able to contribute it real soon now.
>It is easy for a configure script to extend CPPFLAGS and LDFLAGS 
>itself based on the prefix but this can cause problems for the user 
>since then the user loses control over the header and linking search 
>path ordering.  It is important to ensure that the person doing the 
>install retains control.

Well it sounds like there is no good solution to this then =(

I could try adding -I and -L directories, and make sure they always go
at the end of whatever the user specifies. Can I make the assumption
that all compilers will search dir1 before dir2 when given 'cc -Idir1

Of course, this also leaves some users who have multiple copies
installed to believe my script found the correct one, and unwittingly
compile with the wrong library. Also it means I have to keep on top of
where different packagers install things to, which seems like a lot of
work / effort on the part of a package maintainer.

Fortunately I've just noticed that gsl comes with a 'gsl-config'
script. This helps me find directories, but with multiple GSL libraries
installed I still could run into the issue of 'choosing' the wrong
gsl-config script, and thus forcing a particular version of the library
on my users. Maybe I could add an AC_ARG_WITH an option to specify the
gsl-config path...

Well it sounds like I have a workable solution to my current issue, but
it relies on the library packager of the library I am using being
'good' and setting up a pkgconfig or <pkg>-config script. Perhaps I
should be asking / moving this thread to the libtool mailing list, but
is there any way we could have some part of the autotools suite
automagically generate a script when it sees a library is being built?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]