[18995] in Kerberos_V5_Development
Re: [patch] krb5 HEAD fails to build on RHEL5/Linux/IA64 with $
daemon@ATHENA.MIT.EDU (Roland Mainz)
Tue Sep 2 12:30:21 2014
Date: Tue, 2 Sep 2014 12:30:05 -0400 (EDT)
From: Roland Mainz <rmainz@redhat.com>
To: Greg Hudson <ghudson@mit.edu>
Message-ID: <740815884.27297643.1409675405026.JavaMail.zimbra@redhat.com>
In-Reply-To: <5405ED86.6040307@mit.edu>
MIME-Version: 1.0
Cc: krbdev@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
----- Original Message -----
> From: "Greg Hudson" <ghudson@mit.edu>
> To: "Roland Mainz" <rmainz@redhat.com>, krbdev@mit.edu
> Sent: Tuesday, September 2, 2014 6:17:10 PM
> Subject: Re: [patch] krb5 HEAD fails to build on RHEL5/Linux/IA64 with $ configure --enable-static --disable-shared #
> ...
>
> On 09/01/2014 02:57 PM, Roland Mainz wrote:
> > -VERTO_LIBS="-lverto"
> > +VERTO_LIBS="-lverto -lm"
>
> This is too broad. libm should not be a linker dependency of krb5kdc
> and kadmind for non-static builds or when the system libverto is used.
Well... libverto needs libm ...
> Taking a step back, I think we are likely to get rid of static linking
> support rather than add more complexity to fix or improve it.
>
> Support for static linking was removed in 1.7 because our architecture
> was moving increasingly in the direction of loading plugin modules,
> including some in-tree modules like PKINIT, KDB modules, and now the TLS
> plugin module. I added limited static linking support back in for 1.8
> in order to be able to do test coverage analysis with gcov, but gcov now
> works with shared libraries, so the motivation is gone.
... but that was exactly the motivation why I wanted to fix the static build - almost all of the (static) analyzer/instrumentation software (minus the original "lint") need a "whole view" of all the sources to be able to analyze the code properly with *ALL* interdependencies... and so far none of them (e.g. tested with Sun Studio's XIPO, Coverity or gcc/clang -flto) can deal with compiled shared libraries (*.a archives are fine because the precompiled source code is embedded in special ELF chunks or (in the case of "clang") the *.o files in the archives are compiler-specific bytecode; creating shared libraries (*.so) will cause the linker to strip this information).
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) rmainz@redhat.com
\__\/\/__/ IPA/Kerberos5 team
/O /==\ O\
(;O/ \/ \O;)
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
