Difficulties making monolithic-lib-op portable suggest that it (and maybe also lib-op) should output an object file as if by ld -r rather than a static library. Indeed, there is no *portable* way to combine several .a files into a single one on a BSD system (including MacOS X). Or should that be the case only on said systems? In any case, that's ugly, and to make a distinction, we'd have to extend os.lisp to also distinguish bsd-style unix from gnu-style unix. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org It is said that pragmatism trumps ideology in a crisis. What actually happens in a crisis, certainly in this one, is that the ruling party gets to rechristen its ideology as pragmatism. — Christopher Caldwell
Faré writes:
Difficulties making monolithic-lib-op portable suggest that it (and maybe also lib-op) should output an object file as if by ld -r rather than a static library. Indeed, there is no *portable* way to combine several .a files into a single one on a BSD system (including MacOS X). Or should that be the case only on said systems?
We have currently bug regarding combining static libraries[1], but doesn't BSD nor OSX support libtool? If yes, then we can just extract all objects from static archive and combine them again.
In any case, that's ugly, and to make a distinction, we'd have to extend os.lisp to also distinguish bsd-style unix from gnu-style unix.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org It is said that pragmatism trumps ideology in a crisis. What actually happens in a crisis, certainly in this one, is that the ruling party gets to rechristen its ideology as pragmatism. — Christopher Caldwell
[1] https://gitlab.com/embeddable-common-lisp/ecl/issues/177 In one of the comments @Whimse provides a working solution using libtool. -- Daniel Kochmański | Poznań, Poland ;; aka jackdaniel "Be the change that you wish to see in the world." - Mahatma Gandhi
On Tue, Oct 6, 2015 at 1:18 AM, Daniel Kochmański <daniel@turtleware.eu> wrote:
Faré writes:
Difficulties making monolithic-lib-op portable suggest that it (and maybe also lib-op) should output an object file as if by ld -r rather than a static library. Indeed, there is no *portable* way to combine several .a files into a single one on a BSD system (including MacOS X). Or should that be the case only on said systems?
We have currently bug regarding combining static libraries[1], but doesn't BSD nor OSX support libtool? If yes, then we can just extract all objects from static archive and combine them again.
[1] https://gitlab.com/embeddable-common-lisp/ecl/issues/177
In one of the comments @Whimse provides a working solution using libtool.
Do you require libtool to be installed on BSD (including OSX)? It certainly doesn't come standard, not even on Linux. Also, I could never get libtool to work correctly, even on Linux, despite having alleged cut-and-paste recipes and a man page. I was thinking about MRI scripts, but they are also a GNUism not supported on BSD. Why do we need a .a rather than a .o, anyway? For the proposed use case, a .o seems more reasonable. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Director is a misnomer. You're a hoper. You put all these people together and you hope it all works out. — Frank Oz, director of "Dirty Rotten Scoundrels"
Faré writes:
On Tue, Oct 6, 2015 at 1:18 AM, Daniel Kochmański <daniel@turtleware.eu> wrote:
Faré writes:
Difficulties making monolithic-lib-op portable suggest that it (and maybe also lib-op) should output an object file as if by ld -r rather than a static library. Indeed, there is no *portable* way to combine several .a files into a single one on a BSD system (including MacOS X). Or should that be the case only on said systems?
We have currently bug regarding combining static libraries[1], but doesn't BSD nor OSX support libtool? If yes, then we can just extract all objects from static archive and combine them again.
[1] https://gitlab.com/embeddable-common-lisp/ecl/issues/177
In one of the comments @Whimse provides a working solution using libtool.
Do you require libtool to be installed on BSD (including OSX)? It certainly doesn't come standard, not even on Linux.
It is at least dependency at ECL compilation time (bdwgc requires it). It isn't that unreasonable to require it for C backend.
Also, I could never get libtool to work correctly, even on Linux, despite having alleged cut-and-paste recipes and a man page.
@Whimse claims it works just OK for him. I'll have to adjust it to play nice with cross-compilation framework I'm working on now.
I was thinking about MRI scripts, but they are also a GNUism not supported on BSD.
Why do we need a .a rather than a .o, anyway? For the proposed use case, a .o seems more reasonable.
That's what we do - we combine .o files. But Sometimes we want to combine with already built static libraries. That's when such approach would be necessary. Mentioned bug affects only such situations. If you just do monolithic build from lisp lisp sources then there's not a problem.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Director is a misnomer. You're a hoper. You put all these people together and you hope it all works out. — Frank Oz, director of "Dirty Rotten Scoundrels"
-- Daniel Kochmański | Poznań, Poland ;; aka jackdaniel "Be the change that you wish to see in the world." - Mahatma Gandhi
Hi, After speaking a bit with jackdaniel on irc, it seems that the issue is correctly writing the .a files? If so, since it's a simple ar archive, this could be done in Lisp. I wrote an ar writer in less than 100 lines with some hard coded values: https://github.com/ralt/deb-packager/blob/master/src/ar.lisp The format is basically: a global header followed by the entries. (Entries format is relatively straightforward, I invite you to look at the code.) I think it would be pretty straightforward to implement the reader in Lisp to manually add .o files to the end of the .a archive. (Basically, add new entries at the end of the archive.) Maybe I haven't fully understood the issue though. In that case, you can fully ignore me :-) Regards, Florian Le 6 oct. 2015 07:50, "Daniel Kochmański" <daniel@turtleware.eu> a écrit :
Faré writes:
On Tue, Oct 6, 2015 at 1:18 AM, Daniel Kochmański <daniel@turtleware.eu>
wrote:
Faré writes:
Difficulties making monolithic-lib-op portable suggest that it (and maybe also lib-op) should output an object file as if by ld -r rather than a static library. Indeed, there is no *portable* way to combine several .a files into a single one on a BSD system (including MacOS X). Or should that be the case only on said systems?
We have currently bug regarding combining static libraries[1], but
doesn't
BSD nor OSX support libtool? If yes, then we can just extract all objects from static archive and combine them again.
[1] https://gitlab.com/embeddable-common-lisp/ecl/issues/177
In one of the comments @Whimse provides a working solution using libtool.
Do you require libtool to be installed on BSD (including OSX)? It certainly doesn't come standard, not even on Linux.
It is at least dependency at ECL compilation time (bdwgc requires it). It isn't that unreasonable to require it for C backend.
Also, I could never get libtool to work correctly, even on Linux, despite having alleged cut-and-paste recipes and a man page.
@Whimse claims it works just OK for him. I'll have to adjust it to play nice with cross-compilation framework I'm working on now.
I was thinking about MRI scripts, but they are also a GNUism not supported on BSD.
Why do we need a .a rather than a .o, anyway? For the proposed use case, a .o seems more reasonable.
That's what we do - we combine .o files. But Sometimes we want to combine with already built static libraries. That's when such approach would be necessary. Mentioned bug affects only such situations. If you just do monolithic build from lisp lisp sources then there's not a problem.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics•
Director is a misnomer. You're a hoper. You put all these people together and you hope it all works out. — Frank Oz, director of "Dirty Rotten Scoundrels"
-- Daniel Kochmański | Poznań, Poland ;; aka jackdaniel
"Be the change that you wish to see in the world." - Mahatma Gandhi
On Tue, Oct 6, 2015 at 2:30 AM, Florian Margaine <florian@margaine.com> wrote:
After speaking a bit with jackdaniel on irc, it seems that the issue is correctly writing the .a files? If so, since it's a simple ar archive, this could be done in Lisp. I wrote an ar writer in less than 100 lines with some hard coded values: https://github.com/ralt/deb-packager/blob/master/src/ar.lisp
The format is basically: a global header followed by the entries. (Entries format is relatively straightforward, I invite you to look at the code.)
I think it would be pretty straightforward to implement the reader in Lisp to manually add .o files to the end of the .a archive. (Basically, add new entries at the end of the archive.)
Maybe I haven't fully understood the issue though. In that case, you can fully ignore me :-)
Well, *if* we move that code from CFFI (my current branch of it) to ASDF (post 3.1.6 release), that's about 300 more lines to add to ASDF (and probably even more lines to support 10 additional implementations). I don't know whether or not we want that, and if we do, whether 100 or 200 additional lines for ar support are OK. Maybe we could require libtool when running on BSD. Meh. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Superstition brings bad luck. — Saul Gorn
On Tue, Oct 6, 2015 at 2:30 AM, Florian Margaine <florian@margaine.com> wrote:
After speaking a bit with jackdaniel on irc, it seems that the issue is correctly writing the .a files? If so, since it's a simple ar archive, this could be done in Lisp. I wrote an ar writer in less than 100 lines with some hard coded values: https://github.com/ralt/deb-packager/blob/master/src/ar.lisp
The format is basically: a global header followed by the entries. (Entries format is relatively straightforward, I invite you to look at the code.)
I think it would be pretty straightforward to implement the reader in Lisp to manually add .o files to the end of the .a archive. (Basically, add new entries at the end of the archive.)
Maybe I haven't fully understood the issue though. In that case, you can fully ignore me :-)
Well, *if* we move that code from CFFI (my current branch of it) to ASDF (post 3.1.6 release), that's about 300 more lines to add to ASDF (and probably even more lines to support 10 additional implementations). I don't know whether or not we want that, and if we do, whether 100 or 200 additional lines for ar support are OK. Maybe we could require libtool when running on BSD. Meh.
Maybe it's not such a bad idea to bundle libtool with CFFI. -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib
I've mistakenly taken this thread as one on the ecl-devel - please ignore direct ECL references. Regards, Daniel Daniel Kochmański writes:
Faré writes:
On Tue, Oct 6, 2015 at 1:18 AM, Daniel Kochmański <daniel@turtleware.eu> wrote:
Faré writes:
Difficulties making monolithic-lib-op portable suggest that it (and maybe also lib-op) should output an object file as if by ld -r rather than a static library. Indeed, there is no *portable* way to combine several .a files into a single one on a BSD system (including MacOS X). Or should that be the case only on said systems?
We have currently bug regarding combining static libraries[1], but doesn't BSD nor OSX support libtool? If yes, then we can just extract all objects from static archive and combine them again.
[1] https://gitlab.com/embeddable-common-lisp/ecl/issues/177
In one of the comments @Whimse provides a working solution using libtool.
Do you require libtool to be installed on BSD (including OSX)? It certainly doesn't come standard, not even on Linux.
It is at least dependency at ECL compilation time (bdwgc requires it). It isn't that unreasonable to require it for C backend.
Also, I could never get libtool to work correctly, even on Linux, despite having alleged cut-and-paste recipes and a man page.
@Whimse claims it works just OK for him. I'll have to adjust it to play nice with cross-compilation framework I'm working on now.
I was thinking about MRI scripts, but they are also a GNUism not supported on BSD.
Why do we need a .a rather than a .o, anyway? For the proposed use case, a .o seems more reasonable.
That's what we do - we combine .o files. But Sometimes we want to combine with already built static libraries. That's when such approach would be necessary. Mentioned bug affects only such situations. If you just do monolithic build from lisp lisp sources then there's not a problem.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Director is a misnomer. You're a hoper. You put all these people together and you hope it all works out. — Frank Oz, director of "Dirty Rotten Scoundrels"
-- Daniel Kochmański | Poznań, Poland ;; aka jackdaniel "Be the change that you wish to see in the world." - Mahatma Gandhi
participants (4)
-
Daniel Kochmański -
Faré -
Florian Margaine -
Stelian Ionescu