[Hackage] #564: Cabal doesn't use LD options when testing linking
#564: Cabal doesn't use LD options when testing linking ----------------------------+----------------------------------------------- Reporter: igloo | Owner: Type: defect | Status: new Priority: high | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- 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. }}} -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/564 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#564: Cabal doesn't use LD options when testing linking ----------------------------+----------------------------------------------- Reporter: igloo | Owner: Type: defect | Status: new Priority: high | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: normal | Resolution: Keywords: | Difficulty: unknown Ghcversion: | Platform: ----------------------------+----------------------------------------------- Comment (by igloo): Initially reported [http://www.haskell.org/pipermail/libraries/2009-June/012006.html here] in [http://www.haskell.org/pipermail/libraries/2009-June/011978.html this] thread on libraries@. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/564#comment:1 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#564: Cabal doesn't use LD options when testing linking ----------------------------+----------------------------------------------- Reporter: igloo | Owner: Type: defect | Status: new Priority: high | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: normal | Resolution: Keywords: | Difficulty: unknown Ghcversion: | Platform: ----------------------------+----------------------------------------------- Comment (by 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). -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/564#comment:2 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#564: Cabal doesn't use LD options when testing linking ----------------------------+----------------------------------------------- Reporter: igloo | Owner: Type: defect | Status: new Priority: high | Milestone: Cabal-1.8 Component: Cabal library | Version: 1.6.0.1 Severity: normal | Resolution: Keywords: | Difficulty: unknown Ghcversion: | Platform: ----------------------------+----------------------------------------------- Changes (by duncan): * milestone: => Cabal-1.8 Comment: 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. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/564#comment:3 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#564: Cabal doesn't use LD options when testing linking ----------------------------+----------------------------------------------- Reporter: igloo | Owner: Type: defect | Status: new Priority: high | Milestone: Cabal-1.8 Component: Cabal library | Version: 1.6.0.1 Severity: normal | Resolution: Keywords: | Difficulty: unknown Ghcversion: | Platform: ----------------------------+----------------------------------------------- Comment (by 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 }}} -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/564#comment:4 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#564: Cabal doesn't use LD options when testing linking ----------------------------+----------------------------------------------- Reporter: igloo | Owner: Type: defect | Status: new Priority: high | Milestone: Cabal-1.8 Component: Cabal library | Version: 1.6.0.1 Severity: normal | Resolution: Keywords: | Difficulty: unknown Ghcversion: | Platform: ----------------------------+----------------------------------------------- Comment (by 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. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/564#comment:5 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#564: Cabal doesn't use LD options when testing linking ----------------------------+----------------------------------------------- Reporter: igloo | Owner: Type: defect | Status: new Priority: high | Milestone: Cabal-1.8 Component: Cabal library | Version: 1.6.0.1 Severity: normal | Resolution: Keywords: | Difficulty: unknown Ghcversion: | Platform: ----------------------------+----------------------------------------------- Comment (by duncan): Replying to [comment:5 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?
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-
Why should it? Autoconf uses (g)cc for link tests. 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. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/564#comment:6 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#564: Cabal doesn't use LD options when testing linking ----------------------------+----------------------------------------------- Reporter: igloo | Owner: Type: defect | Status: new Priority: high | Milestone: Cabal-1.8 Component: Cabal library | Version: 1.6.0.1 Severity: normal | Resolution: Keywords: | Difficulty: unknown Ghcversion: | Platform: ----------------------------+----------------------------------------------- Comment (by sudish): Replying to [comment:4 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. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/564#comment:7 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
participants (1)
-
Hackage