- Glasgow-haskell-users

possible readline license problem with ghc and -package util
by Martin Norbäck 12 Jun '02

12 Jun '02

I have a problem with the readline license that applies to ghc, and programs compiled with ghc. The readline library is under the GPL license. This means that any program (including ghc) that links with this library must itself be licensed under the GPL. This is very unfortunate. I would suspect that this only applies if you actually use the Readline module, so I can just avoid that. However, using -package lang (to get the GetOpt module) links with -lreadline even though it's not necessary. So the resulting binary is dynamically linked with libreadline. My meaning is that this is not a license violation of readline, but I am no lawyer, and I recall Richard Stallman of the FSF says differently. Linking statically with -lreadline may be a solution, since the linker is smart and removes unused code in statically linked libraries. If only I could be sure that that's the fact. I think most ghc users have better things to do than to track licenses of libraries that ghc links your program to, so I suggest that the Readline module is either removed or moved to a separate package, so that there is no doubt that it's not linked in. Another question is what to do with ghc, ghc uses readline and is not licensed under the GPL. A possible GPL violation, at least it would be according to Richard Stallman. Regards, Martin -- Martin Norbäck Safelogic AB martin.norback(a)safelogic.se Stena Center 1C +46 (0)31 772 81 70 S-412 92 GÖTEBORG http://www.safelogic.se SWEDEN

3 2

GHC Ownership
by Ashley Yakeley 11 Jun '02

11 Jun '02

At 2002-06-11 08:18, Simon Marlow wrote: >This is *so* annoying when all we're trying to do is write free software >here. This reminds me... who legally owns GHC? * the University of Glasgow? * Simon and Simon? * Microsoft? * many different people and institutions? -- Ashley Yakeley, Seattle WA

1 0

Updating the net package
by Dominic Steinitz 11 Jun '02

11 Jun '02

I need to update the net package so that I can pass setSocketOption IP_TTL. This is a one line change. I'm using 5.02.2. There weren't any versions of Socket.hsc tagged as 5.02.2 in the CVS repository but there was one tagged Revision 1.2 / (download) - annotate - [select for diffs] , Fri Aug 17 12:51:08 2001 UTC (9 months, 3 weeks ago) by simonmar Branch: MAIN CVS Tags: ghc-5-02-branch, ghc-5-02-3, ghc-5-02-1, ghc-5-02 Changes since 1.1: +18 -12 lines Diff to previous 1.1 Track updates to hslibs/net I downloaded this and tried to compile but it has the following in it: instance Show Socket where ... and quite rightly the compiler complains. I'm going to take the latest version (although it would be nice to know which one was included in 5.02.2). 1. Should I be using Revision 1.11.2.2 / (download) - annotate - [select for diffs] , Wed Jun 5 16:36:59 2002 UTC (6 days, 3 hours ago) by simonpj Branch: meta-haskell-branch Changes since 1.11.2.1: +6 -4 lines Diff to previous 1.11.2.1 to branchpoint 1.11 next main 1.12 Merge from HEAD up to meta-haskell-merge3 or should I be using Revision 1.18 / (download) - annotate - [select for diffs] , Fri May 31 14:50:40 2002 UTC (11 days, 5 hours ago) by sof Branch: MAIN CVS Tags: HEAD Changes since 1.17: +3 -3 lines Diff to previous 1.17 cygwin: let's give UNIX domain sockets a go.. 2. Is my naive approach of just recompiling the relevant module going to work? I'd rather avoid having to build the whole of ghc if I can. Many thanks, Dominic Steinitz

1 0

GHC Gentoo Linux package
by Sven Moritz Hallberg 11 Jun '02

