RE: GHCI and archive libraries.
I believe that it ought to be fairly straightforward to modify GHCi's linker (which is written in C) to understand .a files. Would someone like to try? Failing that, it'd be great if someone would feel able to write a few paras to summarise this thread, for us to add to the documentation. Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:glasgow-haskell-users- | [EMAIL PROTECTED] On Behalf Of Keean Schupke | Sent: 04 December 2005 14:28 | To: Sven Panne | Cc: Lennart Augustsson; glasgow-haskell-users@haskell.org | Subject: Re: GHCI and archive libraries. | | 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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHCI and archive libraries.
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
Re: GHCI and archive libraries.
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 ___ 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
