[Top][All Lists]

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

Mac OS X library path woes / issues / complaints

From: tom fogal
Subject: Mac OS X library path woes / issues / complaints
Date: Tue, 26 Jul 2005 14:57:29 -0400

Hi all, I'm trying to make a project that uses the GNU scientific
library, and having trouble getting it to build comfortable on the Mac.

The problem is the location of the GSL libraries. When building from
source, they are put (appropriately, at least IMHO) in /usr/local/lib.
Darwinports puts them in /opt/local/lib, which makes me cringe a little
but i'll acquiesce it. The problem is that neither of these directories
is part of the standard Mac OS X library search paths. Thus the
AC_CHECK_LIB tests are failing because they cannot find the appropriate

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
because of darwinports' choice of path, this might fall under the
'jumping through special hoops' category, but downloading the source
and installing manually (w/o a --prefix) puts things in /usr/local/lib.

On a system with GNU ld, I would have no problem telling my users that
/usr/local/lib should be in their library search paths to compile my
software. However I cannot seem to find a Mac OS X equivalent of
/etc/ I've come across DYLD_LIBRARY_PATH and of course
LD_LIBRARY_PATH from google searches, but these don't even seem to work
as I would expect:

[DY]LD_LIBRARY_PATH="/opt/local/lib" ./configure

still fails, and config.log shows a command line which doesn't even
include these paths.

If I go the LDFLAGS route, I still end up having the same issue with
includes too. Now users must specify two paths by hand on the command
line, for a library they might not even know exists! I feel like I
should just be including a 'makefile' with some docs that say, "edit
the first 10 lines to suit your system...".

How have other people solved this? I'm finding it hard to accept that I
must tell OS X users that a significant majority of them should be
specifying environment variables on the ./configure line. I don't
expect most people will even start scouring through the docs if they
find it doesn't build right off.
On the other hand, I don't know how to work around OS X's strange
linker and unconfigurable default search paths. It seems very strange
to me that the Mac folk would design it this way; could someone please
point out what I'm missing?

Any other thoughts / opinions / ideas / solutions / rants?


reply via email to

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