OpenIndiana lead Alasdair Lumsden resigns [LWN.net]

OpenIndiana lead Alasdair Lumsden resigns

Posted Sep 5, 2012 23:57 UTC (Wed) by nix (subscriber, #2304)
In reply to: OpenIndiana lead Alasdair Lumsden resigns by schily
Parent article: OpenIndiana lead Alasdair Lumsden resigns

Well, this is the kind of attention to detail that gives you (and Solaris, alas, if people should think you have anything to do with Solaris, which thankfully you do not) a bad name. (If people want to see what Solaris hackers are actually like, I recommend talking to Alan Coopersmith. A more charming and helpful man was never born.)

The -R (DT_RPATH) handling in Libtool was very carefully thought out specifically so as to work properly on both systems with an /etc/ld.so.conf-equivalent (like Linux) and systems which prefer DT_RPATH (like Solaris). If you have a problem with it, I might recommend you report it: but configure / make / make install with a variety of prefixes and DESTDIRs works perfectly in my testing. (There have been bugs in this area, but not for a long time). It is definitely unacceptable to just use DT_RPATH, since that would torpedo Linux systems. Instead, we provide an implementation which permits you to use -R to get the effect of DT_RPATH, while instead providing whatever implementation is preferred on the system being used (including 'none' for systems like Linux, if the user so requests). That's kind of what Libtool is all about, after all.

As for 'self modifying makefiles', you really do have no clue what you're talking about here. Autoconf is based on M4-driven generation of shell scripts. Automake is based on Perl-driven generation of makefiles (which do in fact warn about non-POSIX-make features, but most people sensibly don't care because GNU make is portable and most non-GNU makes are a horror show: here I explicitly include the coredumping halfwitted feature-free pile that is Solaris make: I have fairly frequent nightmares about the ten years I spent forced to keep things working with it).

Nothing whatsoever in GNU autotools is based on 'self-modifying Makefiles'. Perhaps you are talking about the dependency generation in Automake-driven makefiles, which does rely on generation of makefile fragments which are then included, but does not require self-modifying a makefile, unlike the 'make depend' system it generally replaced.

The makefile-fragment scheme may be 'a technique from the 1970s' but I'll note that this is both a non sequitur and untrue, since makes didn't have the ability to automatically reload their makefiles if their include dependencies had been modified until long long after that. Furthermore, it doesn't matter how old the scheme is: it works, and it is completely transparent to the user, unlike the horrible old 'make depend' system, which worked fine until you deleted or moved a file with generated dependencies, whereupon everything fell down in a screaming heap until you hand-hacked the dependencies or did a complete 'make clean' and rebuilt. Clearly you haven't read Paul D. Smith's excellent paper on this algorithm (due to Tom Tromey), which clearly describes the reasons why the scheme was implemented as it was.

(Actually, sorry, perhaps I was wrong: quite possibly you have read that paper. I'd forgotten how immune to reasoned argument you are. My apologies. For a moment I thought I was talking to a rational being.)

(corbet: sorry about the tone here, but I consider it important to refute schily's untruths, and further that, to be blunt, driving off schily before he converts the entire site into a single giant flamewar is more important than civility in this instance, not least since schily has long since proved himself incapable of civilized discourse. We are talking about someone who got himself banned from the Debian bugtracker(!) for repeated kibozing and trolling, after all.)

(Log in to post comments)

OpenIndiana lead Alasdair Lumsden resigns

Posted Sep 6, 2012 10:45 UTC (Thu) by schily (guest, #60311) [Link]

People like you are responsible for the bad taste Linux has in the public.

Attacking people for a bug description is more than a fauxpas....
Doing this with a non-personalized nick is even worse.

BTW: this was different before aprox. 2004. Before that time Linux people generally have been very polite and helpful. Since then there are so many unfriendly people that these people unfortunately dominate the rest in the public.

Looking at your reply shows that you don't know what you are talking of.

- If you like to associate -R with an environment, it is LD_RUN_PATH.
DT_RPATH does not exist.

- Linux uses the old runtime linker that was written for a.out
This is why linker-caching and path setup exist. ELF has a RUNPATH
property that is better than the method in the old a.out system.

- It may be that recent libtool versions are better, but there is too much
software out that uses non-working versions

- It seems that you just know too few things about GNU autoconf.
Knowing that it is based on m4 is not sufficient to understand that
the documentation from the FSF in how to use it is based on outdated
technologies from the 1970s.

- Using "configure" to create something like config.h (as done in the
schily makfile system) is OK

- It seems that Paul Smith copied the ideas for a more modern
autodependency handling from Sun's ideas and implementations in
SunPro make from 1986 and from the Schily makefilesystem that
implemented this method in a portable way in the 1990s. He however
implemented the support in a gmake in a buggy way as gmake spits out
warnings for things that are expected due to his strange algorithm.

OpenIndiana lead Alasdair Lumsden resigns

Posted Sep 6, 2012 13:04 UTC (Thu) by mpr22 (subscriber, #60784) [Link]

It may be that recent libtool versions are better, but there is too much software out that uses non-working versions

That's not an argument for claiming that libtool is bad. That's an argument for claiming that the software that uses bad versions of libtool is bad (and I will cheerfully admit that there's a lot of badly maintained software out there that, if it runs on anything except Linux, does so only by serendipity).

ELF has a RUNPATH property that is better than the method in the old a.out system.

And the GNU dynamic linker, used on Linux, supports it.

OpenIndiana lead Alasdair Lumsden resigns

Posted Sep 8, 2012 16:08 UTC (Sat) by nix (subscriber, #2304) [Link]

Oh gods, this is hilarious. Unintentionally, of course, but still.

Let's go down your fun little list one by one, as far as it is worth it to go.

- DT_RPATH does exist. It is the name of the ELF dynamic tag that is used to implement various linkers' RPATH flags. (It sucks because it wires paths into binaries in a way that is impossible to override without binary editing: DT_RUNPATH sucks slightly less, but still wires paths into binaries, which is less than good).

- The glibc runtime linker was rewritten from scratch for ELF support. It doesn't support a.out, and never has. Linker caching exists because it provides a huge speedup over searching at runtime; its search path exists to allow that to be customized; and RUNPATH is a mild abomination, as you would immediately realize if you had ever had a binary with a runpath that had a path baked into it (often a build path) which was pointing to an NFS server that had become unavailable. I've used Solaris for many, many years, and believe me the number of bugs we had reported that were attributable to mis-set LD_LIBRARY_PATHs (which were *all supposed to have the same value* and which on Linux would just have been set in /etc/ld.so.conf) was simply astonishing.

The rest of your comment is as far as I can tell pure ad hominems, arguments from authority, and straw man attacks, not worthy of a response. ("based on outdated technologies from the 1970s", I'll bet if I ask the actual authors, the only people who might know, they would disagree.)