Unit tests of internal functions

[Mike Patnode]

Ditto.   It's a necessary evil.  Maintaining a Kerberos specific version
may reduce the pain.

mp

-----Original Message-----
From: krbdev-bounces at mit.edu [mailto:krbdev-bounces at mit.edu] On Behalf
Of Marcus Watts
Sent: Wednesday, December 30, 2009 4:55 AM
To: krbdev at mit.edu
Subject: Re: Unit tests of internal functions 

Jeff Hutzelman <jhutz at cmu.edu> writes:
...
> Libtool sucks.
> 
> However, as someone who builds and deploys a lot of software, my
preference 
> is that _every_ package that builds shared libraries uses libtool.
> 
> Why?  Because it turns out that some of the most annoying problems can
be 
> made to go away with a relatively minor patch to libtool, at the
expense of 
> making it not work at all on a couple of platforms I happen not to
care 
> about.  We locally maintain patched libtool, and simply relibtoolize
each 
> package as it comes in.  We also maintain local patches that help us
adjust 
> the soname of every shared library to depend on the versions of its 
> dependencies.  So, for example, a (Heimdal) libkrb5.so built against 
> OpenSSL 0.9.8 will have a different soname from the same version of 
> libkrb5.so built against OpenSSL 0.9.7.  This turns out to be really 
> important when you have complex applications with multiple direct and 
> indirect dependencies on the same library.
> 
> Anyway, the point is, if a package uses libtool, I can get all the
special 
> behavior I need by relibtoolizing.  If it doesn't, I get to figure out
how 
> its super-special shared-library build system works.
> 
> So, libtool sucks, but please, use it anyway.
> 
> -- Jeff

I build a lot of software as well.
Please don't use libtool.
Or if you must, please fix it so it doesn't suck first.

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.  If I'm "just" building vanilla packages, I would prefer not
to need to know.

Out of a "random" selection of about 250+ packages,
at least 20+ of them use libtool.  (maybe 25% overall).  I
currently have a bunch of these that build with this error.
	rm: invalid argument: `'
This appears frequently in google - this is clearly a well-known
warning most everyone ignores.  But here's somebody's fix:
	
http://github.com/php/php-src/commit/26e4b42d0e1d97e5f85a1d529978ad4d86b
7b99c
so why is this fix not upstream already?

libtool from another package says:
libtool: install: error: cannot install `libbeecrypt_java.la' to a
directory not ending in
 /usr/lib at LIBALT@
huh?
Ok, so it's bitrot, and I didn't really need that part anyways.

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.

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.

Did I mention how I hate that libtool slows things down?  I know
machines
are fast and all, but honestly, I don't think we need to slow them back
down to the speed of a vax.  Processing 8 lines of shell script per line
of C source should just not be necessary.

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.

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".

					-Marcus Watts
_______________________________________________
krbdev mailing list             krbdev at mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev