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

[tom fogal]

 <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
-Idir2'?

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?

-tom