[patch] krb5 HEAD fails to build on RHEL5/Linux/IA64 with $ configure --enable-static --disable-shared # ...

Greg Hudson ghudson at mit.edu
Tue Sep 2 13:23:20 EDT 2014


On 09/02/2014 01:12 PM, Roland Mainz wrote:
>> Coverity works fine without static linking.
> 
> From what I've seen on last FOSDEM Coverity works better when it has access to all sources...

As far as I know Coverity doesn't care how you do linking, as it keeps
its own internal database of compiled objects.  We have used Coverity
with MIT krb5 for years without any need for static build support.

> Erm... the point wasn't link-time optimisation in this case... it's whole-view, i.e. access to all sources and analysis of **ALL** interdependencies between all sources. The shared libraries are reducing the coverage of these tools down to just what's in the current sources and the shared libraries are handled as black boxes...

You listed three use-cases, two of which are link-time optimization and
the other of which doesn't benefit from static build support.  If you
have additional use cases which can benefit from static builds, I would
be interested in hearing them.  The abstract notion of giving the linker
access to all of the objects at once is not itself a use case.

> ... and finally: Static build works (except the IA64 issue I've reported and the assembler "fun" on x86/AMD64) ... why dump it if it works (or can be repaired easily) and has some benefits to Kerberos (e.g. Coverity doesn't cover all platforms and IMHO portability and analysis/instrumentation on as many platforms as possible is a good thing... right ? ;-) ) ?

It doesn't really work.  You wind up without PKINIT and HTTP proxy
support, and in the future it could get worse.  Repairing that isn't
easy; it would come at noticeable added complexity to the build system,
in addition to the complexity which is already there for the KDB module
interface.  Fixing the verto libm issue would be relatively easy
(although not as simple as the one-liner patch), but making it really
work would not.


More information about the krbdev mailing list