11 Jun '02

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OK, here it is. The GHC ebuild for Gentoo Linux has been incorporated in the official package tree (search http://www.gentoo.org/index-packages.html) This means that it is available to anyone running Gentoo, so you can now safely claim to run on that platform. While I'm at it, I have two questions: 1) Is there a package of unregisterised HC files for any version of GHC (4.08.2 preferably) downloadable anywhere? If not, does anyone have one lying around which might be made available? The ebuild is capable of attempting a bootstrap from unreg HC on platforms for which no platform-specific HC files exist. It expects a file http://www.haskell.org/ghc/dist/4.08.2/ghc-4.08.2-unreg-hc.tar.bz2 for that, which of course does not exist right now. I would try to build that file myself, but I'm completely out of time right now. :( 2) I read a comment somewhere (in some script or so) saying something along the lines of "once we are cross-compiling". Are there plans to make GHC able to cross-compile? Sven Moritz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9BjN4Bz8tX8KX/qsRApFBAJ445sIUdba9QOho5C7hNfsisbBOzACfW+z1 e8iqbRT9lW7iZ3mNcZa6ekM= =Baoh -----END PGP SIGNATURE-----

2 2

Get Your Free $110
by promo＠casino.com 11 Jun '02

11 Jun '02

1 0

RE: Dynamic Libraries on MacOS X
by Simon Marlow 11 Jun '02

11 Jun '02

> And there's a problem: ghc-pkg uses Read, and that requires all the > fields to be there. It would be a Bad Idea to force everyone > to update > every single package.conf file out there. Is there any special reason > why it doesn't use the ParsePkgConf.y parser from > compiler/main? (Simon: Am I allowed to make it do so?) Sure, go ahead. That's been on my ToDo list for a while. I'm beginning to think that the way MacOS X does frameworks is the way we should have done packages: it's much simpler to install/remove packages ("xcopy install" in MS-speak) if they all hang off a common root. On the other hand, it wouldn't be possible to install packages in some non-standard place without giving GHC an extra flag each time you use the package. > > One interesting possibility would be to allow support for > .hi files in > > frameworks. This would mean GHC would look inside > frameworks specified > > by > > the -framework flag and "frameworks" package.conf entries > for .hi files, > > in addition to -I and "import_dirs". > > I don't see why I would want to add a Haskell-Framework to a > package.conf file... I would definitely like to be able to > drag&drop-install GHC-Packages (it could be done on all > platforms, not > only MacOS). It would require loading package.conf files from > framework-style directories - I'll take a look at whether > this could be > done easily (and without disturbing the existing system) when > I've got the more important things done. This does indeed sound useful, and perhaps it could co-exist with the existing global package.conf file: if a package isn't found in package.conf, then we just search the framework/package search path for <package>/pkg.conf. I'm sure this would make people distributing 3rd party packages happier. Cheers, Simon

1 0

RE: Dynamic Libraries on MacOS X
by Ashley Yakeley 11 Jun '02

11 Jun '02

At 2002-06-10 04:03, Simon Marlow wrote: >It sounds like frameworks are similar in concept to GHC's packages. They solve a similar problem in a quite different way. A framework is a "bundle": an actual directory with everything inside it, libraries, header files, localised strings, whatever, with a particular internal structure that does clever stuff with symbolic links to handle multiple versions. Frameworks and other bundles (such as applications) may be relocated by the user, though frameworks generally need to be in certain standard places so that other tools can find them. Bundles may be uninstalled simply by deleting the directory. Generally the Mac GUI shows the directory as an object rather than a folder, though there's a special menu option to open the directory up like any folder. By contrast, GHC packages are virtual i.e. the stuff is not necessarily all in one directory. And if any of it gets moved, the package.conf file would need to be updated. For code-generating tools, you point to frameworks on the command-line much as you do libraries. For instance, just as you do "-lfoo -L./foolibs" to refer to libfoo and to search for libraries in ./foolibs/, you'd do "-framework foo -F ./foofws" to refer to foo.framework and to search in ./foofws/ for frameworks (there are also standard places to search). The Darwin C compiler can use this to find include files, and then you can pass the same options to the linker, and it will find the libraries. Too bad frameworks aren't standard on all UNIX, they are an excellent way of packaging software. >> *) add two command line options that get passed on to the >> linker (-framework for linking with a framework and -F for >> specifying framework search paths) >> *) add corresponding entries to package.conf > >You mean add a new package for each framework? I think Wolfgang means add new package specification components, such as "frameworks" and "frameworks_dir". They just need to be passed on to the linker. One interesting possibility would be to allow support for .hi files in frameworks. This would mean GHC would look inside frameworks specified by the -framework flag and "frameworks" package.conf entries for .hi files, in addition to -I and "import_dirs". This would mean a bit more code but I believe Apple provides APIs for dealing with bundles easily. -- Ashley Yakeley, Seattle WA

2 1

Re: problems with FFI including h files
by cwitty＠newtonlabs.com 10 Jun '02

10 Jun '02

