- Glasgow-haskell-users

Re: 64-bit windows version?
by Peter Tanski 20 Jun '07

20 Jun '07

Simon Marlow wrote: > GHC *developers* wouldn't be any better off either. You'd still > need either > Cygwin or MSYS for the build environment. There's no way I'm using > MS build > tools, ugh. The way I have it set up (so far) is as simple as running configure and make--all from the command line, under DOS or Mingw, although someone with VS tools may open up the VSproject in the IDE. Would that be o.k.? I am not particularly enamored with VS, myself but that may be a consequence of having a small monitor for my Windows machine and constantly comparing it to the Xcode/Emacs combination I normally use. The VS debugger *is* very good and helped me pick out some bugs in Yasm quickly--when I only really know how to use gdb. Cheers, Pete

1 0

How to use qualified name ModuleName.(.!.) ?
by Marc Weber 20 Jun '07

20 Jun '07

Example: marc@localhost /tmp/qual $ ls; cat M.hs main.hs; ghc --make main.hs M.hi M.hs M.o main.hs -- module M ------------------ module M where import Data.List infixr 9 .!. f = "dummyf" (.!.) = (!!) -- module Main ------------------ module Main where import qualified M as M main = do print $ M.f -- (1) print $ M.(.!.) [1,2] 1 -- (2) -- ------------------------------- [2 of 2] Compiling Main ( main.hs, main.o ) main.hs:7:10: Not in scope: data constructor `M' (3) main.hs:7:12: Not in scope: `.!.' (4) Calling M.f (1) works fine whereas calling M.(.!.) results in the error messages. Is possible somehow? Can I find more information in the ghc docs? Marc Weber

2 1

Re: Locating shared libraries
by Peter Tanski 19 Jun '07

19 Jun '07

skaller wrote: > On Fri, 2007-06-15 at 19:40 -0500, Spencer Janssen wrote: >> On Sat, 16 Jun 2007 08:21:50 +1000 >> skaller <skaller(a)users.sourceforge.net> wrote: >> >>> One way to measure this is: if you removed GHC and applications, >>> and there are (necessarily) no users of the remaining library >>> package .. the library package shouldn't be in the global public >>> place (/usr/lib+include etc). >>> >> >> As I understand it, the entire point of this effort (shared libraries >> in GHC) is to allow dynamically linked Haskell executables. In this >> case, applications outside the GHC toolchain will in fact depend on >> these shared objects. As a concrete case, a binary darcs package >> could >> be a user of libghc66-base.so and libghc66-mtl.so -- with no >> dependencies on the GHC compiler package itself. >> >> Does this pass your litmus test? >> > > Yes, it passes the separability test. My darcs wouldn't run otherwise! > And versioning the library filename as above is a good idea too. > > Felix adds _dynamic for shared libs and _static for static link > archives to ensure the Linux linker doesn't get confused. > > However, the libs still aren't fully public if the interfaces > are only private details of the GHC tool chain. Hmmm. Under the current system, darcs is linked statically so it is a self- contained executable. Under the proposed shared-library system versioning the shared libraries may pose a very big problem and I don't think it would pass your litmus test. As I mentioned previously, GHC is a fast-moving target and there are quite a few GHC- Haskell-based applications available that rely on different versions of the compiler. Here is an example: There are any number of GHC-Haskell-based programs, all built with different versions of GHC; GHC itself relies on some of these to build, such as Happy and Alex. (There are .rpm packages for Alex.) You already talked about the situation from there: several different programs relying on different versions of the shared libraries, located in /usr/local/lib--and they don't rely on just one library. As is, the GHC runtime system has more than a few base libraries, the minimum set of which is: HSrts HSbase HSbase_cbits With dynamically linked libraries on OS X, the convention was to have add the suffix _dyn, so we had: HSrts_dyn, HSbase_dyn and HSbase_cbits_dyn Now each GHC-Haskell-based program installer would search /usr/local/ lib for, say, libHSrts_dyn-6.6.1.dylib and install that version if necessary. What happens on uninstall? The same thing you get on Windows when you have another program using a particular .DLL--the uninstall of that version of the library would fail but for unix systems _only_ if you also have another program using at while you are doing the uninstall. So if you did not break everything on each install, eventually you have a complete mess of different versions of GHC libraries in /usr/local/lib that may have no current use but at one time were used for several GHC-Haskell-based programs that have now been upgraded to use something different. Hopefully those who distributed the binary programs adopted a convention of using the full version of the library instead of symlinking libHSrts_dyn-6.6.1 to libHSrts_dyn, or as a user several of your older programs might break after a later one installed a new version of the library and symlinked that the new version... That is why I think your idea was good: put everything into distinct directories. Cheers, Pete

