Cabal doesn't use LD options when testing linking #557

Closed
bos opened this Issue May 24, 2012 · 8 comments

Comments

Projects
None yet
3 participants
Contributor

bos commented May 24, 2012

(Imported from Trac #564, reported by @igfoo on 2009-06-24)

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.
Contributor

bos commented May 24, 2012

(Imported comment by @igfoo on 2009-06-24)

Initially reported here in this thread on libraries@.

Contributor

bos commented May 24, 2012

(Imported comment by kili on 2009-06-24)

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).

Contributor

bos commented May 24, 2012

(Imported comment by @dcoutts on 2009-06-24)

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.

Contributor

bos commented May 24, 2012

(Imported comment by @dcoutts on 2009-06-26)

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
Contributor

bos commented May 24, 2012

(Imported comment by @igfoo on 2009-06-26)

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.

Contributor

bos commented May 24, 2012

(Imported comment by @dcoutts on 2009-06-26)

Replying to @igfoo:

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.

Contributor

bos commented May 24, 2012

(Imported comment by sudish on 2009-06-27)

Replying to @dcoutts:

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.

jsl commented Feb 24, 2015

Given that there is no activity on this ticket since 2009, I propose closing. Please re-open, or create a new ticket if this problem persists.

/cc @tibbe

tibbe closed this Feb 24, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment