Hopefully we can get rid of libtool, by using ar only
Depends on: D3579
Automatic diff as part of commit; lint not applicable. |
Automatic diff as part of commit; unit tests not applicable. |
Can you fix the warnings?
Are you sure we want to do this? Afterall, libtool exists for a reason; creating static libraries can be quite tricky on some platforms.
This is what libtool on macOS says
Apple Inc. version cctools-898
Libtool with -static is intended to replace ar(5) and ranlib.
and this is what libtool on my debian says:
libtool (GNU libtool) 2.4.2 Written by Gordon Matzigkeit <gord@gnu.ai.mit.edu>, 1996 Copyright (C) 2011 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
If OUTPUT-FILE ends in `.a' or `.lib', then a standard library is created using `ar' and `ranlib', or on Windows using `lib'.
While there are .la libtool archives, the -staticlib flag for GHC has always just produced an archive of all the object
files, ready to be linked with ld into an executable.
-staticlib was available on iOS/macOS only so far. And the other patch requires a libtool that behaves sufficiently similar or a wrapper script (that uses ar). I just hope this allows us to stay out of the libtool for staticlibs mess. (And we already use ar to create archives.)
I still want to do some additional tests with this patch over the weekend.
Ahhh right, of course. I keep forgetting this was previously Darwin-only. Sounds fine to me.
This falls apart as soon as an archive contains multiple files of the same name.
Extracting files onto the file system thus inevitably results in conflicts.
We did? When? With the Ar.hs this now specifically sidesteps the issues with libtool and ar.
Wait a moment; I'm terribly confused in that case. I thought that using libtool handled the duplicate file case properly. Is this not so?
The earlier diff, which was landed a while ago uses libtool. However this requires the presence of libtool (or the libtool-lite script which relies on GNU ar with MRI librarian support). libtool is quite different on each platform (the one on macOS is nothing like GNU libtool).
libtool for static archives does essentially: concatinate the input archives, add the input objects, and create a symbol index.
As Archives are rather simple structurally, we can just build the archives with Haskell directly and use ranlib on the final result to get the symbol index. This is what this diff does and it seems simpler to me and superior to trying to deal with the differences/abailability of libtool across platforms.
Alright, I suppose this is reasonable if libtool really is that inconsistent (thanks, Apple!). However, let's document the reason why we are doing this. Can you add a small note to Ar.hs saying what you said above? Then I promise I'll accept it :)