3 4

GHC Crosscompile
by Cristian Perfumo 19 Jun '07

19 Jun '07

Hi everybody: I would like to compile Haskell programs to run on Alpha architecture. As the target architecture is going to be simulated, I can't install GHC on an Alpha machine (because I don't have one). As most of you, I have got GHC installed and running on x86. Is there any way to cross-compile and generate Alpha code with my x86 compiler? Hope you can help me. Regards Cristian Perfumo

4 3

cyclic import bug in 6.6.1
by Serge D. Mechveliani 18 Jun '07

18 Jun '07

Dear GHC developers, I an half-stuck now due to the ghc-6.6.1 bug of `undefined reference' at the stage of linking the executable. I am almost sure that this is due to cyclic import. There already was cyclic import, and the whole program worked correct. Now, I have split one large module into two modules, and there appeared more cyclic imports. Now, it `makes' the package and does `install', but cannot link the executable for `main'. There are about 30 modules in the project, and 4-5 of them form a cycle by import. Please, whom I need to send the source archive to ? I can reduce this bug report project many times, but I suspect that in this particular case you can easily spot the place in the project as it is. Can you ? Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

Re: Locating shared libraries
by Peter Tanski 16 Jun '07

16 Jun '07

Spencer Janssen wrote: > On Sat, 16 Jun 2007 08:21:50 +1000 > skaller <skaller(a)users.sourceforge.net> wrote: > >> One way to measure this is: if you removed GHC and applications, >> and there are (necessarily) no users of the remaining library >> package .. the library package shouldn't be in the global public >> place (/usr/lib+include etc). > > As I understand it, the entire point of this effort (shared libraries > in GHC) is to allow dynamically linked Haskell executables. In this > case, applications outside the GHC toolchain will in fact depend on > these shared objects. As a concrete case, a binary darcs package > could > be a user of libghc66-base.so and libghc66-mtl.so -- with no > dependencies on the GHC compiler package itself. > > Does this pass your litmus test? If a binary darcs package requires GHC libraries to function it would be a GHC "application," so it would not pass the test. John Skaller's point is actually very good, though it would require special changes to the current system: distinguishing between GHC- compiled _shared_libraries_ and the GHC compiler itself. Under the current system ghc sits in its own subdirectory, typically / usr/local/lib, /opt/local/lib, etc., depending on your distribution, with only the compiler and "base" libraries. Relatively few Cabal packages install into this directory--HaXml does, if i remember correctly. Most Cabal packagers leave the default install, so applications compiled by GHC are installed as subdirectories in the user library directory (/usr/local/lib). So we have this layout: /usr/local/lib/ghc-6.6.1 <--compiler, ghc-distribution libraries /usr/local/lib/ghc-6.6.1/imports <-- .hi files after installing HaXml: /usr/local/lib/ghc-6.6.1 <- HaXml libraries /usr/local/lib/ghc-6.6.1/imports <-- HaXml .hi files after installing a default Cabal distribution (here, HXT): /usr/local/lib/hxt-$(version) <-- libraries /usr/local/lib/hxt-$(version)/imports <-- hxt .hi files With the current setup is it is a real pain to go through and uninstall all those extra libraries when you upgrade GHC: you must either delete the directories completely (for directories based on version, such as hxt-$(version), above); or, you must go into each directory and delete the old libraries contained there. The ghc-pkg program only handles finding these libraries for the ghc compile process; it does not help with uninstalling them except by tracking location. I would extend John's idea--and reference to gcc's install layout: everything should go into the generic "ghc" directory, say, /usr/ local/lib/ghc; _under_ that should go the compiler version (including arch-platform); _under_ that may go user-libraries. That structure would make it much easier for users to uninstall or upgrade ghc versions. It also gives distributors the flexibility to include a ghc-library-only distribution (no compiler) for packaging applications--say, a basic darcs install (with shared libraries) includes only the shared libraries it needs. A basic "ghc" directory on top--no version until the next subdirectory--also preserves prime real estate toward the top levels of the directory structure: a user may install more than one version of GHC into their home directory without flooding their home directory with ghc-$(version)s. There is a fundamental flaw with all these "new" languages: ABI changes between compiler versions force software vendors to give customers upgrades of the entire program--you can't send a patch if you need to compile all the libraries again. Static libraries are horrible for the same problem, and one of the main reasons I will not use OCaml for any distributable application. Even in-house, a hassle like that means time and lost productivity. Patches are inevitable for new features, security, etc., and changes to the compiler are inevitable just to get around bugs in the compiler! GHC is a research effort so it is a relatively fast moving target--how much Haskell code has bit rotted simply due to changes in the GHC compiler? In the past _three_ years? How much simply due to changes in the _interface_ file (.hi) format? A lot. Too much to mention here. Even if we can't standardise the ABI a bit the solution of where to put libraries should place some real consideration on how much time and trouble it is to uninstall and recompile everything, without resorting to a script or package system to do it for us--you may imagine the bug bath from, say, modifying ghc-pkg to handle uninstallation. Cheers, Pete

1 0

Locating shared libraries
by Clemens Fruhwirth 16 Jun '07

16 Jun '07

Hi, I'm hacking on shared library support for GHC and it's coming along quite nicely. http://hpaste.org/192 My initial hacks are available from: http://clemens.endorphin.org/patches/ghc-20070605-initial-shared-libs.patch (works only with x86-64 atm, on i386 the NCG dies in the register allocator when compiling cmm files RTS) http://clemens.endorphin.org/patches/cabal-20070528-initial-shared-library.… libtool usually takes care of creating shared libraries under *nix system. libtool solves a few minor problems associated with: 1) creating shared libraries 2) linking programs that depend on shared libraries 3) running programs that depend on shared libraries libtool is tailored to C compilers and the general opinion from #ghc towards libtool seems to be: "hands off". From the list above, I will try to sketch solutions without libtool. 1) creating shared libraries: At the moment, my second patch teaches Cabal how to build shared libraries. Basically, this is: * add -fPIC to the compiler invocation (and -optc-fPIC for c-sources), * invoke "ld -shared -Bsymbolic -o foo.so obj1.o obj2.o ...". ATM, ld is not invoked with the inter-library dependencies for the shared library being built. This is not problematic as the final executable will include all dependencies due to the ghc package dependency tracking. But DT_NEEDED on ELF influences the sequence in which shared library initializers are run. I have not yet investigated if this leads to any problems. To solve this little shortcoming, the ld-invocation could be delegated to GHC. "ghc -o libHSfoo.so Foo1.o Foo2.o". We already have a similar facility for DLLs (see MkDLL in DriverPipeline.hs). This could be abstracted into MkShared, and platform specific knowledge could be encapsulated in GHC. The benefit would be that we could easily access the package information and we could create shared libraries that contain proper DT_NEEDED sections. 2) Linking programs Linking should work out of the box: "ghc -dynamic -o HelloWorld HelloWorld.o" creates dynamically linked executable. 3) Running programs This a typical problem: ./HelloWorld ./HelloWorld: error while loading shared libraries: libHShaskell98-1.0_dyn.so: cannot open shared object file: No such file or directory There are several ways to add search paths for dynamic linking: either we do it temporarily or we encode the search paths into the executables. On ELF platforms, this works by adding -rpath to the linker flags. This adds two new entries in the .dynamic section (DT_RPATH, DT_RUNPATH) both responsible for signalling additional search paths to the dynamic linker, ld.so. According to Simon Marlow, Windows has similar mechanism via manifest files. Let's see how libtool handles this situation. libtool differentiates between installed and uninstalled libraries. When linking against installed libraries not in the standard search path, libtool uses -rpath to add these search paths to the created executable. When linking against uninstalled libraries, libtool still uses -rpath but pointing to the directory the uninstalled library is going to be installed in. libtool derives this information from the .la files+Makefiles. In any case, libtool creates a wrapper in the build directory that takes care of executing the program linked against uninstalled shared libraries. There are two strategies for accomplishing this: * add the paths of the uninstalled shared libraries to LD_LIBRARY_PATH * relink the executable with additional -rpath's libtool chooses the second strategy. How do we translate these solutions to GHC? The first question is whether we expect ghc -dynamic -package uninstalled-package -o Hello Hello.o ./Hello to work or whether we require manual intervention in these cases. If we expect this to work without intervention, we have the same options as libtool: * create a wrapper that takes care of locating the uninstalled shared libraries and sets LD_LIBRARY_PATH. * create a binary with rpath of the uninstalled libraries, and create an additional executable for deployment without these rpaths. In any case we have to modify the installer scripts to either know about where to locate the real binary, either ask ghc where to find the real binary, or either delegate the installation to ghc. The last option is basically the libtool way, "libtool --mode=install ..." When we decide to create a deployable executable at the "-o" spot, we need to * modify the invocation to manually pick up the libraries by modifying LD_LIBRARY_PATH.. this is pretty unpractical. * delegate invocation to ghc. Maybe "ghc --execute HelloWorld". libtool has a similar mechanism for executing 3rd party programs in the "dynamic environment" of the compiler executable. For instance, "gdb HelloWorld" would fails for libtool as HelloWorld is a wrapper, but "libtool --mode=execute gdb HelloWorld" works, as libtool rewrites to HelloWorld to .libs/lt-HelloWorld. And now something completely different: Create a custom ELF program interpreter for Haskell programs. Using INTERP in the ELF program header, loads up this interpreter and delegates control to it. Usually this is /lib/ld-linux.so.2, the dynamic linker, but we can replace that. Haskell has its own idea of libraries/packages. We have package.conf which gives us the location of the installed libraries. This is ok for static linking, as at link time ghc is running and knows how to invoke gcc with the correct paths. It does not matter, if package.conf is updated afterwards as the statically linked programs contain a copy of the library anyway. For dynamic linking this phase is delayed and when we encode rpath such as "/usr/lib/network-2.0/ghc-6.6/", we can not update to network-2.1 without breaking this executables. A custom programming loading stub could access the global and local package.conf and extract the library path for the dependencies and execve /lib64/ld-linux.so.2 --library-path=<paths of the dependencies> HelloWorld <args> This certainly gives us more flexibility than encoding all these rpaths statically into HelloWorld. To solve the inplace execution directly from the build directory, we might create .HelloWorld.package.conf in case a non-standard package.conf is used (non-standard=different from global and local) and have the stub loader to check for this file. I agree that the last scheme sounds a bit wild, but I argue that that's what ELF designers had in mind when they specified the INTERP header. Of course, this is only a solution for ELF platforms. Opinions :) ? -- Fruhwirth Clemens - http://clemens.endorphin.org

9 19

DoCon soft announcement
by Serge D. Mechveliani 15 Jun '07

15 Jun '07

Software Announcement --------------------- The Algebraic Domain Constructor DoCon, Version 2.09, written in Haskell, is available, together with its source program, on Internet at the following addresses: http://www.botik.ru/~mechvel/ click at docon-2.09 (Russian site), ftp.botik.ru/pub/local/Mechveliani/docon/ (same site), http://www.haskell.org/docon/distrib/ (USA site) The difference to previous (2.08) release is small: * it is ported to the latest (on 2007) Glasgow Haskell version of 6.6.1, * it has a simpler installation code, due to that it relies on the commands `configure', `build', `install' of the Cabal support for `making', * several bugs are fixed, * the implementation for decomposing to elementary symmetrics is improved. ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

