#2933: LDFLAGS ignored by build system
--------------------+-------------------------------------------------------
Reporter:  duncan   |          Owner:                  
    Type:  bug      |         Status:  new             
Priority:  normal   |      Component:  Build System    
 Version:  6.10.1   |       Severity:  normal          
Keywords:           |       Testcase:                  
      Os:  Solaris  |   Architecture:  Unknown/Multiple
--------------------+-------------------------------------------------------
 I have required libs installed in `/opt/csw/lib` which is not on the
 ordinary system linker path. This includes things like `libgmp` etc. That
 means that to link ghc I want to pass `-R/opt/csw/lib` so that at runtime
 I do not need to set `LD_LIBRARY_PATH`.

 The `./configure --help` mentions `LDFLAGS` however this is ignored. When
 building gcc the equivalent makes everything work out fine. It would be
 nice if this were supported.

 Note also that `--with-gmp-includes` and `--with-gmp-libraries` are only
 half helpful. They add -L and -I options during the build only. That lets
 ghc link stuff using gmp. There are still two problems however:

  * Running such programs does not work if the gmp lib dir is not on the
 standard runtime linker path (which is quite likely given that it was not
 on the standard compile-time linker path).
  * It does not cause the final built ghc to automatically use
 -L/path/to/gmp/lib. Again I think if it's using `-L/path/to/gmp/lib` it
 should also use `-R/path/to/gmp/lib` or it'll link but not run.

 Some people claim that -R is evil. If we think it is evil and we choose
 not to use it for `--with-gmp-includes` and `--with-gmp-libraries` then
 those two become less than useful and it becomes more important to support
 `LD_OPTIONS`/`LDFLAGS` properly so that distros like the Solaris CSW can
 use it. For example, see http://www.opencsw.org/standards/pkg-walkthrough
 which recommends:
 {{{
 export LD_OPTIONS='-R/opt/csw/lib/$ISALIST -R/opt/csw/lib -L/opt/csw/lib'
 }}}

 Note: the workaround is to modify the driver script of the bootstrapping
 ghc and add `-optl-R/the/extra/lib` and then do the same for the script
 template that will get used by the stage1/2 inplace and final ghc, or to
 temporarily use LD_LIBRARY_PATH and modify the final ghc driver script
 during/after install.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2933>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Reply via email to