Alastair Reid <reid(a)cs.utah.edu> writes: > > I thought we established that generating valid C prototypes from the > > Haskell FFI type signature wasn't possible due to the incompleteness > > of the Haskell type (lack of 'const' modifiers for one thing - is > > there anything else?). > > Compilers use the same calling sequence whether you tell them about > const or not. > > I believe that we can call all C functions correctly knowing only the > calling convention (ccall, stdcall, etc) and the Haskell type. I > certainly hope this is true since Hugs' implementation of wrappers > depends on it. > > (Hmmm, some calling conventions do funny things when passing and > returning small structs. I don't know much about this though...) I think some ABI's specify a different calling convention for varargs functions than non-varargs functions. (I remember reading this on some Haskell mailing list some time back, one of the previous times this same discussion occurred.) Carl Witty

1 0

RE: Dynamic Libraries on MacOS X
by Simon Marlow 10 Jun '02

10 Jun '02

> Possible Solution: > Frameworks. A "Framework" on MacOS X is a directory that > contains a dynamic library plus associated resources and > header files. There is an extra compiler/linker option for > linking to a framework. The big advantage is that the place > they are supposed to be installed in is accessible from the > user interface. > I've created a framework called "HaskellSupport.framework", > and I've made ghc link to that. It sounds like frameworks are similar in concept to GHC's packages. It's usually a good idea to comply with whatever is the approved way of doing things on a given platform, so I think this sounds like a reasonable solution. > Disadvantage: > Problems with GHCi (yes, I've almost got it to work!) - > "-framework HaskellSupport" is in the extra_ld_opts field of > the RTS package, so GHCi doesn't know that it has to load the > libraries. That sounds fine... as long as HaskellSupport doesn't contain any static libraries, right? > Related Problem: > Sooner or later, GHC for MacOS X should support Apple's > Frameworks anyway, as almost all functionality beyond the > standard C library is packaged in frameworks. I don't know > yet how much work that would be for me, and I fear that the > ghc gurus would dislike too much platform-specific code for > Apple's non-standard features... Here's what I'd like to do: I don't object at all to adding MacOS X specific code for frameworks, as long as there's someone around to maintain it! > *) add two command line options that get passed on to the > linker (-framework for linking with a framework and -F for > specifying framework search paths) > *) add corresponding entries to package.conf You mean add a new package for each framework? That's what I would suggest, if it is at all possible. If that's the case, then is the -framework option needed at all, since you can use -package instead? > *) add code for GHCi to load frameworks. Same here: if a framework is really just a collection of libraries and a search path, then converting frameworks into packages will mean that GHCi can load them as normal. Cheers, Simon

1 0

Dynamic Libraries on MacOS X
by Wolfgang Thaller 06 Jun '02

06 Jun '02

Hi Everyone, I've run into some problems/"design issues" for GHC/MacOSX, and I'd like to hear other people's opinions on the subject. Sorry for the long post. Programs compiled by GHC for MacOS X currently depend on two libraries that are not included with MacOS X: *) dlcompat - a compatibility layer implementing the dlopen API, which is not normally available on MacOS X (BSD-style license) *) libgmp - support for the Integer type, under LGPL The Problem: *) Most Mac users don't know how to install unix-style dynamic libraries. They shouldn't be expected to know. The MacOS Finder (Apple's File Browser) hides the entire /usr directory hierarchy be default. Requiring everyone who uses a program written in Haskell to install a dylib is not an option on MacOS. *) The LGPL imposes serious restrictions on all programs statically linked with libgmp, so static linking is not an option, either. *) Dynamic libraries anywhere on the system take precedence over static libraries, so if GHC included static versions of the libraries, developers could still accidentally create programs that depend on the dylibs. Possible Solution: Frameworks. A "Framework" on MacOS X is a directory that contains a dynamic library plus associated resources and header files. There is an extra compiler/linker option for linking to a framework. The big advantage is that the place they are supposed to be installed in is accessible from the user interface. I've created a framework called "HaskellSupport.framework", and I've made ghc link to that. Disadvantage: Problems with GHCi (yes, I've almost got it to work!) - "-framework HaskellSupport" is in the extra_ld_opts field of the RTS package, so GHCi doesn't know that it has to load the libraries. Related Problem: Sooner or later, GHC for MacOS X should support Apple's Frameworks anyway, as almost all functionality beyond the standard C library is packaged in frameworks. I don't know yet how much work that would be for me, and I fear that the ghc gurus would dislike too much platform-specific code for Apple's non-standard features... Here's what I'd like to do: *) add two command line options that get passed on to the linker (-framework for linking with a framework and -F for specifying framework search paths) *) add corresponding entries to package.conf *) add code for GHCi to load frameworks. I'm looking forward to everyone's opinions. Cheers, Wolfgang

1 0