| |||||||||||||
OpenIndiana lead Alasdair Lumsden resignsOpenIndiana lead Alasdair Lumsden resignsPosted Sep 2, 2012 21:04 UTC (Sun) by nix (subscriber, #2304)In reply to: OpenIndiana lead Alasdair Lumsden resigns by peterj Parent article: OpenIndiana lead Alasdair Lumsden resigns
Libtool and autotools are classic double- speak - they claim to promote portability but actually do the opposite - the code might be portable but autotools and libtool still endeavour to make building the code as painful as possible unless you have a GNU toolchain (preferably on Linux).This is obviously an entirely different autotools and libtool than I have used, perhaps from a parallel dimension or something. The autotools (and gnulib) maintainers are some of the most portability-crazed people I have ever heard of.
(Log in to post comments)
OpenIndiana lead Alasdair Lumsden resigns Posted Sep 3, 2012 11:13 UTC (Mon) by schily (guest, #60311) [Link]
Try to have a look beyond your own nose:
libtool handles "portability" on Linux but does not even handle basic ld features like -L and -R options correctly.
All a bit more complex projects have problems compiling on Solaris because usually -R is not used and the linked binaries thus will not find their libraries and this is definitely not a Solaris caused problem.
BTW: even "autotools" is a step from autoconf into the wrong direction. Autoconf (as documented by the FSF is based on self modifying makefiles - a technique from the 1970s). What the FSF calls "automake" is definitely not an automake program but something that makes people believe that it will create portable makefiles but does not. What it really does is to propagate code that depends on bugs and extensions of gmake.
OpenIndiana lead Alasdair Lumsden resigns Posted Sep 5, 2012 23:57 UTC (Wed) by nix (subscriber, #2304) [Link] 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.)
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....
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.
- Linux uses the old runtime linker that was written for a.out
- It may be that recent libtool versions are better, but there is too much
- It seems that you just know too few things about GNU autoconf.
- Using "configure" to create something like config.h (as done in the
- It seems that Paul Smith copied the ideas for a more modern
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.)
|
|||||||||||||