In D3721#105497, @bgamari wrote:

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.

Right, but do we know that this won't break, for instance, AIX or OpenBSD?

In D3721#105761, @bgamari wrote:

Right, but do we know that this won't break, for instance, AIX or OpenBSD?

-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.

In D3721#105765, @angerman wrote:

In D3721#105761, @bgamari wrote:

Right, but do we know that this won't break, for instance, AIX or OpenBSD?

-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.)

Ahhh right, of course. I keep forgetting this was previously Darwin-only. Sounds fine to me.

In D3721#107290, @angerman wrote:

In D3721#107237, @bgamari wrote:

If I'm not mistaken we decided against this approach.

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?

In D3721#107316, @bgamari wrote:

In D3721#107290, @angerman wrote:

In D3721#107237, @bgamari wrote:

If I'm not mistaken we decided against this approach.

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.