Cabal doesn't use LD options when testing linking

[igloo]

When checking to see if the C libraries are available, Cabal isn't using the LD options that it has been given.

This example is using GHC's ghc-cabal program, but that's just a thin wrapper around the Cabal library. It looks like it's in checkForeignDeps in Distribution.Simple.Configure that it goes wrong. Note that --ld-options="-L/usr/local/lib " is passed, but not used in the gcc commands that do the linking.

$ "inplace/bin/ghc-cabal" configure --with-ghc="/home/kili/src/ghc/ghc-head/inplace/bin/dummy-ghc" --with-ghc-pkg="/home/kili/src/ghc/ghc-head/inplace/bin/ghc-pkg" --with-gcc="gcc" --configure-option=--with-cc="gcc" --with-hscolour="/usr/local/bin/HsColour" --configure-option=CFLAGS="-O -I/usr/local/include  " --configure-option=LDFLAGS="-L/usr/local/lib  " --gcc-options="-O -I/usr/local/include  " --ld-options="-L/usr/local/lib " -v3  -- dist-install libraries/integer-gmp
[boring stuff skipped]
("sh",["configure","--with-compiler=ghc","--with-cc=gcc","CFLAGS=-O -I/usr/local/include  ","LDFLAGS=-L/usr/local/lib  "])
checking build system type... x86_64-unknown-openbsd4.5
checking host system type... x86_64-unknown-openbsd4.5
checking target system type... x86_64-unknown-openbsd4.5
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking for __gmpz_fdiv_qr in -lgmp... yes
configure: creating ./config.status
config.status: creating integer-gmp.buildinfo
config.status: creating gmp/config.mk
Reading parameters from ./integer-gmp.buildinfo
("/usr/bin/gcc",["-O","-I/usr/local/include","/tmp/2499.c","-o","/tmp/2499","-O","-I/usr/local/include","-D__GLASGOW_HASKELL__=611","-I.","-I/home/kili/src/ghc/ghc-head/includes","-I/home/kili/src/ghc/ghc-head/libffi/build/include","-lgmp"])
/usr/bin/gcc returned ExitFailure 1 with error message:
/usr/bin/ld: cannot find -lgmp
collect2: ld returned 1 exit status
("/usr/bin/gcc",["-O","-I/usr/local/include","/tmp/2499.c","-o","/tmp/2499","-lgmp"])
/usr/bin/gcc returned ExitFailure 1 with error message:
/usr/bin/ld: cannot find -lgmp
collect2: ld returned 1 exit status
("/usr/bin/gcc",["-O","-I/usr/local/include","/tmp/2499.c","-o","/tmp/2499","-lgmp"])
/usr/bin/gcc returned ExitFailure 1 with error message:
/usr/bin/ld: cannot find -lgmp
collect2: ld returned 1 exit status
("/usr/bin/gcc",["-O","-I/usr/local/include","/tmp/2499.c","-o","/tmp/2499","-c","-O","-I/usr/local/include","-D__GLASGOW_HASKELL__=611","-I.","-I/home/kili/src/ghc/ghc-head/includes","-I/home/kili/src/ghc/ghc-head/libffi/build/include"])
ghc-cabal: Missing dependency on a foreign library:
* Missing C library: gmp
This problem can usually be solved by installing the system package that
provides this library (you may need the "-dev" version). If the library is
already installed but in a non-standard location then you can use the flags
--extra-include-dirs= and --extra-lib-dirs= to specify where it is.

[igloo]

Initially reported  here in  this thread on libraries@.

[kili]

Additional notes: it would be really nice if Cabal would support some environment variables also supported by autoconf, like CPPFLAGS, LDFLAGS, etc.

And, if possible, it should try to use results from an embedded autoconf run instead of repeating the test already done by autoconf (maybe via some buildinfo tricks).

[duncan]

Cabal support extra-lib-dirs and extra-include-dirs. If these are not respected by the internal lib tests then that's a bug.

These flags are not currently passed to configure but they should be. That's ticket #458.

[duncan]

Note, this does not actually pass any LD options to Cabal:

$ "inplace/bin/ghc-cabal" configure
--with-ghc="/home/kili/src/ghc/ghc-head/inplace/bin/dummy-ghc"
--with-ghc-pkg="/home/kili/src/ghc/ghc-head/inplace/bin/ghc-pkg"
--with-gcc="gcc" --configure-option=--with-cc="gcc"
--with-hscolour="/usr/local/bin/HsColour"
--configure-option=CFLAGS="-O -I/usr/local/include  "
--configure-option=LDFLAGS="-L/usr/local/lib  "
--gcc-options="-O -I/usr/local/include  "
--ld-options="-L/usr/local/lib " -v3 --
 dist-install libraries/integer-gmp

It passes clfags and ldflags direct to the ./configure script. It specifies extra flags to use when calling gcc ie "-O -I/usr/local/include " but since Cabal does not call ld directly for the lib tests, passing extra options to ld has no effect.

It'd be better to use:

--extra-lib-dirs=/usr/local/lib
--extra-include-dirs=/usr/local/include

[igloo]

Why is the Cabal user expected to know that Cabal isn't going to use ld when doing a link test?

Why is Cabal not using ld for link tests?

I think the fact that there is a special flag for this case is a red herring; we might have needed to pass another flag, e.g. --no-trampoline, for some reason.

[duncan]

Replying to igloo:

Why is the Cabal user expected to know that Cabal isn't going to use ld when doing a link test?

They are not.

Why is Cabal not using ld for link tests?

Why should it? Autoconf uses (g)cc for link tests.

I think the fact that there is a special flag for this case is a red herring; we might have needed to pass another flag, e.g. --no-trampoline, for some reason.

We have no options for extra generic cpp, cc or linker flags. The fact that you can always pass extra options whenever Cabal calls gcc or ld is somewhat orthogonal. The --PROG-option flags are there to save you the bother of writing a wrapper script for PROG, it does not mean that --PROG-option flags are somehow generic "cpp/cc/linker options" flags that will be used whenever we do some linking. They are literally only used when we call that PROG.

[sudish]

Replying to duncan:

It'd be better to use: {{{ --extra-lib-dirs=/usr/local/lib --extra-include-dirs=/usr/local/include }}}

I'm running into the same problem when trying to build ghc HEAD under OS X. In my case, I have some of the requisite libs under /opt/local/{include,lib} since I use MacPorts? to install them. The ghc build system fails to find them for the above reasons.

I tried to work around this by adding the following to ~/.cabal/config:

extra-include-dirs: /opt/local/include
extra-lib-dirs: /opt/local/lib

This seems to have no effect on the build. Does the in-place cabal not look at that config file?

More to the point, is there any way to pass in those dirs as defaults for the entire build? I.e., a way to add to ghc's in-place cabal's default search paths?

Thanks! -Sudish

PS: I do have a very ugly workaround: symlink all required headers and libs into dirs on gcc's default search paths. This is very fragile and error-prone, however, and I would rather not do that.

[elga]

*  simyo

[edouard]

A l'image du RIB bancaire, un code RIO est un identifiant unique attribue a la ligne et a un contrat client permettant d'identifier son demande de portabilite vers un autre operateur.  rio bouygues