Unit tests of internal functions

[Jeffrey Hutzelman]

--On Wednesday, December 30, 2009 07:54:34 AM -0500 Marcus Watts 
<mdw at umich.edu> wrote:

> I quite agree that libtool sucks.  It "knows" too much about what it's
> doing, there isn't any easy way to override what it's doing, and it's
> nearly impossible to figure out what it's doing.  The core script is 8000
> lines of nearly indecipherable shell code.  Clearly Jeff knows what's
> in there.

No; that's mostly information I re-derive when I have to, which is 
thankfully quite rare.  I have a perl script that knows how to apply our 
modifications to the shell script.

> With another package, I wound up hacking its copy of libtool to
> put the proper "-Wl,-rpath," into it.  I actually don't want to
> have to patch it to override its behavior, but it was easier
> to fix the binary after configure made it than to figure out
> what to feed into configure or elsewhere to get the right results.

This is probably substantially the same problem we patch around.  It 
affects packages that provide a shared library and something that depends 
on it (or maybe only a shared library, a shared library that depends on it, 
and a program that depends on _that_).


> I'm currently staring at yet another project.  It wants to use
> "-fstack-protector".  The make subsystem passes it into libtool.  The .o
> files get made with it, but not the shared library, which consequently
> fails to link.  Note: unlike Jeff, I am not trying for special behavior.
> This is "off the shelf" behavior, of the latest version of a common
> package, using the latest version of many of its various dependencies.
> This should not be an 'exotic' build, but apparently, it is.

Yeah; one of libtool's failings is it thinks it knows better than you do 
what switches belong to whom.  You may be able to work around this by 
adding -Wl,-fstack-protector.  Or maybe not.  Note that I'm trying to offer 
practical advice here, not arguing that the example is invalid.



> Did I mention how I hate that libtool slows things down?

Yeah; that is annoying.

> I'll resist the temptation to talk about .libs, install-time relinking,
> or that special joy of trying to run gdb on what turns out to be a shell
> script.

Oh, we generally skip install-time relinking.



> The point here is that libtool has to understand the behavior of all the
> options that get fed into gcc, ld, and (it seems) a fair amount about the
> local filesystem, in order to do what it does.  It can't get it completely
> right, not for all the stuff it's trying to do, not for all the packages
> that use it.  It's neither easy nor simple to make it do the right thing,
> even for the obvious common cases, like "rm: invalid argument".

It doesn't help that it is, IMHO, an unmaintainable heap of crap.



However, I think my original point stands to some extent.  It sucks, but it 
sucks less than a package which reinvents the wheel, gets it wrong, and 
then I have to figure out how to coerce it into doing what I want/need.  At 
least with libtool, I've done that work once and can more or less apply it 
to every package I see.


It would be nice to have a tool that solves the same problems as libtool, 
but does a better job of it, has less detailed knowledge of the behavior of 
compilers and other tools, produces less kludgy output, at least on most 
platforms, and is fast, portable, and maintainable.  I suspect we're less 
likely to get that than the pony we've always wanted.

-- Jeff