Running multithreaded GHC on Itanium
by Srđan Stipić 14 Jun '07

14 Jun '07

I am currently trying to modify GHC 6.6.1 to run on Itanium in multithreaded mode (+RTS -N). Is it possible to do those modifications without generating back-end for Itanium? (If I am correct GHC on Itanium uses gcc to generate the code) Thanks Srdjan

2 1

GHC 6.6 panics when compiling HSet from collections package
by Daniel McAllansmith 13 Jun '07

13 Jun '07

Hi. I just got the collections package from http://darcs.haskell.org/packages/collections-ghc6.6 When trying to build it with GHC 6.6 on an amd64 linux machine using Cabal I got the following: [12 of 57] Compiling Data.Tree.AVL.IntMap.Internals.HSet ( Data.Tree.AVL.IntMap/Data/Tree/AVL/IntMap/Internals/HSet.hs, dist/build/Data/Tree/AVL/IntMap/Internals/HSet.o ) ghc-6.6: panic! (the 'impossible' happened) (GHC version 6.6 for x86_64-unknown-linux): cgPanic tpl{v s2zg} [lid] static binds for: collections-0.3:Data.Tree.AVL.IntMap.Internals.HSet.intersectionMaybeH{v rji} [gid] collections-0.3:Data.Tree.AVL.IntMap.Internals.HSet.$Lr2jfforkL{v r2jf} [gid] collections-0.3:Data.Tree.AVL.IntMap.Internals.HSet.$Lr2jhforkR{v r2jh} [gid] local binds for: SRT label collections-0.3:Data.Tree.AVL.IntMap.Internals.HSet.intersectionWithH'{v rjg}_srt Anyone seen this before? A real GHC bug, a problem with my GHC installation, or a problem with the collections package? Cheers Daniel

2 1