GHCI and archive libraries.
GHCI does not load archive libraries. Is it possible (easy?) to get it to load (.a) archive libraries as well as .o and .so files? The problem is some optimized cblas libraries are not available as shared libraries due to the performace loss. Regards, Keean. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHCI and archive libraries.
Can't you unpack the ar library and then link the object files into a shared library? -- Lennart Keean Schupke wrote: GHCI does not load archive libraries. Is it possible (easy?) to get it to load (.a) archive libraries as well as .o and .so files? The problem is some optimized cblas libraries are not available as shared libraries due to the performace loss. Regards, Keean. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHCI and archive libraries.
Am Samstag, 3. Dezember 2005 14:48 schrieb Lennart Augustsson: Can't you unpack the ar library and then link the object files into a shared library? On most platforms the code in a *.a library is not shared library code, e.g. it is not PIC or something like that. Nevertheless, I think that the *.o files GHCi loads are not exactly shared libraries, they are incrementally linked relocatable object code (correct me if I'm wrong here, the details of shared libraries are still a kind of black art...). So you might have luck with unpacking and re-linking like that: ar x libblah.a ld -r -x -o /my/new/blah.o *.o The linker flags for doing this vary, depending on the platform, you can have a look at GHC's autoconf magic for hints if it doesn't work like mentioned above. Cheers, S. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHCI and archive libraries.
And on many platforms (well, at least a few years ago) a shared library doesn't have to be PIC. The dynamic loader can do relocation when it loads the file. (Then it can't be shared.) But this was a few years ago on Solaris and BSDs, it could be different now. -- Lennart Sven Panne wrote: Am Samstag, 3. Dezember 2005 14:48 schrieb Lennart Augustsson: Can't you unpack the ar library and then link the object files into a shared library? On most platforms the code in a *.a library is not shared library code, e.g. it is not PIC or something like that. Nevertheless, I think that the *.o files GHCi loads are not exactly shared libraries, they are incrementally linked relocatable object code (correct me if I'm wrong here, the details of shared libraries are still a kind of black art...). So you might have luck with unpacking and re-linking like that: ar x libblah.a ld -r -x -o /my/new/blah.o *.o The linker flags for doing this vary, depending on the platform, you can have a look at GHC's autoconf magic for hints if it doesn't work like mentioned above. Cheers, S. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHCI and archive libraries.
Am Samstag, 3. Dezember 2005 15:17 schrieb Lennart Augustsson: And on many platforms (well, at least a few years ago) a shared library doesn't have to be PIC. The dynamic loader can do relocation when it loads the file. (Then it can't be shared.) But this was a few years ago on Solaris and BSDs, it could be different now. After a quick look this seems to be the case on current x86 Linux systems, too: Real shared libraries consist of PIC to enhance sharing code at runtime, but nevertheless the dynamic loader seems to be able to load and relocate non-PIC, at the cost of less sharing, but often slightly better code quality. So the mentioned repacking of a static library into a partially linked object file might work for most common platforms. Cheers, S. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
recommended build system
Hi all, I'm looking for a build system for my projects which will correctly handle all of ghc's dependencies. I.e. every time I ask it to rebuild an output file, it will only do the minimum amount of compilation necessary. This is important to me because ghc --make and cabal currently (AFAICT) will always relink an executable even when it is not necessary to do so; thus if I have a project with a bunch of libraries and executables, the cost of making a small modification and recompiling is very high, and it becomes hard to maintain focus on my projects after the initial design phase. I've just been playing around with GNU coreutils and was impressed with how well the build system works, and how fast the recompilation goes. Anyway, the system that darcs uses seems to work pretty well, should I copy that, or do people recommend other alternatives? Frederik ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc --make and make
I was thinking it would be nice if ghc --make could touch the output file with the timestamp of the most recently modified source file. As it is, if you edit a file in between when ghc --make starts and it finishes (a substantial amount of time in some cases) then 'make' will not realize the dependencies have changed. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
exhaustive pattern warning bug with irrefutable patterns
the following gives a 'non-exhaustive pattern matching' error when it shouldn't. the ~-pattern always matches. It is not the function that is non-exhausitive, but the irrefutable binding, which are necessarily always non-exhausive so warning about it is the wrong thing to do. f :: [a] - a f [x] = x f ~(_:xs) = f xs John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
