Mold Linker Jumps From v2.4.1 To v2.30 To Resolve GNU libtool Compatibility

[phoronix]

Phoronix: Mold Linker Jumps From v2.4.1 To v2.30 To Resolve GNU libtool Compatibility

Mold 2.30 is out this weekend as the newest version of this open-source high speed linker alternative to GNU Gold/LD and LLVM LLD...

https://www.phoronix.com/news/Mold-Linker-2.30-Released

[tildearrow]

Michael I thought you stopped using that disgusting former logo.

[bug77]

This change was made to prevent GNU libtool from mistaking mold 2.4.1 for GNU ld 2.4.1

Nasty bug right there. I guess fixing it was out of the question...

[varikonniemi]

libtool should feel ashamed such workarounds are needed around their snowflake program....

[fitzie]

libtool should feel ashamed such workarounds are needed around their snowflake program....

libtool has no shame. anyone still using it or autoconf/make in 2024 are clearly stuck up a creek without a paddle, so kudos for mold for helping them out.

[cend]

libtool has no shame. anyone still using it or autoconf/make in 2024 are clearly stuck up a creek without a paddle, so kudos for mold for helping them out.

There are projects maintained since all the way to 1990s that still rely on it.

[Blademasterz]

ew libtool, my homies use slibtool

[brad0]

libtool should feel ashamed such workarounds are needed around their snowflake program....

Typical low IQ comment.

[fitzie]

There are projects maintained since all the way to 1990s that still rely on it.

any project that hasn't moved to meson or cmake is just frozen in time with little sign of life. sure there's a lot of important software in such a state, but that's exactly my point, mold putting this hack isn't for those software devs, its for distros and system administrators trying to build frozen software with a modern toolchain.

[Vorpal]

any project that hasn't moved to meson or cmake is just frozen in time with little sign of life. sure there's a lot of important software in such a state, but that's exactly my point, mold putting this hack isn't for those software devs, its for distros and system administrators trying to build frozen software with a modern toolchain.

Or it is GNU software. Lots of GNU software (binutils, GCC, glibc, etc) still use autotools as far as I know. I don't know of any GNU software that doesn't use autotools, but I have not checked exhaustively.

And then there is a whole bunch of other projects that keep it out of inertia (it isn't working badly enough that they have reason to switch). Doesn't mean that the project itself is dead though as you seem to imply. I wouldn't consider Python to be "frozen in time with little sign of life" for example. Or ruby. Or a whole bunch of other long lived software.

There is a whole bunch of projects still using plain make files after all, or custom make-based build systems. So your generalisation really doesn't work. What is true though as far as I know is that there aren't many newly created projects using autotools.