Ticket #1798 (closed feature request: duplicate)

Opened 10 months ago

Last modified 7 months ago

add better framework support to ghc

Reported by: guest Assigned to:
Priority: normal Milestone: 6.10 branch
Component: Compiler Version: 6.6.1
Severity: normal Keywords:
Cc: Christian.Maeder@dfki.de Difficulty: Unknown
Test Case: Architecture: Multiple
Operating System: MacOS X

Description

ghc should be enabled to find a framework at runtime even in a user's home directory.

Currently ghci cannot load a framework from a user's home directory. (ghci may find a framework in a directory given under frameworkDirs in a package.conf, though)

If ghc would find the path to a framework `Bla' (at runtime) it could generate proper include and link options as follows.

Be <fpath> the path to the directory Bla.framework (containing framework Bla) then 

-I<fpath>/Bla.framework/Headers

should be added as include-path for header files. 

-F<fpath> -framework Bla

are the linker flags and 

<fpath>/Bla.framework/Bla

is the dynamic library to be loaded by dlopen.

Currently only "-framework Bla" is passed to linker and the dynamic linker tries to find the framework under /Library/Frameworks, /System/Library/Frameworks and directories (that must be known at build time) under frameworkDirs.

Currently C-Header files are only found if they are included in source files as: 

#include <Bla/blaheader.h>

This is rather unportable (as it only works on Macs) and requires library writers to create code (and configure stuff) like: 

#if defined(HAVE_FRAMEWORK_GMP)
#include <GMP/gmp.h>
#else
#include <gmp.h>
#endif

(I'm not even sure if the recursive includes work for the GNUreadline framework. see #1395)

if "#include <Bla/blaheader.h>" should work with frameworks installed under <fpath> not being /Library/Frameworks or /System/Library/Frameworks then also -F<fpath> needs to be passed to the C-compiler. (But it is better to always only write "#include <blaheader.h>" and use the above include flag.)

By accident the GNUreadline framework can be dynamically loaded from a user's home directory because ghci itself loads this framework (provided the package.conf file does not mention the framework GNUreadline, see #1395)

All these disadvantages can be avoided by computing the <fpath> for every framework at runtime. (The code is almost there at the end of compiler/ghci/Linker.lhs)

Once this all works the next step would be to also add a proper include-path to hsc2hs as it is currently rather difficult to pass -I$HOME/Library/Frameworks/GNUreadline.framework/Headers to hsc2hs when building libraries/readline with Cabal!

Christian

Attachments

Linker.lhs (46.2 kB) - added by maeder on 12/13/07 10:08:23.
also finds frameworks in a user's home directory (if it exists)

Change History

11/05/07 15:11:39 changed by igloo

  • milestone set to 6.10 branch.

12/13/07 09:54:01 changed by thorkilnaur

Please refer to #1395 for a description of changes proposed for the ghc linker.

The issue of this ticket can be separated into:

  1. Improved framework support when running Haskell programs (dynamic linking of libraries in frameworks etc.)
  2. Improved framework support when compiling Haskell programs (looking for include files etc.)

I suggest that the present ticket be used for the first of these, determining the desired run time libraries. I will create a new ticket shortly to deal with the second, looking for include files at compile time.

Please feel free to shout if this is not appropriate.

Best regards Thorkil

12/13/07 10:06:34 changed by maeder

Ok, let me repeat my request to commit my changes (about 6 lines) to Linker.lhs (see #1395) which should be save under all circumstances. I'll happily re-attach this file to this ticket with all tabs and trailing whitespace removed. (A pity this change did not make it into ghc-6.8.2)

12/13/07 10:08:23 changed by maeder

  • attachment Linker.lhs added.

also finds frameworks in a user's home directory (if it exists)

12/13/07 13:28:14 changed by thorkilnaur

Thanks a lot, sorry about chasing you around like this. It really helps me to get things more separated.

Best regards Thorkil

(follow-up: ↓ 6 ) 12/17/07 11:23:43 changed by thorkilnaur

I can confirm that your Linker.lhs is closer to dyld with respect to the handling of frameworks than the original Linker.lhs: With the original Linker.lhs and a recent HEAD, if I remove /Library/Frameworks/GNUreadline and instead install a suitable $HOME/Library/Frameworks/GNUreadline, then ghci is able to run, but reports 

Loading package readline-1.0.1 ... can't load framework: GNUreadline (not found)

when asked to run this program: 

module Main where
  import System.Console.Readline as Readline
  main = Readline.initialize

With your changed Linker.lhs, the program runs without complaints. So based on that, I would say that your change makes sense.

While performing these tests, I noticed that dyld apparently also looks for frameworks in the current directory. Perhaps judah - with dyld.cpp (see http://hackage.haskell.org/trac/ghc/wiki/OSXFrameworks) - can confirm this? In any case, there still seems to be some differences between the set of places that dyld and your Linker.lhs search for frameworks.

Best regards Thorkil

(in reply to: ↑ 5 ) 12/17/07 16:52:58 changed by judah

Replying to thorkilnaur:

While performing these tests, I noticed that dyld apparently also looks for frameworks in the current directory. Perhaps judah - with dyld.cpp (see http://hackage.haskell.org/trac/ghc/wiki/OSXFrameworks) - can confirm this? In any case, there still seems to be some differences between the set of places that dyld and your Linker.lhs search for frameworks.

Good catch; I can confirm from dyld.cpp that it does look in the current directory. After browsing the source in more detail, I've updated that page with a couple more observations about dyld, as well as a link in case you want to look at that file yourself.

12/18/07 02:07:37 changed by maeder

We could easily add /Network/Library/Frameworks to defaultFrameworkPaths, to make it just a bit more similar to dyld.

01/18/08 01:59:49 changed by maeder

  • status changed from new to closed.
  • resolution set to duplicate.

let's discuss this further in #2021