[GHC] #2021: let ghc find framework header files and link with frameworks located in $HOME/Library/Frameworks

GHC trac at galois.com
Mon Jan 7 13:30:16 EST 2008


#2021: let ghc find framework header files and link with frameworks located in
$HOME/Library/Frameworks
-----------------------------+----------------------------------------------
 Reporter:  maeder           |          Owner:             
     Type:  feature request  |         Status:  new        
 Priority:  normal           |      Milestone:             
Component:  Compiler         |        Version:  6.8.2      
 Severity:  normal           |     Resolution:             
 Keywords:                   |     Difficulty:  Easy (1 hr)
 Testcase:                   |   Architecture:  Multiple   
       Os:  MacOS X          |  
-----------------------------+----------------------------------------------
Comment (by thorkilnaur):

 I have not been able to find any mention in Apple documentation (man gcc,
 man ld,
 http://developer.apple.com/documentation/MacOSX/Conceptual/BPFrameworks/BPFrameworks.pdf)
 that $HOME/Library/Frameworks is to be searched automatically. In fact,
 the latter document says
 {{{
 Applications that link to frameworks in other directories, such as
 ~/Library/Frameworks or /Network/Library/Frameworks, must specify the
 exact path to the framework at build time so that the dynamic linker can
 find it.
 }}}
 I do not believe that GHC should provide such an additional service: In
 some cases, it will cause confusion and additional work.

 If the problem is that GHC is not able to pass enough framework-related
 parameters to gcc, ld, and possibly other programs, then that is the
 problem to be solved. That would also allow someone to store local
 frameworks in any desired location, in addition to
 $HOME/Library/Frameworks.

 As I have mentioned elsewhere (http://haskell.org/pipermail/glasgow-
 haskell-users/2008-January/014022.html), I see a need to figure out a
 comprehensive solution to this framework-related matter. I do not
 presently see such a comprehensive solution. Until I do, I am unable to
 tell whether any particular step goes in the right direction or is merely
 a temporary hack to get out of a tight spot.

 Best regards
 Thorkil

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2021#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler


More information about the Glasgow-haskell-bugs mailing list