6 ms·

Please just sunset it and recommend projects adopt better tools. And if not, please please please please deprecate libtool, which is the worst abomination. Mak

Please just sunset it and recommend projects adopt better tools. 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).

intc 6y ago
> deprecate libtool.. I don't quite understand this. What if one uses something else than clang or gcc on the target system?
- jonstewart 6y ago
  Like an ancient compiler that’s also deprecated...?
- JoshTriplett 6y ago
  libtool isn't primarily about portability across compilers; libtool is about portability across linkers and library formats, from the days when there were many systems with deficient library support. It's not unreasonable to assume a modern linker, and modern library support.
  - rvp-x 6y ago
    People still use macOS, which is the main reason I see "please add libtool support" these days.
    - JoshTriplett 6y ago
      It's possible to handle libraries on macOS without libtool.
dig1 6y ago
I had the same opinion until I had to ship the app with shared libraries on different BSD versions and a few older Solarises, besides multiple Linux distributions. Even then, I wasn't sure it would work without problems. 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.
- jonstewart 6y ago
  Would you still have to ship your app on a variety of BSDs and older Solaris versions in 2021, though? 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).
- rleigh 6y ago
  Libtool attempted (badly) to solve portability problems between the diverse range of linkers on 90s Unix platforms. Its versioning scheme is utterly insane. It made a slightly difficult problem incredibly complex, and for no good reason. 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.
jcranmer 6y ago
I still vividly remember the time libtool decided to drop "-flto" from the linker command line, because it decided that dropping unknown options would be more likely to make the link work. Dropping "-flto" rather has the opposite effect, and there was no way to force libtool to actually accept it, since it would drop it even when the user specifically requests it in the linking flags environment variable. From that day forward, I never want to work with libtool ever again.

intc 6y ago

> deprecate libtool.. I don't quite understand this. What if one uses something else than clang or gcc on the target system?

jonstewart 6y ago
Like an ancient compiler that’s also deprecated...?
JoshTriplett 6y ago
libtool isn't primarily about portability across compilers; libtool is about portability across linkers and library formats, from the days when there were many systems with deficient library support. It's not unreasonable to assume a modern linker, and modern library support.
- rvp-x 6y ago
  People still use macOS, which is the main reason I see "please add libtool support" these days.
  - JoshTriplett 6y ago
    It's possible to handle libraries on macOS without libtool.

dig1 6y ago

I had the same opinion until I had to ship the app with shared libraries on different BSD versions and a few older Solarises, besides multiple Linux distributions. Even then, I wasn't sure it would work without problems. 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.

jonstewart 6y ago
Would you still have to ship your app on a variety of BSDs and older Solaris versions in 2021, though? 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).
rleigh 6y ago
Libtool attempted (badly) to solve portability problems between the diverse range of linkers on 90s Unix platforms. Its versioning scheme is utterly insane. It made a slightly difficult problem incredibly complex, and for no good reason. 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.

jcranmer 6y ago

I still vividly remember the time libtool decided to drop "-flto" from the linker command line, because it decided that dropping unknown options would be more likely to make the link work. Dropping "-flto" rather has the opposite effect, and there was no way to force libtool to actually accept it, since it would drop it even when the user specifically requests it in the linking flags environment variable. From that day forward, I never want to work with libtool ever again.