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.
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
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.
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
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.
Thaks guys... I realise it is a simple matter of unpacking the object files, however when using ghci for prototyping, it can be more convenient to have all the '.o's packed into a '.a'. As it is a simple matter to extract the .o files from the .a, I would have thought a fairly small change to the ghci code would have enabled using archive libraries. I think this change would aid usability. I don't know the ghci code at all, so it would take me a long time to make this change, as I would first have to understand the existing code. I was wondering if anyone familier with the ghci code could add archive library support? I suppose as a work around I could write a wrapper for ghci that extracts the .o files from the .a to a temp directory, and then calls ghci with the .o files on the command line. Regards, Keean. Sven Panne wrote:
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
You can write a simple shell script wrapper around ghci that takes care of .a files. -- Lennart Keean Schupke wrote:
Thaks guys... I realise it is a simple matter of unpacking the object files, however when using ghci for prototyping, it can be more convenient to have all the '.o's packed into a '.a'. As it is a simple matter to extract the .o files from the .a, I would have thought a fairly small change to the ghci code would have enabled using archive libraries. I think this change would aid usability. I don't know the ghci code at all, so it would take me a long time to make this change, as I would first have to understand the existing code. I was wondering if anyone familier with the ghci code could add archive library support? I suppose as a work around I could write a wrapper for ghci that extracts the .o files from the .a to a temp directory, and then calls ghci with the .o files on the command line.
Regards, Keean.
Sven Panne wrote:
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
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
participants (3)
-
Keean Schupke -
Lennart Augustsson -
Sven Panne