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

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Roland Mainz

Hi!

---

While doing debugging for another issue I came across the following build failure in krb5 HEAD (zip'ed src archive from 2014-09-01/20:05h CEST) with --enable-static --disable-shared on RHEL5/Linux/IA64:
-- snip --
../lib/libverto.a(verto-k5ev.o): In function `periodic_recalc':
/home/rmainz/work/krb5/krb5-master/build2_static/util/verto/../../../src/util/verto/ev.c:2218: undefined reference to `ceil'
/home/rmainz/work/krb5/krb5-master/build2_static/util/verto/../../../src/util/verto/ev.c:2218: undefined reference to `ceil'
/home/rmainz/work/krb5/krb5-master/build2_static/util/verto/../../../src/util/verto/ev.c:2218: undefined reference to `ceil'
collect2: ld returned 1 exit status
make[1]: *** [krb5kdc] Error 1
make[1]: Leaving directory `/home/rmainz/work/krb5/krb5-master/build2_static/kdc'
make: *** [all-recurse] Error 1
-- snip --


Straightforward patch is a simple:
-- snip --
$ diff -u src/configure.in.original src/configure.in
--- src/configure.in.original   2014-09-01 14:44:21.000000000 -0400
+++ src/configure.in    2014-09-01 14:44:39.000000000 -0400
@@ -1260,7 +1260,7 @@
   [AC_HELP_STRING([--with-system-verto], [always use system verto library])],
   [], [with_system_verto=default])
 VERTO_CFLAGS=
-VERTO_LIBS="-lverto"
+VERTO_LIBS="-lverto -lm"
 VERTO_VERSION=k5
 if test "x$with_system_verto" != xno; then
   if verto_cflags=`pkg-config --cflags libverto 2>&1`; then
-- snip --

With that patch the build succeeds... :-)

----

Bye,
Roland

--
  __ .  . __
 (o.\ \/ /.o) [hidden email]
  \__\/\/__/  IPA/Kerberos5 team
  /O /==\ O\  
 (;O/ \/ \O;)
 
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

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

Greg Hudson
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.

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.  In the
meantime, we have added another pluggable interface with an in-tree
module, and have expanded our automated test coverage to include PKINIT
and the new TLS plugin module, neither of which will work in a static build.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

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

Roland Mainz


----- Original Message -----

> From: "Greg Hudson" <[hidden email]>
> To: "Roland Mainz" <[hidden email]>, [hidden email]
> 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) [hidden email]
  \__\/\/__/  IPA/Kerberos5 team
  /O /==\ O\  
 (;O/ \/ \O;)
 
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

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

Greg Hudson
On 09/02/2014 12:30 PM, Roland Mainz wrote:
>> 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 ...

Only the in-tree libverto needs libm (because it includes an embedded
libev).  And with shared linking, you neither need nor want to list the
dependencies of a library when linking against it.

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

Coverity works fine without static linking.

The other tools you listed appear to be for whole-program optimization
at link time.  Unless someone can document substantial benefits from
using link-time optimization with the Kerberos tree, I don't think it
warrants the additional build system complexity.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

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

Roland Mainz


----- Original Message -----
[snip]

> > ... 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).
>
> Coverity works fine without static linking.

>From what I've seen on last FOSDEM Coverity works better when it has access to all sources...

> The other tools you listed appear to be for whole-program optimization
> at link time.  Unless someone can document substantial benefits from
> using link-time optimization with the Kerberos tree, I don't think it
> warrants the additional build system complexity.

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

... 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 ? ;-) ) ?

----

Bye,
Roland

--
  __ .  . __
 (o.\ \/ /.o) [hidden email]
  \__\/\/__/  IPA/Kerberos5 team
  /O /==\ O\  
 (;O/ \/ \O;)
 
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

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

Greg Hudson
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.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev