And if not, please please please please deprecate libtool, which is the worst abomination. Making shared libraries with gcc and clang is not hard, and libtool should never be adopted for new projects (yet the GNU docs recommend it).
libtool is ugly because it tries to solve an ugly problem. To support the above, my manual Makefile was uglier than libtool :)
These days, if I'd have to do that again, I'll pick libtool without overthinking.
People need to learn why some things are as such and should see outside of Ubuntu/Windows/macOS comfort.
On current BSDs, clang works. Solaris and HPUX and AIX and Ultrix and Irix are all, in a word, deprecated. The 2000+ line long shell script that’s used to figure out which args to pass to the compiler, determined on the fly for each source file, can still be used on those deprecated systems, but it should also probably be deprecated itself when all you need is “-fPIC” in your CFLAGS (an oversimplification but not by much).
Every current platform of note has a perfectly good linker, making libtool redundant. More often than not, it's been an "anti-portability" impediment when it thinks it knows how to drive modern linkers but because it's barely maintained, it gets it wrong by trying to be too clever.
Even proprietary embedded toolchains come with full-fat ELF linkers these days.
Of all of the pieces which make up the Autotools, libtool is the one which could be dropped today with zero impact. It's the least useful and the least necessary of them all.
From that day forward, I never want to work with libtool ever again.
I don't quite understand this. What if one uses something else than clang or gcc on the target system?