Re: GHC include files
George Russell <[EMAIL PROTECTED]> wrote, > "Manuel M. T. Chakravarty" wrote: > > This is exactly what the `...-config' script that I was > > talking about is supposed to do. Now we can argue whether > > that should be part of `ghc' proper or an extra script. An > > extra script at least has the advantage that it is easier to > > maintain manual in case somebody moves a tree or so. > On the other hand, wrapping it into the ghc command will make a > version mismatch when someone moves files around slightly less likely. Yes, but given that ghc is not really a small package, you have to be careful when moving it around anyway, and the ghc driver is intimidating anyway - so, I am not sure, I really would want to add things to it... Manuel
Re: GHC include files
"Manuel M. T. Chakravarty" wrote: > This is exactly what the `...-config' script that I was > talking about is supposed to do. Now we can argue whether > that should be part of `ghc' proper or an extra script. An > extra script at least has the advantage that it is easier to > maintain manual in case somebody moves a tree or so. On the other hand, wrapping it into the ghc command will make a version mismatch when someone moves files around slightly less likely.
Re: GHC include files
Sven Panne <[EMAIL PROTECTED]> wrote, > It seems that the choice of the installation path depends more on > religious thoughts than technical necessities. The only thing I was > trying to say is that Joe User rarely needs 5 different versions of > GHC at the same time, so I prefer paths without version numbers for > my RPMs. Of course it makes sense for advanced GHC hackers to have > different versions lying around, but those people normally build GHC > from source anyway. And with the configure stuff relocating GHC is a > piece of cake, e.g. with > >./configure --prefix=/usr --libdir=/usr/lib/ghc > > binaries go into /usr/bin, the whole rest into /usr/lib/ghc. So what's > the problem? :-) Easy - I don't want to build an rpm which doesn't contain a version number in the path (for public use) only to compile ghc once more for myself with a version number in the path. So, better have everybody have the version number and share the binaries :-) Manuel
Re: GHC include files
George Russell <[EMAIL PROTECTED]> wrote, > "Manuel M. T. Chakravarty" wrote: > > > > Malcolm Wallace <[EMAIL PROTECTED]> wrote, > > > > > Can I propose a change to the -i / -I flags? Currently, the -idir (or > > > -Idir) options add a directory to the search path for imports. This > > > directory is either relative to the current dir, or absolute. My > > > suggestion is that it could also be used for "relative to a standard > > > installation directory". For instance, -Idata/edison would look first > > > in ./data/edison if it exists, then in $prefix/data/edison, where > > > $prefix has the value /usr/local/lib/ghc, or whatever. > I don't think this scheme would solve my problem at all. As has been pointed > out before, I can already get the GHC include files appended by calling "ghc" > and not "gcc". It's a good suggestion and one I shall probably follow. BUT > it is not ideal because (a) ghc seems to munge up its arguments rather a lot - > for example, it rearranges libraries which is a problem for Solaris when you > are using the system linker; (b) if you had a huge C program to which you > wanted to link a little Haskell, it would be silly to compile all the code > in the C program with ghc, and it would also be silly to compile some C code > with gcc and some with gcc. I'm not sure what would be best; perhaps > what I want is ghc options which won't do any compiling, but just tell me > where the include files and libraries are. So then I can type > GHC_INCLUDES = `$(GHC) -display-includes` > or something like that . . . This is exactly what the `...-config' script that I was talking about is supposed to do. Now we can argue whether that should be part of `ghc' proper or an extra script. An extra script at least has the advantage that it is easier to maintain manual in case somebody moves a tree or so. Manuel
Re: GHC include files
Sven Panne wrote: > binaries go into /usr/bin, the whole rest into /usr/lib/ghc. So what's > the problem? :-) None. But can I suggest that if it's completely trivial we have ghc -display-include-path and ghc -display-libraries if that's easy to do? EG on this system ghc -display-libraries -syslib lang might output -L/usr/local/pub-bkb/ghc/ghc-binary/lib -lHSrts -lHS -lHS_cbits -lHSlang -lHSlang_cbits (Or something similar to be fed to ld.) This would (a) solve my currently problem (which is admittedly rather trivial); (b) not force me to go through ghc when linking Glasgow Haskell to something else.
Re: GHC include files
It seems that the choice of the installation path depends more on religious thoughts than technical necessities. The only thing I was trying to say is that Joe User rarely needs 5 different versions of GHC at the same time, so I prefer paths without version numbers for my RPMs. Of course it makes sense for advanced GHC hackers to have different versions lying around, but those people normally build GHC from source anyway. And with the configure stuff relocating GHC is a piece of cake, e.g. with ./configure --prefix=/usr --libdir=/usr/lib/ghc binaries go into /usr/bin, the whole rest into /usr/lib/ghc. So what's the problem? :-) Cheers, Sven -- Sven PanneTel.: +49/89/2178-2235 LMU, Institut fuer Informatik FAX : +49/89/2178-2211 LFE Programmier- und Modellierungssprachen Oettingenstr. 67 mailto:[EMAIL PROTECTED]D-80538 Muenchen http://www.informatik.uni-muenchen.de/~Sven.Panne
Re: GHC include files
"Manuel M. T. Chakravarty" wrote: > > Malcolm Wallace <[EMAIL PROTECTED]> wrote, > > > Can I propose a change to the -i / -I flags? Currently, the -idir (or > > -Idir) options add a directory to the search path for imports. This > > directory is either relative to the current dir, or absolute. My > > suggestion is that it could also be used for "relative to a standard > > installation directory". For instance, -Idata/edison would look first > > in ./data/edison if it exists, then in $prefix/data/edison, where > > $prefix has the value /usr/local/lib/ghc, or whatever. I don't think this scheme would solve my problem at all. As has been pointed out before, I can already get the GHC include files appended by calling "ghc" and not "gcc". It's a good suggestion and one I shall probably follow. BUT it is not ideal because (a) ghc seems to munge up its arguments rather a lot - for example, it rearranges libraries which is a problem for Solaris when you are using the system linker; (b) if you had a huge C program to which you wanted to link a little Haskell, it would be silly to compile all the code in the C program with ghc, and it would also be silly to compile some C code with gcc and some with gcc. I'm not sure what would be best; perhaps what I want is ghc options which won't do any compiling, but just tell me where the include files and libraries are. So then I can type GHC_INCLUDES = `$(GHC) -display-includes` or something like that . . .
Re: GHC include files
On Tue, Feb 29, 2000 at 17:06:01 +, Marcin 'Qrczak' Kowalczyk wrote:
> BTW, I see lack of standard way of conveniently installing a Haskell
> library. For example c2hs installs in its own subdirectory and provides a
> script c2hs-config which outputs compiler and linker flags necessary to
> link an application with c2hs libs. OK, but should every package provide
> its own script?
At least, the idea is flexible and those scripts are easily adaptable...
> Putting C headers in a standard place like /usr/include or
> /usr/local/include and C libraries in /usr/lib is convenient.
Not a good idea, if there is more than one version of a software installed
on a system...
> IMHO there should be a flag similar to -syslib which tells the compiler
> and linker to use a package of a given name from such standard
> directory (hoping that there will be no name clashes): search for
> interfaces there and link a library. Not depending on whether it is
> under /usr/lib or /usr/local/lib - packages themselves should not be
> required to separately announce where they reside.
>
> It's possible that a package requires some additional compiler flags when
> it is used.
the "script" solution addresses this problem, too...
(cf. `xxx-config--libs')
> Will ghc change interface format with each version? :-)
This is the biggest problem (and, interestingly, the least addressed :-)).
Especially for binary distribution builders, it's quite inconvenient to
rebuild every GHC-library on the system to match with the latest compiler
version :-(
I thought about a scheme similar to the tex-font generation (if the font is
"compiled" for a particular resolution (dpi), it's re-used; if not, it is
created).
[I'll describe that in another mail...]
On Wed, Mar 01, 2000 at 04:34:43 -0800, Simon Marlow wrote:
> What we need is a way for external library writers to be able to package up
> and distribute a library that will install onto a system with an existing
> GHC such that you can say '-syslib ' to get the new library. This is
> pretty straightforward, we just need to separate out the syslib
> configuration stuff from the driver, and write a (perl?) script to do the
> installation. The script would be part of GHC, and invoked as part of the
> library installation.
This would not address the .hi-file versionitis...
And what, if the library needs additional compiler flags?
On Wed, Mar 01, 2000 at 14:29:41 +0100, Sven Panne wrote:
> Just a few remarks and personal opinions from a RPM builder's view:
>
>* IMHO the whole /usr/local hierarchy is completely obsolete for
> and "real" programs should only be used for quick local hacks.
> => GHC should reside under /usr/{bin,lib,include}
... and the GNU/Hurd people try to obsolete the /usr tree IIRC :-)
... and there is the /opt tree (for big packages) ...
quoting FHS-pre2.1#4.6 "/usr/local : Local hierarchy":
[...]
This directory should always be empty after first installing a FHS-
compliant system. No exceptions to this rule should be made other than
the listed directory stubs.
Locally installed software should be placed within /usr/local rather
than /usr unless it is being installed to replace or upgrade software in
/usr.
[...]
So, /usr/local is perfectly ok for software that is not installed via a
package management system and should be the default for a source dist or
binary-tarballs[2].
[2] a single tarball bindist is _NO_ package management! (Go away,
slackware users! :-))
There is no single solution... that's one of the reasons, why autoconf
exists, right? :-) (Hi Sven, Manuel!) :-))
>> Include files, on the other hand, should really be in
>> /usr/local/include/ghc, so f.e. #include has a chance of
>> working. [...]
I'd favour a scheme, in which ghc can tell me, where the include files
reside: the perl driver already knows about the location, so why not adding
an option: `ghc --print-includedir'?
This would also be the cleanest solution, if there is more than one version
of ghc installed...
Honestly, if a project has more than two source files, I let `make' care
about dependencies etc. and
GHCINCLUDES := $(shell $(HC) --print-includedir)
[...]
%.o: %.hs
$(HC) $(GHCINCLUDES) $(MOREOPTIONS) $< -o $@
is not very complicated, is it?
On Wed, Mar 01, 2000 at 07:59:25 -0800, Simon Marlow wrote:
> In a package system the choice of installation directories is moot, as you
> point out. The only issue is whether several versions are allowed to
> co-exist.
There is also the possibility to have more than one _flavour_ of a specific
version installed, for example ghc-4.06 and ghc-4.06-debugging...
Cheers,
Michael
p.s.: I'm just browsing through my overflowing mail folders, sorry if I
miss some of the messages...
--
Lehrstuhl-Gärtnerei Michael Weber <[EMAIL PROTECTED]>
Lehrstuhl für Informatik II
RWTH Aachen
WWW: http://www-i2.informatik.rwth-aachen.de/Software/Haskell/
RE: GHC include files
Simon Marlow <[EMAIL PROTECTED]> wrote, > > Don't know about binary dists, but I compiled 4.06 from source and > > it did install directly in /usr/local/lib, which is IMHO not so good. > > Many files used by a single package should generally go to a separate > > subdirectory. I reran ./configure with some option to install in > > /usr/local/lib/ghc-4.06 to have less mess directly in /usr/local/lib. > > I think on reflection that /usr/local/lib/ghc or /usr/local/lib/ghc-4.06 > would be a better choice than /usr/local/lib. In fact, binary distributions > already use the latter. I like the use of a prefix including the program name and version number very much, as I usually have about three versions of ghc installed (the latest stable release, the stable release before that, and the current cvs version). I understand Sven's position on that matter, but only because some packages make a mess out of the installation doesn't mean that we can't find a nice way to let different versions co-exist. > Include files, on the other hand, should really be in > /usr/local/include/ghc, so f.e. #include has a chance of > working. That is indeed a problem. > > BTW, I see lack of standard way of conveniently installing a Haskell > > library. For example c2hs installs in its own subdirectory > > and provides > > a script c2hs-config which outputs compiler and linker flags necessary > > to link an application with c2hs libs. OK, but should every package > > provide its own script? > > I don't think so. Also, I don't think we should adopt a solution that > requires the programmer to know anything about how or where a particular > library is installed. > > I had in mind a slight generalisation of GHC's syslib mechanism. Currently > GHC's libraries (HsLibs) are split into about 7 categories, and you can > bring a given category into scope by saying, eg. '-syslib text' on the > command line. GHC knows about dependencies between libraries, so you don't > need to say '-syslib lang' as well, if text depends on lang. The ordering > is also unimportant. I will still have to use `c2hs-config'[1]. The point of `c2hs-config' is to provide a truely OS and compiler system-independent way of using C->HS. So, unless the Haskell language definition enforces a fixed policy on library organisation, the need for `c2hs-config' won't go away. In fact, the concept behind `c2hs-config' is not my own idea. It is the mechanism used by the GTK+ and Gnome libraries - ie, even C libraries run into essentially the same problems as we do. There are quite a number of subtleties involved here: * How do I get the version of a library? (I just use `c2hs-config --version'.) * How can I have two versions of the same library installed? (With `c2hs-config' they can be installed with different prefixes.) * How can I select between different versions of one library? Eg, how can I have ./configure --cool-lib= style options in a program using the library. (With `c2hs-config', you just provide the path to the c2hs-config script you want - the script knows the rest.) * How can I handle multi-language programs/libraries (eg, mixed C and Haskell code)? (The `...-config' script gets different flags for the different languages involved.) * How can I select between different capabilities of my library (with or without threads or so)? (`gtk-config' is called with or without the `gthread' argument). I don't know of any other configuration mechanism that handles all these things gracefully. Cheers, Manuel [1] For those who don't know how `c2hs-config' works: http://www.cse.unsw.edu.au/~chak/haskell/c2hs/docu/c2hs-2.html#ss2.1
Re: GHC include files
Malcolm Wallace <[EMAIL PROTECTED]> wrote, > Can I propose a change to the -i / -I flags? Currently, the -idir (or > -Idir) options add a directory to the search path for imports. This > directory is either relative to the current dir, or absolute. My > suggestion is that it could also be used for "relative to a standard > installation directory". For instance, -Idata/edison would look first > in ./data/edison if it exists, then in $prefix/data/edison, where > $prefix has the value /usr/local/lib/ghc, or whatever. > > I think this is a reasonably straightforward means to allow > hierarchical library organisation. Plus, as of about two weeks ago, > nhc98 (in CVS) implements something similar to this feature. > > However, -i / -I only covers imports, it doesn't cover linking. Hence, > I also propose to extend the -L flag in the same way. -Ldir usually > adds a relative or absolute directory to the link search path, so > the same extension would allow "-Ldata/edison -ledison" to search for > both ./data/edison/libedison.a and $prefix/data/edison/libedison.a. The disadvantage of this scheme is that you can get into trouble as soon as you (accidentally) name one of your local directories the same as one of the system directories. With system directories like `posix', `lang', `num', `net', etc a collision is only a matter of time, I think. Cheers, Manuel
RE: GHC include files
> Just a few remarks and personal opinions from a RPM builder's view:
>
>* IMHO the whole /usr/local hierarchy is completely obsolete for
> and "real" programs should only be used for quick local hacks.
> => GHC should reside under /usr/{bin,lib,include}
I'd rather say that the use of /usr/local is system dependent. The BSD
folks for example have a nice clear scheme: everything in /usr is part of
the base system, everything in /usr/local comes from the ports tree.
In a package system the choice of installation directories is moot, as you
point out. The only issue is whether several versions are allowed to
co-exist. Either choice seems reasonable to me.
Cheers,
Simon
Re: GHC include files
I must admit I'm surprised by the reaction to my suggestion. Here /usr is shared between lots of machines and there is no question of my installing GHC in /usr/bin or anything like it. (The few system adminstrators here are all honest, overworked, and sadly incorruptible.) My original problem was that GHC installs the include files in /lib/ghc-4.06/includes meaning you have to know the version number as well as the prefix. I suppose this makes sense where is in fact /usr, but I actually make depend on the version, so having to specify the version twice is redundant. At least my scheme means that (on the rare times when I can build from source . . .) I can store multiple CVS releases.
Re: GHC include files
Simon Marlow wrote:
> I think on reflection that /usr/local/lib/ghc or
> /usr/local/lib/ghc-4.06 would be a better choice than
> /usr/local/lib.
Just a few remarks and personal opinions from a RPM builder's view:
* IMHO the whole /usr/local hierarchy is completely obsolete for
and "real" programs should only be used for quick local hacks.
=> GHC should reside under /usr/{bin,lib,include}
* Using the file system as a DB and coding the version number
into the installation path is not good, either. If look at
existing Linux distributions closely, there is complete chaos
in this respect: Version numbers are often used below the
/usr/lib hierarchy, but not below /usr/bin or /usr/doc, so
there will be collisions from different versions anyway. Any
modern OS should have a decent package concept (RPM for Linux
and some other platforms, Solaris has its own package system
AFAIK), so this is mainly a non-problem.
* Most "normal" users of GHC (are there any ;-) are more than
happy if they get *one* version installed and running. And
power users can easily tweak GHC to reside everywhere they
like, anyway.
> In fact, binary distributions already use the latter.
Not mine, for the reasons above.
> Include files, on the other hand, should really be in
> /usr/local/include/ghc, so f.e. #include has a
> chance of working. [...]
sed ,/local,,g :-)
Cheers,
Sven
--
Sven PanneTel.: +49/89/2178-2235
LMU, Institut fuer Informatik FAX : +49/89/2178-2211
LFE Programmier- und Modellierungssprachen Oettingenstr. 67
mailto:[EMAIL PROTECTED]D-80538 Muenchen
http://www.informatik.uni-muenchen.de/~Sven.Panne
RE: GHC include files
> Don't know about binary dists, but I compiled 4.06 from source and > it did install directly in /usr/local/lib, which is IMHO not so good. > Many files used by a single package should generally go to a separate > subdirectory. I reran ./configure with some option to install in > /usr/local/lib/ghc-4.06 to have less mess directly in /usr/local/lib. I think on reflection that /usr/local/lib/ghc or /usr/local/lib/ghc-4.06 would be a better choice than /usr/local/lib. In fact, binary distributions already use the latter. Include files, on the other hand, should really be in /usr/local/include/ghc, so f.e. #include has a chance of working. > BTW, I see lack of standard way of conveniently installing a Haskell > library. For example c2hs installs in its own subdirectory > and provides > a script c2hs-config which outputs compiler and linker flags necessary > to link an application with c2hs libs. OK, but should every package > provide its own script? I don't think so. Also, I don't think we should adopt a solution that requires the programmer to know anything about how or where a particular library is installed. I had in mind a slight generalisation of GHC's syslib mechanism. Currently GHC's libraries (HsLibs) are split into about 7 categories, and you can bring a given category into scope by saying, eg. '-syslib text' on the command line. GHC knows about dependencies between libraries, so you don't need to say '-syslib lang' as well, if text depends on lang. The ordering is also unimportant. What we need is a way for external library writers to be able to package up and distribute a library that will install onto a system with an existing GHC such that you can say '-syslib ' to get the new library. This is pretty straightforward, we just need to separate out the syslib configuration stuff from the driver, and write a (perl?) script to do the installation. The script would be part of GHC, and invoked as part of the library installation. In the long term, I hope Haskell will get a hiearchical module namespace and we can do away with the -syslib option altogether. We're also working towards expanding the library collection to be a lot more comprehensive; we've now incorporated HaXml, for instance. > Simon Marlow has already explained why shared libraries are currently > impossible... A pity. Hope that at some time someone will anyway > do them, possibly not using standard Unix linker if problems are > specifically with it itself rather than with the concept. Good news on this front: due to a truly heroic effort on the part of Julian, STG-Hugs is just about able to load GHC-compiled modules, which means you can compile Main.hs into Main.o, and run it inside STG-Hugs against the compiled prelude/libraries etc. Strictly speaking it's dynamic linking, not shared libraries, but you still get the disk-space and link-time savings. If the linker were separated out from Hugs and included in GHC's RTS, we'd have a way to generate standalone dynamically-linked binaries. Cheers, Simon
Re: GHC include files
> > Maybe there should be a standard place to put Haskell interfaces and > > libraries/objects. As there can be many modules in a package and thus > > many interfaces, and collisions between module names are harmless in > > a case where both are not used in the same program, interfaces should > > probably go to a separate directories for each package. > > Yes, yes, yes!! Me3 :-) Can I propose a change to the -i / -I flags? Currently, the -idir (or -Idir) options add a directory to the search path for imports. This directory is either relative to the current dir, or absolute. My suggestion is that it could also be used for "relative to a standard installation directory". For instance, -Idata/edison would look first in ./data/edison if it exists, then in $prefix/data/edison, where $prefix has the value /usr/local/lib/ghc, or whatever. I think this is a reasonably straightforward means to allow hierarchical library organisation. Plus, as of about two weeks ago, nhc98 (in CVS) implements something similar to this feature. However, -i / -I only covers imports, it doesn't cover linking. Hence, I also propose to extend the -L flag in the same way. -Ldir usually adds a relative or absolute directory to the link search path, so the same extension would allow "-Ldata/edison -ledison" to search for both ./data/edison/libedison.a and $prefix/data/edison/libedison.a. So, to conclude, using a "standard" Haskell library would make the compiler command lines look something like: ghc -c MyProg.hs -idata/edison ghc -o MyProg MyProg.o -Ldata/edison -ledison which is not too painful, and matches C reasonably closely. Regards, Malcolm
Re: GHC include files
> Maybe there should be a standard place to put Haskell interfaces and > libraries/objects. As there can be many modules in a package and thus > many interfaces, and collisions between module names are harmless in > a case where both are not used in the same program, interfaces should > probably go to a separate directories for each package. Yes, yes, yes!! It might be worth considering something like Perl's system: the user/administrator sets an environment variable giving a search path for libraries, and includes something like $HOME/lib/site_perl or /usr/local/lib/perl. When a program requests a module, it is searched for in the appropriate subtree of all the directories listed in this variable (plus the standard places). Of course, Perl has a hierarchical namespace for modules, rather than a flat one, so conflicts are a little less likely; but this could still be useful anyway. JAP\010HH... --KW 8-) -- : Keith Wansbrough, MSc, BSc(Hons) (Auckland) ---: : PhD Student, Computer Laboratory, University of Cambridge, UK. : : Native of Antipodean Auckland, New Zealand: 174d47'E, 36d55'S. : : http://www.cl.cam.ac.uk/users/kw217/ mailto:[EMAIL PROTECTED] : ::
Re: GHC include files
Tue, 29 Feb 2000 10:24:34 +0100, George Russell <[EMAIL PROTECTED]> pisze:
> The latest binary distribution puts the GHC include files in
> "lib/ghc-4.06/includes", not "lib/includes" as older versions used to.
Don't know about binary dists, but I compiled 4.06 from source and
it did install directly in /usr/local/lib, which is IMHO not so good.
Many files used by a single package should generally go to a separate
subdirectory. I reran ./configure with some option to install in
/usr/local/lib/ghc-4.06 to have less mess directly in /usr/local/lib.
> This is a nuisance, because it means that there isn't any way a
> Makefile can refer to the includes without coding in the GHC version.
You can call ghc to compile C files. They will get the necessary
options.
BTW, I see lack of standard way of conveniently installing a Haskell
library. For example c2hs installs in its own subdirectory and provides
a script c2hs-config which outputs compiler and linker flags necessary
to link an application with c2hs libs. OK, but should every package
provide its own script?
Putting C headers in a standard place like /usr/include or
/usr/local/include and C libraries in /usr/lib is convenient.
Looks like a contradiction for my statement in the first paragraph,
but here many programs use them; it's inconvenient to design each
time another script which tells Makefiles what options to use.
Maybe there should be a standard place to put Haskell interfaces and
libraries/objects. As there can be many modules in a package and thus
many interfaces, and collisions between module names are harmless in
a case where both are not used in the same program, interfaces should
probably go to a separate directories for each package.
IMHO there should be a flag similar to -syslib which tells the compiler
and linker to use a package of a given name from such standard
directory (hoping that there will be no name clashes): search for
interfaces there and link a library. Not depending on whether it is
under /usr/lib or /usr/local/lib - packages themselves should not be
required to separately announce where they reside.
It's possible that a package requires some additional compiler flags
when it is used. For example linking packages or syslibs or C libs
it depends on. So maybe the package's subdirectory under standard
Haskell directory could contain a file describing additional compiler
and linker options needed. Particularly the -l option which links
the relevant library would be simply there.
Will ghc change interface format with each version? :-) This is what
makes reuse harder - not to say that there are other incompatibilities:
fromInt/toInt, syslib reorganization, Haskell language versions,
evolving FFI - ugh, there is only a little chance that a random package
like gtk+hs or TclHaskell will still compile without tweaking under
a new ghc version.
For C there are plenty of libraries, and in simple cases I only add
#include, linker's -l option and just use it. Haskell has much better
module system, but in ghc making packages is still inconvenient. I
hope that at some time there will be many Haskell libraries to choose
from too, but they need some infrastructure to maintain packages
conveniently.
Simon Marlow has already explained why shared libraries are currently
impossible... A pity. Hope that at some time someone will anyway
do them, possibly not using standard Unix linker if problems are
specifically with it itself rather than with the concept.
--
__("$ P+++ L++>$ E-
^^ W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK 5? X- R tv-- b+>++ DI D- G+ e> h! r--%>++ y-
RE: GHC include files
> The latest binary distribution puts the GHC include files in > "lib/ghc-4.06/includes", not "lib/includes" as older versions used to. > This is a nuisance, because it means that there isn't any way a > Makefile can refer to the includes without coding in the GHC version. > Or is there? One needs access to the include files to get > at, for example, > Stg.h I wasn't aware that anything had changed; perhaps you used to use 'make install' instead of a binary distribution? You're right, for certain things you might need to get at the include files, so they should be in a more standard place. Like /usr/local/include/ghc, or something. Cheers, Simon
