[SSSD] [PATCHES] Build-system improvements

Stephen Gallagher sgallagh at redhat.com
Mon May 23 14:58:21 UTC 2011


On Mon, 2011-05-23 at 08:39 +0200, Jan Zelený wrote:
> > On 05/20/2011 12:32 PM, Stephen Gallagher wrote:
> > > On Thu, 2011-05-19 at 10:53 +0200, Jakub Hrozek wrote:
> > >> On 05/18/2011 10:40 PM, Jan Zeleny wrote:
> > >>> Stephen Gallagher<sgallagh at redhat.com>  wrote:
> > >>>> Patch 0001: Stop building a fake interface version into the backend
> > >>>> plugins. This is not the correct way to create a plugin module with
> > >>>> libtool. Since the interface and the plugins are built at the same
> > >>>> time, the correct method is to produce an unversioned .so.
> > >>>> 
> > >>>> Patch 0002: Build the sssd utility sources as an internal libtool
> > >>>> helper library. This should speed the build up quite a bit, as what
> > >>>> we had been doing is rebuilding all of the common sources for each
> > >>>> binary and library. We will now build them once as a helper library
> > >>>> that is statically linked into those binaries that require them.
> > >>>> 
> > >>>> There is one caveat with this: we now have to explicitly link this
> > >>>> helper library to the plugins, instead of consuming them from the
> > >>>> sssd_be binary. This is because there is no way to export the
> > >>>> functions through sssd_be from a helper library (that I have been
> > >>>> able to find). They stopped being visible to the plugins.
> > >>>> 
> > >>>> I'm debating whether we should be statically linking all of this
> > >>>> common code at all, or whether the libsss_util.la should just become
> > >>>> a shared library in its own right. For the moment I've kept it as-is,
> > >>>> but as of this patch, it's trivial to change over to a shared
> > >>>> library. Comments welcome.
> > >>>> 
> > >>>> Please test patch 0002 very carefully. I tried most of the common
> > >>>> use-cases I could think of, but I'd prefer if it be tested in a few
> > >>>> additional environments.
> > >>> 
> > >>> I'm sorry, I have to nack this. I tried compilation couple times,
> > >>> always with
> > >>> 
> > >>> the same error:
> > >>>    CCLD   sssd
> > >>> 
> > >>> ./.libs/libsss_util.a(util.o): In function `diff_string_lists':
> > >>> /root/sssd/src/util/util.c:331: undefined reference to `hash_create'
> > >>> /root/sssd/src/util/util.c:344: undefined reference to `hash_enter'
> > >>> /root/sssd/src/util/util.c:356: undefined reference to `hash_delete'
> > >>> /root/sssd/src/util/util.c:404: undefined reference to `hash_keys'
> > >>> /root/sssd/src/util/util.c:461: undefined reference to `hash_destroy'
> > >>> ./.libs/libsss_util.a(util.o): In function `sss_hash_create_ex':
> > >>> /root/sssd/src/util/util.c:496: undefined reference to `hash_create_ex'
> > >>> /root/sssd/src/util/util.c:520: undefined reference to
> > >>> `hash_error_string'
> > >>> 
> > >>> 
> > >>> I got this error using both my installation script and standard make
> > >>> rpms.
> > >>> 
> > >>> 
> > >>> Jan
> > >> 
> > >> Shouldn't we pass $(AM_CFLAGS) to libsss_util_la_CFLAGS and similarly to
> > >> $(SSSD_LIBS) to libsss_util_la_LIBADD ? Adding these fixed the
> > >> compilation for me.
> > > 
> > > Strange that it built for me. But you're right, the $(SSSD_LIBS) should
> > > have been in LIBADD. There's no reason to add $(AM_CFLAGS) unless
> > > libsss_util_la_CFLAGS is being overridden. It's the default.
> > > 
> > > New patches attached.
> > 
> > These patches work for me. I tested make, make check and basic
> > functionality on multiple targets (F14 32bit and 64bit, RHEL6.1,
> > RHEL5.7) to test more toolchain and external library versions and
> > everything seems to be working fine.
> > 
> > I'll ack this patch unless you would like to have some more test run.
> 
> Everything seems to work for me as well.


Pushed to master.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20110523/b0d795cb/attachment.sig>


More information about the sssd-devel mailing list