[syslog-ng] linking changes

[Balazs Scheidler]

Hi,

On Wed, 2011-02-23 at 17:29 +0100, Corinna Vinschen wrote:
> On Feb 23 16:09, Balazs Scheidler wrote:
> > Before making a fool from myself, can you please check if this patch is
> > OK, before commit & push? (against the current HEAD).
> > 
> > My intention was:
> >   * create a static lib for linking with programs (unit tests & pdbtool)
> >   * recompile each source files as a part of the shared library
> > separately
> > 
> > This way:
> >   * no linking of static lib into shared lib happens
> > 
> > Also, a heads up: this will be a problem again in syslog-ng OSE 3.3,
> > where I started to embed dependent libraries into the syslog-ng tree
> > (ivykis, libmongo-client) because those are not yet in widespread use.
> > That's implemented using static libraries and -fPIC, and I don't see an
> > easy solution for that problem, unless of course one obtains and
> > installs those libraries separately.
> 
> ivykis and libmongo-client are not available for Cygwin.  Is there
> no way around using these libs by using conditional compilation?

There's a way, mongodb can be disabled using --disable-mongodb configure
option (but is enabled by default with the bundled libmongo-client
library).

ivykis is not so simple, syslog-ng core depends on that heavily. ivykis
is compiled as a static library (with -fPIC) and then linked into
libsyslog-ng.so

The staticlib is just a convenience library, however I'd like that to be
created by the ivykis configure/automake stuff, and would like to avoid
having to rewrite the build system for ivykis. Also, I wouldn't want to
install ivykis (as a shared object) from the syslog-ng tree, as I could
perhaps break people's setup if ivykis becomes more widely available.
(e.g. installed on the system).

Do you perhaps have an idea how to solve that differently?

> 
> If that's not feasible for some reason, could you please at least allow
> to disable affected modules from building so that not the entire build
> fails just because some modules won't work on some systems?
> 
> > $ git diff
> > diff --git a/modules/dbparser/Makefile.am b/modules/dbparser/Makefile.am
> > index b2ab700..7e4c366 100644
> > --- a/modules/dbparser/Makefile.am
> > +++ b/modules/dbparser/Makefile.am
> > @@ -11,26 +11,30 @@ AM_CPPFLAGS = -I$(top_srcdir)/lib -I../../lib
> >  AM_CFLAGS = @CFLAGS_NOWARN_POINTER_SIGN@
> >  export top_srcdir
> >  
> > -lib_LIBRARIES = libsyslog-ng-patterndb.a
> > +noinst_LIBRARIES = libsyslog-ng-patterndb.a
> >  libsyslog_ng_patterndb_a_SOURCES = radix.c radix.h \
> >         patterndb.c patterndb.h patterndb-int.h \
> >         timerwheel.c timerwheel.h \
> >         patternize.c patternize.h
> > -libsyslog_ng_patterndb_a_CFLAGS = $(AM_CFLAGS) -fPIC
> >  
> > +# we're not linking against the .a file as this is not supported on Cygwin,
> > +# even if we compile it using -fPIC.  Therefore the .a file is only used to
> > +# link programs, and the dbparser.so gets those files as source files,
> > +# thereby recompiling them twice.
> >  module_LTLIBRARIES = libdbparser.la
> >  libdbparser_la_SOURCES = \
> >         dbparser.c dbparser.h \
> > -       dbparser-grammar.y dbparser-parser.c dbparser-parser.h dbparser-plugin.c
> > +       dbparser-grammar.y dbparser-parser.c dbparser-parser.h dbparser-plugin.c \
> > +       $(libsyslog_ng_patterndb_a_SOURCES)
> >  
> >  libdbparser_la_CPPFLAGS = $(AM_CPPFLAGS)
> > -libdbparser_la_LIBADD = ../../lib/libsyslog-ng.la libsyslog-ng-patterndb.a
> > +libdbparser_la_LIBADD = ../../lib/libsyslog-ng.la
> 
> This fails to build on Cygwin because libdbparser_la_LIBADD is missing a
> @OPENSSL_LIBS@ (needed by patternize.c).
> 
> Amazing but true: Another restriction of the Windows platform is the
> inability to create shared libs with undefined symbols.  All symbols must
> be resolvable at link time.
> 
> >  libdbparser_la_LDFLAGS = -avoid-version -module -no-undefined
> >  
> >  bin_PROGRAMS = pdbtool
> >  pdbtool_SOURCES = pdbtool.c
> >  pdbtool_CPPFLAGS = $(AM_CPPFLAGS) @OPENSSL_CFLAGS@
> > -pdbtool_LDADD = ../../lib/libsyslog-ng.la libsyslog-ng-patterndb.a @TOOL_DEPS_LIBS@ @OPENSSL_LIBS@
> > +pdbtool_LDADD =  libsyslog-ng-patterndb.a ../../lib/libsyslog-ng.la @TOOL_DEPS_LIBS@ @OPENSSL_LIBS@
> >  
> >  BUILT_SOURCES = dbparser-grammar.y dbparser-grammar.c dbparser-grammar.h
> >  EXTRA_DIST = $(BUILT_SOURCES) radix-find.c dbparser-grammar.ym
> > diff --git a/modules/dbparser/tests/Makefile.am b/modules/dbparser/tests/Makefile.am
> > index 8d3a970..6726121 100644
> > --- a/modules/dbparser/tests/Makefile.am
> > +++ b/modules/dbparser/tests/Makefile.am
> > @@ -1,6 +1,6 @@
> >  AM_CFLAGS = -I$(top_srcdir)/lib -I../../../lib -I$(top_srcdir)/modules/dbparser -I.. @CFLAGS_NOWARN_POINTER_SIGN@
> >  AM_LDFLAGS = -dlpreopen ../../syslogformat/libsyslogformat.la
> > -LDADD = $(top_builddir)/lib/libsyslog-ng.la ../libsyslog-ng-patterndb.a  ../patternize.lo @TOOL_DEPS_LIBS@ @OPENSSL_LIBS@
> > +LDADD = $(top_builddir)/lib/libsyslog-ng.la ../libsyslog-ng-patterndb.a @TOOL_DEPS_LIBS@ @OPENSSL_LIBS@
> 
> I didn't test that, but shouldn't this LDADD be reordered as well, just
> as in the pdbtool_LDADD case?
> 
>   LDADD = ../libsyslog-ng-patterndb.a $(top_builddir)/lib/libsyslog-ng.la @TOOL_DEPS_LIBS@ @OPENSSL_LIBS@

Good catch, also applied.

> 
> Btw., I'm seeing a lot of
> 
>   foo.y: warning: X nonterminals useless in grammar
>   foo.y: warning: Y rules useless in grammar
> 
> messages.  Aren't the grep calls in build/lex-rules.am wrong?
> 
>   grep -E -v "warning: (nonterminals|rules) useless in grammar
> 
> instead of 
> 
>   grep -E -v "warning: (nonterminal|rule) useless in grammar
> 
> ?  Or does the message depend on the version of yacc/bison used, perhaps?

Well, it seems to matter which bison version you are using. 3.3 has a
fix for this (where it accepts both the pural and the singular forms).

-- 
Bazsi