[syslog-ng] differing linking options

[Balazs Scheidler]

Hi,

@Corinna: I'm ccing you because of a cygwin question at the end of this
email. Thanks for answering it if you have time.

While cherry-picking changes from your tree at
git://git.balabit.hu/syslog-ng-team/syslog-ng-core-4.1.git

I've noticed that you are changing linking command lines for modules,
which would break mixed linking mode used by Linux distributions in
their native packages.

Since it's bad to differ on things like this, I've figured it might make
sense to come to a solution that's good for both of us.

This is the patch that adds the new libraries:

commit 23ca7a66c5a612ee7135c2543d707c7e484571a1
Author: Tamas Pal <folti at balabit.hu>
Date:   Tue Mar 29 11:42:00 2011 +0200

    [autoconfuse]: make system specific libafsocket symlink with the proper shlib extension. Added proper LIBS dependencies, to prevent linking error in case libtool fails to parse .la files properly

And this is the hunk that is (for instance) problematic:

-libafsocket_notls_la_LIBADD = ../../lib/libsyslog-ng.la $(LIBNET_LIBS) $(LIBWRAP_LIBS)
+libafsocket_notls_la_LIBADD = ../../lib/libsyslog-ng.la $(LIBNET_LIBS) $(LIBWRAP_LIBS) $(GLIB_LIBS) $(EVTLOG_LIBS) $(IVYKIS_LIBS)

The technical issue at hand is that glib, evtlog and ivykis can 
all be static libraries in mixed mode, which would result in 
their inclusion into each module shared object, causing trouble 
at runtime. (not to mention that the static libs are probably 
not compiled with -fPIC so they cannot be linked into .so files).

I do have a problem with AIX linking with 3.2 now, which is 
probably the root cause that you've added these libraries 
into the Makefiles in the first place.

AIX linker is quite restrictive on how symbols are reexported from the 
main executable, but I do remember I could successfully 
create a linking mode that worked on AIX and wasn't broken 
on Linux in mixed mode. Clearly adding the libraries to that
command line unconditionally is not such a combination.

Mixed mode doesn't need to be supported on AIX, (I wouldn't dare 
to try to support that with non-GNU linkers). I think the breakage 
is rooted by the addition of -no-undefined to the libtool command 
line, which causes the AIX linker to ignore symbols exported by 
the main executable.

-no-undefined was added to catch errors on Cygwin, which doesn't allow
to link DLLs with undefined symbols in them.

The questions are:

1) Since last time we've checked that OSE 3.2 built on cygwin, 
which doesn't include those libs, I think the cygwin linker would 
accept symbols exported by the dependencies of libsyslog-ng.so. Is 
that right Corinna?

2) AIX seems to have worked without -no-undefined (I've just retried that 
with 3.2.3, and confirmed that works).

3) @syslog-ng-team: Are there any other reasons you've included the libs explicitly 
on those command lines?

So I'm proposing to make -no-undefined conditional, and only include 
it on non-AIX versions, and skip the listing of libs provided by 
libsyslog-ng.so from LIBADD.

What do you think?

-- 
Bazsi