When I am running make distcheck, one library (lib2 in this example) is not being installed because it requires lib1.
Is there any way to mandate the order of library installation?
Makefile.am:
lib_LTLIBRARIES = libTwo.la libOne.la
libOne_la_SOURCES = lib/one/example.cpp \
lib/one/example.h
libTwo_la_SOURCES = lib/two/Example2.cpp \
lib/two/Example2.h
libTwo_la_CPPFLAGS = -I$(srcdir)/lib/one
libTwo_la_LIBADD = libOne.la
I am using:
RedHatEnterpriseServer 5.5
automake (GNU automake) 1.9.6
*Edit: * Here is what I am seeing on the make distcheck output.
/usr/bin/ld: cannot find -lOne
collect2: ld returned 1 exit status
libtool: install: error: relink `libTwo.la' with the above command before installing it
/bin/sh ./libtool --mode=install /usr/bin/install -c 'libOne.la' '/tmp/xx-x-yy-21346 /home/foo/commonlib-1.0/_inst/lib/libOne.la'
Try exchanging:
lib_LTLIBRARIES = libTwo.la libOne.la
for:
lib_LTLIBRARIES = libOne.la libTwo.la
IIRC, the order in lib_LTLIBRARIES matters at install time.
Related
I'm using libtool (version 2.4.6) for creating a simple shared library
under GNU/Linux.
In my specific case, portability is not as important as simplicity: I don't
want to use the whole Autotools suite, nor CMake. I just want a simple
Makefile which can compile a shared library and install it properly.
I've got a couple of variables definitions, which follow the
conventions of GNU Make
prefix ?= /usr/local
exec_prefix ?= $(prefix)
libdir ?= $(exec_prefix)/lib
I want to support an install target, and I believe it should be roughly
like this:
LIBTOOL_LIB := libxyz.la
install: target = $(abspath $(DESTDIR))
install: all
mkdir -p $(target)/$(libdir)
libtool --mode=install install $(LIBTOOL_LIB) $(target)/$(libdir)
libtool --mode=finish $(target)/$(libdir)
If I run make install DESTDIR=./test I get the following message:
mkdir -p /yadayada/src/test//usr/local/lib
libtool --mode=install install libtrullallero.la /yadayada/src/test//usr/local/lib
libtool: install: install .libs/libtrullallero.so.0.0.0 /yadayada/src.so.0.0.0
libtool: install: (cd /yadayada/src.so.0; }; })
libtool: install: (cd /yadayada/src.so; }; })
libtool: install: install .libs/libtrullallero.lai /yadayada/src.la
libtool: install: install .libs/libtrullallero.a /yadayada/src.a
libtool: install: chmod 644 /yadayada/src.a
libtool: install: ranlib /yadayada/src.a
libtool: warning: remember to run 'libtool --finish /usr/local/lib'
libtool --mode=finish /yadayada/src/test//usr/local/lib
libtool: finish: PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/sbin" ldconfig -n /yadayada/src/test//usr/local/lib
----------------------------------------------------------------------
Libraries have been installed in:
/yadayada/src/test//usr/local/lib
If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the '-LLIBDIR'
flag during linking and do at least one of the following:
- add LIBDIR to the 'LD_LIBRARY_PATH' environment variable
during execution
- add LIBDIR to the 'LD_RUN_PATH' environment variable
during linking
- use the '-Wl,-rpath -Wl,LIBDIR' linker flag
- have your system administrator add LIBDIR to '/etc/ld.so.conf'
See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
----------------------------------------------------------------------
I guess I deserve this notification, since I'm installing outside the
regular library path. This is by the way the same message I would get in a
Autotools-based project, should I set a --prefix in some arbitrary path at
./configure.
There are however some weird things:
If I run make install as root (within a container, of course), without
defining DESTDIR, I get the same kind of message. This does not feel
correct: this time I did not deserve it.
With or without DESTDIR, a call to ldconfig makes in my opinion no
sense at this point. And when I'm not running it as root, it should be
also ineffective, yet the program succeeds.
Lurking in the libtool documentation, I've found a
reference to the -inst-prefix-dir option,
which should allow me to have a DESTDIR-like behaviour.
Perhaps this is what I do wrong. However it behaves weirdly!
For starters, it seems to work only if specified at the end of the
--mode=install line. In fact, if I do this:
install: target = $(abspath $(DESTDIR))
install: all
mkdir -p $(target)/$(libdir)
libtool --mode=install install -inst-prefix-dir $(target) $(LIBTOOL_LIB) $(target)/$(libdir)
libtool --mode=finish $(target)/$(libdir)
…I clearly get a messy command line:
libtool: install: install -inst-prefix-dir /yadayada/libtrullallero/test/usr/local/lib/-inst-prefix-dir
install: invalid option -- 'i'
If I move -inst-prefix-dir to the end of the line, I just get another
wrong call to install:
mkdir -p /yadayada/src/libtrullallero/test//usr/local/lib
libtool --mode=install install libtrullallero.la /yadayada/src/libtrullallero/test
libtool: install: install .libs/libtrullallero.so.0.0.0 /yadayada/src/libtrullallero/test/libtrullallero.so.0.0.0
libtool: install: (cd /yadayada/src/libtrullallero/test && { ln -s -f libtrullallero.so.0.0.0 libtrullallero.so.0 || { rm -f libtrullallero.so.0 && ln -s libtrullallero.so.0.0.0 libtrullallero.so.0; }; })
libtool: install: (cd /yadayada/src/libtrullallero/test && { ln -s -f libtrullallero.so.0.0.0 libtrullallero.so || { rm -f libtrullallero.so && ln -s libtrullallero.so.0.0.0 libtrullallero.so; }; })
libtool: install: install .libs/libtrullallero.lai /yadayada/src/libtrullallero/test/libtrullallero.la
libtool: install: install /yadayada/src/libtrullallero/test/lib
install: omitting directory '/yadayada/src/libtrullallero/test//usr/local/lib'
Makefile:22: recipe for target 'install' failed
make: *** [install] Error 1
I must be doing something wrong, but I cannot spot it. Any hint?
I want to install perl Gtk2, and for this I need first to have Glib installed. I tried sudo cpanm Glib, but I get an error when compiling (I also tried downloading the .tar.gz source etc., with the same effect). I also tried with an older version of Glib. I’m on OS X 10.11 (El Capitan). Here’s the error :
error: '_GStaticAssertCompileTimeAssertion_0' declared as an array with a negative size
I don’t know how to fix it… Thanks a lot if anyone can do something for me !
(BTW, brew install glib works fine, but it seems the app that I’m trying to build and run — auto-multiple-choice, for instance — is looking for a Gtk2.pm somewhere. So, the ‘glib’ installed by Homebrew is of no help.)
Benjamin
p.-s. : below is the complete log, if it helps :
cpanm (App::cpanminus) 1.7042 on perl 5.018002 built for darwin-thread-multi-2level
Work directory is /Users/benjamin/.cpanm/work/1474765262.7331
You have make /usr/bin/make
You have LWP 6.05
You have /usr/bin/tar: bsdtar 2.8.3 - libarchive 2.8.3
You have /usr/bin/unzip
Searching Glib () on cpanmetadb ...
--> Working on Glib
Fetching http://www.cpan.org/authors/id/X/XA/XAOC/Glib-1.322.tar.gz
-> OK
Unpacking Glib-1.322.tar.gz
Entering Glib-1.322
Checking configure dependencies from META.json
Checking if you have ExtUtils::MakeMaker 6.58 ... Yes (6.66)
Checking if you have ExtUtils::PkgConfig 1.000 ... Yes (1.15)
Checking if you have ExtUtils::Depends 0.300 ... Yes (0.306)
Configuring Glib-1.322
Running Makefile.PL
Including generated API documentation...
Checking if your kit is complete...
Looks good
Writing Makefile for Glib
Writing MYMETA.yml and MYMETA.json
-> OK
Checking dependencies from MYMETA.json ...
Checking if you have ExtUtils::Depends 0.300 ... Yes (0.306)
Checking if you have ExtUtils::PkgConfig 1.000 ... Yes (1.15)
Checking if you have ExtUtils::MakeMaker 0 ... Yes (6.66)
Building and testing Glib-1.322
cp lib/Glib/CodeGen.pm blib/lib/Glib/CodeGen.pm
cp /Users/benjamin/.cpanm/work/1474765262.7331/Glib-1.322/typemap blib/arch/Glib/Install/typemap
cp lib/Glib/ParseXSDoc.pm blib/lib/Glib/ParseXSDoc.pm
cp doctypes blib/arch/Glib/Install/doctypes
cp devel.pod blib/lib/Glib/devel.pod
cp gperl_marshal.h blib/arch/Glib/Install/gperl_marshal.h
cp lib/Glib/MakeHelper.pm blib/lib/Glib/MakeHelper.pm
cp gperl.h blib/arch/Glib/Install/gperl.h
cp lib/Glib.pm blib/lib/Glib.pm
cp lib/Glib/Object/Subclass.pm blib/lib/Glib/Object/Subclass.pm
cp build/IFiles.pm blib/arch/Glib/Install/Files.pm
cp lib/Glib/GenPod.pm blib/lib/Glib/GenPod.pm
[ XS Glib.xs ]
[ CC Glib.c ]
In file included from Glib.xs:22:
In file included from ./gperl.h:37:
In file included from /usr/local/Cellar/glib/2.48.2/include/glib-2.0/glib-object.h:23:
In file included from /usr/local/Cellar/glib/2.48.2/include/glib-2.0/gobject/gbinding.h:28:
In file included from /usr/local/Cellar/glib/2.48.2/include/glib-2.0/glib.h:30:
In file included from /usr/local/Cellar/glib/2.48.2/include/glib-2.0/glib/galloca.h:32:
/usr/local/Cellar/glib/2.48.2/include/glib-2.0/glib/gtypes.h:422:3: error: '_GStaticAssertCompileTimeAssertion_0' declared as an array with a negative size
G_STATIC_ASSERT(sizeof (unsigned long long) == sizeof (guint64));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/local/Cellar/glib/2.48.2/include/glib-2.0/glib/gmacros.h:232:103: note: expanded from macro 'G_STATIC_ASSERT'
#define G_STATIC_ASSERT(expr) typedef char G_PASTE (_GStaticAssertCompileTimeAssertion_, __COUNTER__)[(expr) ? 1 : -1] G_GNUC_UNUSED
^~~~~~~~~~~~~~~
1 error generated.
make: *** [Glib.o] Error 1
-> FAIL Installing Glib failed. See
/Users/benjamin/.cpanm/work/1474765262.7331/build.log for details. Retry with --force to force install it.
This was posted to a GitHub issue.
I tracked down the problem by running:
cpanm --verbose --build-args=NOECHO=' ' Glib
so that I could see the specific compilation command that failed:
cc -c -I. -I/usr/local/Cellar/glib/2.50.0/include/glib-2.0 -I/usr/local/Cellar/glib/2.50.0/lib/glib-2.0/include -I/usr/local/opt/gettext/include -I/usr/local/Cellar/pcre/8.39/include -D_REENTRANT -arch x86_64 -arch i386 -g -pipe -fno-common -DPERL_DARWIN -fno-strict-aliasing -fstack-protector -Os -DVERSION=\"1.323\" -DXS_VERSION=\"1.323\" -o Glib.o "-I/System/Library/Perl/5.18/darwin-thread-multi-2level/CORE" Glib.c
Since the problem was something to do with mismatching sizeof's, I figured that the problem was that the architecture that Perl was building with does not the architecture that Homebrew's libglib-2.0 was built against.
The fix is to specify that you only want to build for x86_64 by setting the ARCHFLAGS environment variable:
ARCHFLAGS="-arch x86_64" cpanm --verbose Glib
This is all using the system Perl. If you want the install to work in the long run across system upgrades, you will want to install your own user Perl using either perlbrew or plenv.
I ran into the same issue.
Installing gtk+ as a prerequisite fixed it.
EDIT: If its TLDR, just skip to the bottom. Its where I ask: How do I configure an autotools project to use a static library?
I'm working with a couple of open source libraries, and I'm trying to run their test suite under Clang's sanitizers. To run under Clang sanitizers, we need to (1) specify some options, and (2) link static libraries from Clang's Compiler-RT as required. Note: there are no dynamic libraries or shared objects.
Setting the options is easy:
export DYLD_FALLBACK_LIBRARY_PATH=/usr/local/lib/clang/3.3/lib/darwin/
export CC=/usr/local/bin/clang
export CXX=/usr/local/bin/clang++
export CFLAGS="-g3 -fsanitize=address -fsanitize=undefined"
export CXXFLAGS="-g3 -fsanitize=address -fsanitize=undefined -fno-sanitize=vptr"
./configure
However, this will generate some archive warnings (when AR is run) and link errors (when LD is run) with undefined symbols. The message will be similar to:
libjpeg.a(jmemmgr.o): In function `do_sarray_io':
/home/jwalton/jpeg-6b/jmemmgr.c:695: undefined reference to
`__ubsan_handle_type_mismatch'
/home/jwalton/jpeg-6b/jmemmgr.c:695: undefined reference to
`__ubsan_handle_type_mismatch'
/home/jwalton/jpeg-6b/jmemmgr.c:696: undefined reference to
`__ubsan_handle_type_mismatch'
I know the libraries that need to be linked. For the sanitizers that I use, they are libclang_rt.asan_osx.a and libclang_rt.ubsan_osx.a (or libclang_rt.full-x86_64.a and libclang_rt.ubsan-x86_64.a on Linux).
To supply the libraries, I then export the following. Note: it is LIBS, and not LDLIBS as expected by most other make related tools.
export LIBS="/usr/local/lib/clang/3.3/lib/darwin/libclang_rt.asan_osx.a \
/usr/local/lib/clang/3.3/lib/darwin/libclang_rt.ubsan_osx.a"
This results in a configure problem of:
configure: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
...
Looking at config.log, it looks like two problems are occurring. First, the path is being butchered by changing from /usr/local/... to /Users/jwalton/.... And second, the filename is being butchered by changing from a static lib to a dynamic lib:
configure:3346: ./conftest
dyld: Library not loaded: /Users/jwalton/clang-llvm/llvm-3.3.src/Release+Asserts/lib/clang/3.3/lib/darwin/libclang_rt.asan_osx_dynamic.dylib
Referenced from: /Users/jwalton/libpng-1.6.7/./conftest
Reason: image not found
In another attempt, I tried using LDFLAGS:
export LDFLAGS="-L/usr/local/lib/clang/3.3/lib/darwin/"
export LIBS="libclang_rt.asan_osx.a libclang_rt.ubsan_osx.a"
That results in a similar error:
configure: error: in `/Users/jwalton/libpng-1.6.7':
configure: error: C compiler cannot create executables
And config.log:
configure:3209: /usr/local/bin/clang -g3 -fsanitize=address -fsanitize=undefined -L/usr/local/lib/clang/3.3/lib/darwin/ conftest.c libclang_rt.asan_osx.a libclang_rt.ubsan_osx.a >&5
clang: error: no such file or directory: 'libclang_rt.asan_osx.a'
clang: error: no such file or directory: 'libclang_rt.ubsan_osx.a'
And dropping the lib prefix and .a suffix from the LIBS results in:
configure:3209: /usr/local/bin/clang -g3 -fsanitize=address -fsanitize=undefined -L/usr/local/lib/clang/3.3/lib/darwin/ conftest.c clang_rt.asan_osx clang_rt.ubsan_osx >&5
clang: error: no such file or directory: 'clang_rt.asan_osx'
clang: error: no such file or directory: 'clang_rt.ubsan_osx'
And adding the -l to LIBS results in:
configure:3335: /usr/local/bin/clang -o conftest -g3 -fsanitize=address -fsanitize=undefined
-L/usr/local/lib/clang/3.3/lib/darwin/ conftest.c -lclang_rt.asan_osx -lclang_rt.ubsan_osx >&5
configure:3339: $? = 0
configure:3346: ./conftest
dyld: could not load inserted library: /Users/jwalton/libpng-1.6.7/./conftest
./configure: line 3348: 38224 Trace/BPT trap: 5 ./conftest$ac_cv_exeext
Finally, the -L argument is valid:
$ ls /usr/local/lib/clang/3.3/lib/darwin/
libclang_rt.10.4.a libclang_rt.ios.a
libclang_rt.asan_osx.a libclang_rt.osx.a
libclang_rt.asan_osx_dynamic.dylib libclang_rt.profile_ios.a
libclang_rt.cc_kext.a libclang_rt.profile_osx.a
libclang_rt.cc_kext_ios5.a libclang_rt.ubsan_osx.a
libclang_rt.eprintf.a
After all the background: how do I configure an autotools project to use a static library?
Bonus points: why has something so easy been made so difficult?
You need to add -fsanitize flags to LDFLAGS as well.
Shipping versions of GNU libtool do not pass -fsanitize=... arguments to the linker. You will need to update libtool with the patch from http://savannah.gnu.org/patch/?8775 Specifically:
diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index 0c40da0..b99b0cd 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
## -5362,10 +5362,11 ## func_mode_link ()
# -O*, -g*, -flto*, -fwhopr*, -fuse-linker-plugin GCC link-time optimization
# -specs=* GCC specs files
# -stdlib=* select c++ std lib with clang
+ # -fsanitize=* Clang memory and address sanitizer
-64|-mips[0-9]|-r[0-9][0-9]*|-xarch=*|-xtarget=*|+DA*|+DD*|-q*|-m*| \
-t[45]*|-txscale*|-p|-pg|--coverage|-fprofile-*|-F*|#*|-tp=*|--sysroot=*| \
-O*|-g*|-flto*|-fwhopr*|-fuse-linker-plugin|-fstack-protector*|-stdlib=*| \
- -specs=*)
+ -specs=*|-fsanitize=*)
func_quote_for_eval "$arg"
arg=$func_quote_for_eval_result
func_append compile_command " $arg"
As for getting libtool to accept a static library, you should be able to just include the full path to the static library on the command line, or you can use options like -L/usr/local/lib/clang/3.3/lib/darwin/ -lclang_rt.ubsan_osx. However, cfe should take care of the library magic for you once libtool tells it to use -fsanitize=... for linking.
As for the undefined symbol issue, if you are linking C++ objects, then you must use clang++ instead of clang. Otherwise you can get error such as:
/bin/bash libtool --tag=CC --mode=link clang-3.6 ... -fsanitize=undefined -o freeswitch ...
libtool: link: clang-3.6 ... -fsanitize=undefined -o .libs/freeswitch ./.libs/libfreeswitch.so ...
./.libs/libfreeswitch.so: undefined reference to `__ubsan_vptr_type_cache'
./.libs/libfreeswitch.so: undefined reference to `__ubsan_handle_dynamic_type_cache_miss'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
In the above case, the atrocious libtool used clang instead of clang++ because automake thought that you wanted to link a set of C objects (it does not understand that linking a libtool archive (libfreeswitch.la) using C++ means that a C++ linker is needed (note the --tag=CC). See also https://lists.debian.org/debian-mentors/2003/06/msg00004.html.
To work around this issue, follow the instructions at https://www.gnu.org/software/automake/manual/html_node/Libtool-Convenience-Libraries.html and add a (dummy/real) C++ source to your sources in your Makefile.am:
SUBDIRS = sub1 sub2 …
lib_LTLIBRARIES = libtop.la
libtop_la_SOURCES =
# Dummy C++ source to cause C++ linking.
nodist_EXTRA_libtop_la_SOURCES = dummy.cxx
libtop_la_LIBADD = \
sub1/libsub1.la \
sub2/libsub2.la \
…
I'm trying to compile and install GCC 4.8.2 in OS X 10.9. I followed the instructions here (http://gcc.gnu.org/wiki/InstallingGCC) to first run ./contrib/download_prerequesites and then ran configure and make from a directory different from the source. My build fails with error:
checking for suffix of object files... configure: error: in `/Users/prokilogrammer/temp/gcc-build482/x86_64-apple-darwin13.0.2/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
Apparently this problem would be solved if GCC's dependencies (GMP, MPC, MPFR) are properly installed (http://gcc.gnu.org/wiki/FAQ#configure_suffix). I checked and made sure they are correctly installed under /usr/local/lib & /usr/local/include directories.
Looking at config.log, I see the following errors:
configure:3565: checking for suffix of object files
configure:3587: /Users/prokilogrammer/temp/gcc-build482/./gcc/xgcc -B/Users/prokilogrammer/temp/gcc-build482/./gcc/ -B/usr/local/x86_64-apple-darwin13.0.2/bin/ -B/usr/local/x86_64-apple-darwin13.0.2/lib/ -isystem /usr/local/x86_64-apple-darwin13.0.2/include -isystem /usr/local/x86_64-apple-darwin13.0.2/sys-include -c -g -O2 conftest.c >&5
conftest.c:1:0: internal compiler error: Segmentation fault: 11
/* confdefs.h */
^
libbacktrace could not find executable to open
I am not sure if the segfault is because of the missing dependencies or a legit issue in gcc.
Have you guys experienced similar problems? Is there a solution/workaround?
PS: I have also tried setting LD_LIBRARY_PATH & DYLD_LIBRARY_PATH without any luck.
I've built GCC 4.8.2 on several Mavericks machines, but I chose a slightly different strategy. Specifically, I included the code for GMP, MPC, MPFR (and CLOOG and ISL) in the build directory. I used a script to quasi-automate it:
GCC_VER=gcc-4.8.2
tar -xf ${GCC_VER}.tar.bz2 || exit 1
cd ${GCC_VER} || exit
cat <<EOF |
cloog 0.18.0 tar.gz
gmp 5.1.3 tar.xz
isl 0.11.1 tar.bz2
mpc 1.0.1 tar.gz
mpfr 3.1.2 tar.xz
EOF
while read file vrsn extn
do
tar -xf "../$file-$vrsn.$extn" &&
ln -s "$file-$vrsn" "$file"
done
With that done:
mkdir gcc-4.8.2-obj
cd gcc-4.8.2-obj
../gcc-4.8.2/configure --prefix=$HOME/gcc/v4.8.2
make -j8 bootstrap
AFAICR, that was about all it took, with 4.8.1 and 4.8.2.
On OS X I'm trying to install the zlib prerequisite for haskell's Cabal. I get this error:
$ sudo ./Setup build
Preprocessing library zlib-0.5.0.0…
ld: library not found for -lgmp
collect2: ld returned 1 exit status
linking dist/build/Codec/Compression/Zlib/Stream_hsc_make.o failed
command was: /usr/bin/gcc -lz -L/sw/lib/ghc-6.8.3/lib/bytestring-0.9.0.1.1 -L/sw/lib/ghc-6.8.3/lib/array-0.1.0.0 -L/sw/lib/ghc-6.8.3/lib/base-3.0.2.0 -L/sw/lib/ghc-6.8.3 -lm -lgmp -ldl dist/build/Codec/Compression/Zlib/Stream_hsc_make.o -o dist/build/Codec/Compression/Zlib/Stream_hsc_make
The library -lgmp is found in /sw/lib, so I can run that command ("/usr/bin/gcc ...") successfully if I manually add -L/sw/lib. The problem is that sudo doesn't know about /sw/lib. Behold:
$ gcc -print-search-dirs | grep sw
libraries: =/lib/i686-apple-darwin9/4.0.1/:/lib/:/usr/lib/i686-apple-darwin9/4.0.1/:/usr/lib/:./i686-apple-darwin9/4.0.1/:./:/sw/lib/i686-apple-darwin9/4.0.1/:/sw/lib/:/usr/lib/gcc/i686-apple-darwin9/4.0.1/:/usr/lib/gcc/i686-apple-darwin9/4.0.1/:/usr/lib/gcc/i686-apple-darwin9/4.0.1/../../../../i686-apple-darwin9/lib/i686-apple-darwin9/4.0.1/:/usr/lib/gcc/i686-apple-darwin9/4.0.1/../../../../i686-apple-darwin9/lib/:/usr/lib/gcc/i686-apple-darwin9/4.0.1/../../../i686-apple-darwin9/4.0.1/:/usr/lib/gcc/i686-apple-darwin9/4.0.1/../../../
$ sudo gcc -print-search-dirs | grep sw
$
How do I tell the sudo version of gcc to look in /sw/lib for libraries? Do I add an environment variable on root's .bash_profile? If so, which one?
UPDATE:
There’s probably a more proper way to do this, but here’s what worked. I created a bash script with this in it:
#!/bin/sh
export LIBRARY_PATH=/sw/lib:$LIBRARY_PATH
./Setup build
And then I ran
$ sudo ./script.sh
That compiled zlib without complaining - hooray! Unfortunately cabal-install is still giving me the error:
$ ./Setup configure
Configuring cabal-install-0.6.2…
Setup: At least the following dependencies are missing:
zlib >=0.4 && <0.6
So I went back to the cabal-install dir (which is what I'm trying to do in the first place), and ran...
$ ./bootstrap.sh
...and that installed everything as expected.
Why you use sudo ever? You should not compile as super user. Compile as normal user and install as super user.
Try setting LDFLAGS=-L/sw/lib.
GHC now comes with an installer for OS X (Leopard, not sure about Tiger). The only issue is that if you use macports or fink, these will probably not see that you have GHC installed and try to install their own version of it.