Newer libtool and autoconf versions?
Hi, Right now, the current 3.2.1 sources can't be build on Cygwin. Apart from two minor problems which are fixed in git (bugzilla items 101 and 102) and a refresh of the files in contrib/cygwin-packaging (bugzilla entry 103), there's a somewhat more troubeling problem. The source tarballs contain libtool/autoconf-generated files which have been created with older versions of these tools, namely libtool 2.2.6b and autoconf 2.65. In order to get a working libtool *.la dependency mechanism on Cygwin, these files have to be created with pretty new versions of libtool/autoconf, right now at least libtool 2.4 and autoconf 2.67 (automake is not affected). Otherwise, with the old versions, building the shared libs fails due to a libtool bug. While I can rectify this situation locally by running autoreconf, it would be nice if building syslog-ng from a tarball would work out of the box on Cygwin, just as on other systems. So, here's my question: Is it possible to generate subsequent source tarballs using these newer versions of libtool and autoconf? Thanks in advance, Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat
Hi, On Thu, 2010-12-09 at 15:12 +0100, Corinna Vinschen wrote:
Hi,
Right now, the current 3.2.1 sources can't be build on Cygwin. Apart from two minor problems which are fixed in git (bugzilla items 101 and 102) and a refresh of the files in contrib/cygwin-packaging (bugzilla entry 103), there's a somewhat more troubeling problem.
The source tarballs contain libtool/autoconf-generated files which have been created with older versions of these tools, namely libtool 2.2.6b and autoconf 2.65.
In order to get a working libtool *.la dependency mechanism on Cygwin, these files have to be created with pretty new versions of libtool/autoconf, right now at least libtool 2.4 and autoconf 2.67 (automake is not affected). Otherwise, with the old versions, building the shared libs fails due to a libtool bug.
While I can rectify this situation locally by running autoreconf, it would be nice if building syslog-ng from a tarball would work out of the box on Cygwin, just as on other systems.
So, here's my question: Is it possible to generate subsequent source tarballs using these newer versions of libtool and autoconf?
Well, it should be. Those files are generated on my development laptop, currently with Ubuntu lucid. maverick has autoconf 2.67, but still libtool 2.2.6b So it'll not be solved even if I upgrade to the next distro release. Any ideas why Ubuntu uses such an old libtool? -- Bazsi
On Thu, 2010-12-09 at 20:45 +0100, Balazs Scheidler wrote:
Hi,
On Thu, 2010-12-09 at 15:12 +0100, Corinna Vinschen wrote:
Hi,
Right now, the current 3.2.1 sources can't be build on Cygwin. Apart from two minor problems which are fixed in git (bugzilla items 101 and 102) and a refresh of the files in contrib/cygwin-packaging (bugzilla entry 103), there's a somewhat more troubeling problem.
The source tarballs contain libtool/autoconf-generated files which have been created with older versions of these tools, namely libtool 2.2.6b and autoconf 2.65.
In order to get a working libtool *.la dependency mechanism on Cygwin, these files have to be created with pretty new versions of libtool/autoconf, right now at least libtool 2.4 and autoconf 2.67 (automake is not affected). Otherwise, with the old versions, building the shared libs fails due to a libtool bug.
While I can rectify this situation locally by running autoreconf, it would be nice if building syslog-ng from a tarball would work out of the box on Cygwin, just as on other systems.
So, here's my question: Is it possible to generate subsequent source tarballs using these newer versions of libtool and autoconf?
Well, it should be. Those files are generated on my development laptop, currently with Ubuntu lucid.
maverick has autoconf 2.67, but still libtool 2.2.6b
So it'll not be solved even if I upgrade to the next distro release.
Any ideas why Ubuntu uses such an old libtool?
I've checked around, and as it seems the newest libtool is in Debian experimental (2.2.10). Even the latest Fedora is carrying 2.2.6b So for now, I can only promise to migrate to autoconf 2.67, but I'm reluctant to upgrade to libtool 2.4, so the autoreconf stuff will be needed for a little while. Hopefully natty will carry newer stuff. -- Bazsi
On Dec 9 21:13, Balazs Scheidler wrote:
On Thu, 2010-12-09 at 20:45 +0100, Balazs Scheidler wrote:
Hi,
On Thu, 2010-12-09 at 15:12 +0100, Corinna Vinschen wrote:
Hi,
Right now, the current 3.2.1 sources can't be build on Cygwin. Apart from two minor problems which are fixed in git (bugzilla items 101 and 102) and a refresh of the files in contrib/cygwin-packaging (bugzilla entry 103), there's a somewhat more troubeling problem.
The source tarballs contain libtool/autoconf-generated files which have been created with older versions of these tools, namely libtool 2.2.6b and autoconf 2.65. [...] So, here's my question: Is it possible to generate subsequent source tarballs using these newer versions of libtool and autoconf?
Well, it should be. Those files are generated on my development laptop, currently with Ubuntu lucid.
maverick has autoconf 2.67, but still libtool 2.2.6b
So it'll not be solved even if I upgrade to the next distro release.
Any ideas why Ubuntu uses such an old libtool?
I've checked around, and as it seems the newest libtool is in Debian experimental (2.2.10). Even the latest Fedora is carrying 2.2.6b
The latest Fedora (Fedora 14) comes with libtool 2.2.10.
So for now, I can only promise to migrate to autoconf 2.67, but I'm reluctant to upgrade to libtool 2.4, so the autoreconf stuff will be needed for a little while.
Ok, thank you. I can live with that. Especially since even with libtool 2.4 there's still a problem. Due to the way shared libs are handled on Windows, ther's a hardcoded mechanism in libtool which doesn't work overly well with syslog-ng. When installing the shared libs into $(localstatedir), libtool copies the .a (static lib) and .dll.a (link stub for DLL) files into that directory, while the actual module DLLs are copied to $(localstatedir)/../bin. My contrib/cygwin-packaging/cygwin-postinstall script fixes this situation. It removes the .a and .dll.a files and moves the DLLs over to /usr/lib/syslog-ng. That works, but I'd be glad to find a solution which does the right thing already at `make install' time, not only after applying some postinstall magic. I'll investigate this further. Anyway, for the time being, the new cygwin-postinstall script (https://bugzilla.balabit.com/show_bug.cgi?id=103) will do the job. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat
On Dec 10 10:30, Corinna Vinschen wrote:
On Dec 9 21:13, Balazs Scheidler wrote:
So for now, I can only promise to migrate to autoconf 2.67, but I'm reluctant to upgrade to libtool 2.4, so the autoreconf stuff will be needed for a little while.
Ok, thank you. I can live with that.
Especially since even with libtool 2.4 there's still a problem. Due to the way shared libs are handled on Windows, ther's a hardcoded mechanism in libtool which doesn't work overly well with syslog-ng. When installing the shared libs into $(localstatedir), libtool copies the .a (static lib) and .dll.a (link stub for DLL) files into that directory, while the actual module DLLs are copied to $(localstatedir)/../bin. My
Sorry, I messed up here. Make these directories $(libexecdir)/syslog-ng and $(libexecdir)/syslog-ng/../bin .
contrib/cygwin-packaging/cygwin-postinstall script fixes this situation. It removes the .a and .dll.a files and moves the DLLs over to /usr/lib/syslog-ng. That works, but I'd be glad to find a solution which does the right thing already at `make install' time, not only after applying some postinstall magic. I'll investigate this further.
I just got the hint that the libtool --mode=link option "-module" is supposed to do exactly this on Cygwin. I tested it and with this option the subsequent `make install' actually copies the DLLs into the $(libexecdir)/syslog-ng directory where they belong. I checked that the -module option is already known to libtool 2.2.6, so it seems it would make sense to add this option generically to the Makefile.am files in the modules subdirectories, along these lines. --- SNIP --- diff --git a/modules/affile/Makefile.am b/modules/affile/Makefile.am index 9917ebf..04dbaae 100644 --- a/modules/affile/Makefile.am +++ b/modules/affile/Makefile.am @@ -12,6 +12,6 @@ EXTRA_DIST = $(BUILT_SOURCES) affile-grammar.ym libaffile_la_CPPFLAGS = $(AM_CPPFLAGS) libaffile_la_LIBADD = ../../lib/libsyslog-ng.la -libaffile_la_LDFLAGS = -avoid-version +libaffile_la_LDFLAGS = -avoid-version -module include $(top_srcdir)/build/lex-rules.am --- SNAP --- Would that be ok with you?
Anyway, for the time being, the new cygwin-postinstall script (https://bugzilla.balabit.com/show_bug.cgi?id=103) will do the job.
If the aforementioned -module option is a viable approach, I would have to change the contrib/cygwin-packaging/cygwin-postinstall script again, so in this case I would upload a new patch to bugzilla issue 103. Thanks in advance, Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat
On Dec 10 17:57, Corinna Vinschen wrote:
I just got the hint that the libtool --mode=link option "-module" is supposed to do exactly this on Cygwin. I tested it and with this option the subsequent `make install' actually copies the DLLs into the $(libexecdir)/syslog-ng directory where they belong.
I checked that the -module option is already known to libtool 2.2.6, so it seems it would make sense to add this option generically to the Makefile.am files in the modules subdirectories, along these lines.
--- SNIP --- diff --git a/modules/affile/Makefile.am b/modules/affile/Makefile.am index 9917ebf..04dbaae 100644 --- a/modules/affile/Makefile.am +++ b/modules/affile/Makefile.am @@ -12,6 +12,6 @@ EXTRA_DIST = $(BUILT_SOURCES) affile-grammar.ym
libaffile_la_CPPFLAGS = $(AM_CPPFLAGS) libaffile_la_LIBADD = ../../lib/libsyslog-ng.la -libaffile_la_LDFLAGS = -avoid-version +libaffile_la_LDFLAGS = -avoid-version -module
include $(top_srcdir)/build/lex-rules.am --- SNAP ---
Would that be ok with you?
I created a matching bugzilla entry, https://bugzilla.balabit.com/show_bug.cgi?id=104, and changed the patch attached to https://bugzilla.balabit.com/show_bug.cgi?id=103 accordingly. Thanks in advance, Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat
On Fri, 2010-12-10 at 17:57 +0100, Corinna Vinschen wrote:
On Dec 10 10:30, Corinna Vinschen wrote:
On Dec 9 21:13, Balazs Scheidler wrote:
So for now, I can only promise to migrate to autoconf 2.67, but I'm reluctant to upgrade to libtool 2.4, so the autoreconf stuff will be needed for a little while.
Ok, thank you. I can live with that.
Especially since even with libtool 2.4 there's still a problem. Due to the way shared libs are handled on Windows, ther's a hardcoded mechanism in libtool which doesn't work overly well with syslog-ng. When installing the shared libs into $(localstatedir), libtool copies the .a (static lib) and .dll.a (link stub for DLL) files into that directory, while the actual module DLLs are copied to $(localstatedir)/../bin. My
Sorry, I messed up here. Make these directories $(libexecdir)/syslog-ng and $(libexecdir)/syslog-ng/../bin .
contrib/cygwin-packaging/cygwin-postinstall script fixes this situation. It removes the .a and .dll.a files and moves the DLLs over to /usr/lib/syslog-ng. That works, but I'd be glad to find a solution which does the right thing already at `make install' time, not only after applying some postinstall magic. I'll investigate this further.
I just got the hint that the libtool --mode=link option "-module" is supposed to do exactly this on Cygwin. I tested it and with this option the subsequent `make install' actually copies the DLLs into the $(libexecdir)/syslog-ng directory where they belong.
I checked that the -module option is already known to libtool 2.2.6, so it seems it would make sense to add this option generically to the Makefile.am files in the modules subdirectories, along these lines.
--- SNIP --- diff --git a/modules/affile/Makefile.am b/modules/affile/Makefile.am index 9917ebf..04dbaae 100644 --- a/modules/affile/Makefile.am +++ b/modules/affile/Makefile.am @@ -12,6 +12,6 @@ EXTRA_DIST = $(BUILT_SOURCES) affile-grammar.ym
libaffile_la_CPPFLAGS = $(AM_CPPFLAGS) libaffile_la_LIBADD = ../../lib/libsyslog-ng.la -libaffile_la_LDFLAGS = -avoid-version +libaffile_la_LDFLAGS = -avoid-version -module
include $(top_srcdir)/build/lex-rules.am --- SNAP ---
Would that be ok with you?
It used to be "-avoid-version -module" but it was removed by this commit: Author: Balazs Scheidler <bazsi@balabit.hu> 2010-09-27 15:51:22 Committer: Balazs Scheidler <bazsi@balabit.hu> 2010-09-27 15:51:22 Parent: f437439a9c28555271b1298eeaf6e962ec626cc1 (use -avoid-version for modules) Follows: v3.2alpha1 Precedes: v3.2beta1 modules: don't use -module libtool option As it causes a libtool warning when linking the module explicitly to a program and it worked without that on all of our platforms anyway. The problem is that I'm linking pdbtool against the libdbparser.so file and the unit tests and using -module causes a lot of warnings during compilation. Do you perhaps have an idea how otherwise work around the warning?
Anyway, for the time being, the new cygwin-postinstall script (https://bugzilla.balabit.com/show_bug.cgi?id=103) will do the job.
If the aforementioned -module option is a viable approach, I would have to change the contrib/cygwin-packaging/cygwin-postinstall script again, so in this case I would upload a new patch to bugzilla issue 103.
-- Bazsi
On Dec 13 20:13, Balazs Scheidler wrote:
On Fri, 2010-12-10 at 17:57 +0100, Corinna Vinschen wrote:
On Dec 10 10:30, Corinna Vinschen wrote: I just got the hint that the libtool --mode=link option "-module" is supposed to do exactly this on Cygwin. I tested it and with this option the subsequent `make install' actually copies the DLLs into the $(libexecdir)/syslog-ng directory where they belong.
I checked that the -module option is already known to libtool 2.2.6, so it seems it would make sense to add this option generically to the Makefile.am files in the modules subdirectories, along these lines.
--- SNIP --- diff --git a/modules/affile/Makefile.am b/modules/affile/Makefile.am index 9917ebf..04dbaae 100644 --- a/modules/affile/Makefile.am +++ b/modules/affile/Makefile.am @@ -12,6 +12,6 @@ EXTRA_DIST = $(BUILT_SOURCES) affile-grammar.ym
libaffile_la_CPPFLAGS = $(AM_CPPFLAGS) libaffile_la_LIBADD = ../../lib/libsyslog-ng.la -libaffile_la_LDFLAGS = -avoid-version +libaffile_la_LDFLAGS = -avoid-version -module
include $(top_srcdir)/build/lex-rules.am --- SNAP ---
Would that be ok with you?
It used to be "-avoid-version -module" but it was removed by this commit:
Author: Balazs Scheidler <bazsi@balabit.hu> 2010-09-27 15:51:22 Committer: Balazs Scheidler <bazsi@balabit.hu> 2010-09-27 15:51:22 Parent: f437439a9c28555271b1298eeaf6e962ec626cc1 (use -avoid-version for modules) Follows: v3.2alpha1 Precedes: v3.2beta1
modules: don't use -module libtool option
As it causes a libtool warning when linking the module explicitly to a program and it worked without that on all of our platforms anyway.
The problem is that I'm linking pdbtool against the libdbparser.so file and the unit tests and using -module causes a lot of warnings during compilation.
Do you perhaps have an idea how otherwise work around the warning?
Does the -export-dynamic option when linking pdbtool help, perhaps? Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat
On Dec 13 20:39, Corinna Vinschen wrote:
On Dec 13 20:13, Balazs Scheidler wrote:
On Fri, 2010-12-10 at 17:57 +0100, Corinna Vinschen wrote:
On Dec 10 10:30, Corinna Vinschen wrote: I just got the hint that the libtool --mode=link option "-module" is supposed to do exactly this on Cygwin. [...] Would that be ok with you?
It used to be "-avoid-version -module" but it was removed by this commit:
Author: Balazs Scheidler <bazsi@balabit.hu> 2010-09-27 15:51:22 Committer: Balazs Scheidler <bazsi@balabit.hu> 2010-09-27 15:51:22 Parent: f437439a9c28555271b1298eeaf6e962ec626cc1 (use -avoid-version for modules) Follows: v3.2alpha1 Precedes: v3.2beta1
modules: don't use -module libtool option
As it causes a libtool warning when linking the module explicitly to a program and it worked without that on all of our platforms anyway.
The problem is that I'm linking pdbtool against the libdbparser.so file and the unit tests and using -module causes a lot of warnings during compilation.
Do you perhaps have an idea how otherwise work around the warning?
Does the -export-dynamic option when linking pdbtool help, perhaps?
Here's how you avoid the warning: diff --git a/configure.in b/configure.in index ea671be..0e534f8 100644 --- a/configure.in +++ b/configure.in @@ -156,7 +156,7 @@ AC_PROG_YACC AM_PROG_LEX AC_PROG_MAKE_SET PKG_PROG_PKG_CONFIG -LT_INIT([disable-static]) +LT_INIT([dlopen disable-static]) dnl *************************************************************************** dnl Validate yacc diff --git a/modules/dbparser/Makefile.am b/modules/dbparser/Makefile.am index 2a08c29..76a6cef 100644 --- a/modules/dbparser/Makefile.am +++ b/modules/dbparser/Makefile.am @@ -26,7 +26,7 @@ libdbparser_la_LDFLAGS = -avoid-version -module bin_PROGRAMS = pdbtool pdbtool_SOURCES = pdbtool.c patternize.c patternize.h pdbtool_CPPFLAGS = $(AM_CPPFLAGS) @OPENSSL_CFLAGS@ -pdbtool_LDADD = ../../lib/libsyslog-ng.la libdbparser.la @OPENSSL_LIBS@ @DEPS_LIBS@ +pdbtool_LDADD = ../../lib/libsyslog-ng.la -dlpreopen libdbparser.la @OPENSSL_LIBS@ @DEPS_LIBS@ BUILT_SOURCES = dbparser-grammar.y dbparser-grammar.c dbparser-grammar.h EXTRA_DIST = $(BUILT_SOURCES) radix-find.c dbparser-grammar.ym Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat
On Dec 17 14:07, Corinna Vinschen wrote:
On Dec 13 20:39, Corinna Vinschen wrote:
On Dec 13 20:13, Balazs Scheidler wrote:
On Fri, 2010-12-10 at 17:57 +0100, Corinna Vinschen wrote:
On Dec 10 10:30, Corinna Vinschen wrote: I just got the hint that the libtool --mode=link option "-module" is supposed to do exactly this on Cygwin. [...] Would that be ok with you?
It used to be "-avoid-version -module" but it was removed by this commit:
Author: Balazs Scheidler <bazsi@balabit.hu> 2010-09-27 15:51:22 Committer: Balazs Scheidler <bazsi@balabit.hu> 2010-09-27 15:51:22 Parent: f437439a9c28555271b1298eeaf6e962ec626cc1 (use -avoid-version for modules) Follows: v3.2alpha1 Precedes: v3.2beta1
modules: don't use -module libtool option
As it causes a libtool warning when linking the module explicitly to a program and it worked without that on all of our platforms anyway.
The problem is that I'm linking pdbtool against the libdbparser.so file and the unit tests and using -module causes a lot of warnings during compilation.
Do you perhaps have an idea how otherwise work around the warning?
Does the -export-dynamic option when linking pdbtool help, perhaps?
Here's how you avoid the warning:
diff --git a/configure.in b/configure.in index ea671be..0e534f8 100644 --- a/configure.in +++ b/configure.in @@ -156,7 +156,7 @@ AC_PROG_YACC AM_PROG_LEX AC_PROG_MAKE_SET PKG_PROG_PKG_CONFIG -LT_INIT([disable-static]) +LT_INIT([dlopen disable-static])
dnl *************************************************************************** dnl Validate yacc diff --git a/modules/dbparser/Makefile.am b/modules/dbparser/Makefile.am index 2a08c29..76a6cef 100644 --- a/modules/dbparser/Makefile.am +++ b/modules/dbparser/Makefile.am @@ -26,7 +26,7 @@ libdbparser_la_LDFLAGS = -avoid-version -module bin_PROGRAMS = pdbtool pdbtool_SOURCES = pdbtool.c patternize.c patternize.h pdbtool_CPPFLAGS = $(AM_CPPFLAGS) @OPENSSL_CFLAGS@ -pdbtool_LDADD = ../../lib/libsyslog-ng.la libdbparser.la @OPENSSL_LIBS@ @DEPS_LIBS@ +pdbtool_LDADD = ../../lib/libsyslog-ng.la -dlpreopen libdbparser.la @OPENSSL_LIBS@ @DEPS_LIBS@
BUILT_SOURCES = dbparser-grammar.y dbparser-grammar.c dbparser-grammar.h EXTRA_DIST = $(BUILT_SOURCES) radix-find.c dbparser-grammar.ym
I'm going to prepare another patch for bugzilla #104, which contains the whole thing: - Add "dlopen" to LT_INIT. - Add -module to the module LDFLAGS. - Add -dlpreopen to the pdbtool link line. Plus: - Add -no-undefined to the shared libs LDFLAGS so that you can build on Cygwin with just "make" as well. Right now you have to call "make CCLD='$(CC) -no-undefined'", which is rather annoying. I tested this change on Cygwin and on Fedora 14, so I'm pretty confident that it works. This also requires a change to the patch in bugzilla #103. So far it still mentiones the CCLD='$(CC) -no-undefined' stuff, which will be obsolete with the aforementioned changes to #104. Even with these changes there will still be a problem with pdbtool on Cygwin. Since we have no static libs, and since it's not possible to link statically against a DLL, pdbtool requires cygdbparser.dll (equiv. libdbparser.so on Linux) to be in $PATH. Given that the modules are in /usr/lib/syslog-ng, that's not feasible. Two possible solutions come to mind: - Either enable static libs for the dbparser libs and link pdbtool statically. - Or, install pdbtool into /usr/lib/syslog-ng along the modules, and make /usr/bin/pdbtool a symlink to /usr/lib/syslog-ng/pdbtool. Thoughts? Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat
Even with these changes there will still be a problem with pdbtool on Cygwin. Since we have no static libs, and since it's not possible to link statically against a DLL, pdbtool requires cygdbparser.dll (equiv. libdbparser.so on Linux) to be in $PATH. Given that the modules are in /usr/lib/syslog-ng, that's not feasible.
Two possible solutions come to mind:
- Either enable static libs for the dbparser libs and link pdbtool statically.
- Or, install pdbtool into /usr/lib/syslog-ng along the modules, and make /usr/bin/pdbtool a symlink to /usr/lib/syslog-ng/pdbtool.
Thoughts?
Honestly not much. I wouldn't like to install pdbtool in /usr/lib/syslog-ng I guess this works on Linux because an rpath is added to the pdbtool executable. hmmm... the only idea I have is to create a libsyslog-ng-patterndb.so library, installed in /usr/lib and then libdbparser.so module would be linked against that code. pdbtool would only depend on libsyslog-ng-patterndb and no on the syslog-ng plugin. what do you think? -- Bazsi
On Jan 14 18:18, Balazs Scheidler wrote:
Even with these changes there will still be a problem with pdbtool on Cygwin. Since we have no static libs, and since it's not possible to link statically against a DLL, pdbtool requires cygdbparser.dll (equiv. libdbparser.so on Linux) to be in $PATH. Given that the modules are in /usr/lib/syslog-ng, that's not feasible.
Two possible solutions come to mind:
- Either enable static libs for the dbparser libs and link pdbtool statically.
- Or, install pdbtool into /usr/lib/syslog-ng along the modules, and make /usr/bin/pdbtool a symlink to /usr/lib/syslog-ng/pdbtool.
Thoughts?
Honestly not much. I wouldn't like to install pdbtool in /usr/lib/syslog-ng
I guess this works on Linux because an rpath is added to the pdbtool executable. hmmm...
Unfortunately that's not possible with the Windows loader.
the only idea I have is to create a libsyslog-ng-patterndb.so library, installed in /usr/lib and then libdbparser.so module would be linked against that code.
pdbtool would only depend on libsyslog-ng-patterndb and no on the syslog-ng plugin.
what do you think?
That sounds ok to me. Nevertheless, I'd like to ask what's wrong with installing pdbtool in /usr/lib/syslog-ng and creating a symlink in /usr/bin. I don't see a good reason. It's a very simple change and works on all unixoid platforms. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat
On Jan 14 18:38, Corinna Vinschen wrote:
On Jan 14 18:18, Balazs Scheidler wrote:
Even with these changes there will still be a problem with pdbtool on Cygwin. Since we have no static libs, and since it's not possible to link statically against a DLL, pdbtool requires cygdbparser.dll (equiv. libdbparser.so on Linux) to be in $PATH. Given that the modules are in /usr/lib/syslog-ng, that's not feasible. [...] the only idea I have is to create a libsyslog-ng-patterndb.so library, installed in /usr/lib and then libdbparser.so module would be linked against that code.
pdbtool would only depend on libsyslog-ng-patterndb and no on the syslog-ng plugin.
I just tested the new implementation from git, and gcc fails to build libsyslog-ng-patterndb.dll.a since a lot of function calls are missing: libtool: link: gcc -std=gnu99 -shared .libs/radix.o .libs/patterndb.o .libs/timerwheel.o .libs/patternize.o -lssl -lcrypto -lz -lrt /usr/lib/libgmodule-2.0.dll.a -L/usr/lib /usr/lib/libglib-2.0.dll.a /usr/lib/libintl.dll.a /usr/lib/libiconv.dll.a /usr/lib/libevtlog.dll.a -lresolv /usr/lib/libpcre.dll.a -O2 -Wl,--export-all-symbols -o .libs/cygsyslog-ng-patterndb-0.dll -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker .libs/libsyslog-ng-patterndb.dll.a Creating library file: .libs/libsyslog-ng-patterndb.dll.a .libs/radix.o: In function `r_new_pnode': modules/dbparser/radix.c:374: undefined reference to `_log_msg_get_value_handle' modules/dbparser/radix.c:618: undefined reference to `_msg_limit_internal_message' modules/dbparser/radix.c:618: undefined reference to `_log_msg_get_value_name' modules/dbparser/radix.c:618: undefined reference to `_msg_event_create' modules/dbparser/radix.c:629: undefined reference to `_msg_limit_internal_message' modules/dbparser/radix.c:567: undefined reference to `_msg_event_create' modules/dbparser/radix.c:674: undefined reference to `_msg_limit_internal_message' modules/dbparser/radix.c:674: undefined reference to `_msg_event_create' etc. The reason is that the dependency to libsyslog is missing. Would you mind to apply this simple patch? It fixes the build problem and the resulting pdbtool appears to work fine. signed-off by Corinna Vinschen <vinschen@redhat.com> diff --git a/modules/dbparser/Makefile.am b/modules/dbparser/Makefile.am index c906bcd..ee019bc 100644 --- a/modules/dbparser/Makefile.am +++ b/modules/dbparser/Makefile.am @@ -17,7 +17,7 @@ libsyslog_ng_patterndb_la_SOURCES = radix.c radix.h \ timerwheel.c timerwheel.h \ patternize.c patternize.h libsyslog_ng_patterndb_la_LDFLAGS = -no-undefined -libsyslog_ng_patterndb_la_LIBADD = @OPENSSL_LIBS@ @DEPS_LIBS@ +libsyslog_ng_patterndb_la_LIBADD = @OPENSSL_LIBS@ @DEPS_LIBS@ ../../lib/libsyslog-ng.la module_LTLIBRARIES = libdbparser.la libdbparser_la_SOURCES = \ Thanks, Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat
Hi, I got some negative feedback on the introduction of this shared object by the SUSE guys too. So I might go with the suggestion you made about symlinking pdbtool instead of this new shared library route. Guys, what do you think? On Thu, 2011-01-20 at 18:38 +0100, Corinna Vinschen wrote:
On Jan 14 18:38, Corinna Vinschen wrote:
On Jan 14 18:18, Balazs Scheidler wrote:
Even with these changes there will still be a problem with pdbtool on Cygwin. Since we have no static libs, and since it's not possible to link statically against a DLL, pdbtool requires cygdbparser.dll (equiv. libdbparser.so on Linux) to be in $PATH. Given that the modules are in /usr/lib/syslog-ng, that's not feasible. [...] the only idea I have is to create a libsyslog-ng-patterndb.so library, installed in /usr/lib and then libdbparser.so module would be linked against that code.
pdbtool would only depend on libsyslog-ng-patterndb and no on the syslog-ng plugin.
I just tested the new implementation from git, and gcc fails to build libsyslog-ng-patterndb.dll.a since a lot of function calls are missing:
libtool: link: gcc -std=gnu99 -shared .libs/radix.o .libs/patterndb.o .libs/timerwheel.o .libs/patternize.o -lssl -lcrypto -lz -lrt /usr/lib/libgmodule-2.0.dll.a -L/usr/lib /usr/lib/libglib-2.0.dll.a /usr/lib/libintl.dll.a /usr/lib/libiconv.dll.a /usr/lib/libevtlog.dll.a -lresolv /usr/lib/libpcre.dll.a -O2 -Wl,--export-all-symbols -o .libs/cygsyslog-ng-patterndb-0.dll -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker .libs/libsyslog-ng-patterndb.dll.a Creating library file: .libs/libsyslog-ng-patterndb.dll.a .libs/radix.o: In function `r_new_pnode': modules/dbparser/radix.c:374: undefined reference to `_log_msg_get_value_handle' modules/dbparser/radix.c:618: undefined reference to `_msg_limit_internal_message' modules/dbparser/radix.c:618: undefined reference to `_log_msg_get_value_name' modules/dbparser/radix.c:618: undefined reference to `_msg_event_create' modules/dbparser/radix.c:629: undefined reference to `_msg_limit_internal_message' modules/dbparser/radix.c:567: undefined reference to `_msg_event_create' modules/dbparser/radix.c:674: undefined reference to `_msg_limit_internal_message' modules/dbparser/radix.c:674: undefined reference to `_msg_event_create'
etc.
The reason is that the dependency to libsyslog is missing. Would you mind to apply this simple patch? It fixes the build problem and the resulting pdbtool appears to work fine.
signed-off by Corinna Vinschen <vinschen@redhat.com>
diff --git a/modules/dbparser/Makefile.am b/modules/dbparser/Makefile.am index c906bcd..ee019bc 100644 --- a/modules/dbparser/Makefile.am +++ b/modules/dbparser/Makefile.am @@ -17,7 +17,7 @@ libsyslog_ng_patterndb_la_SOURCES = radix.c radix.h \ timerwheel.c timerwheel.h \ patternize.c patternize.h libsyslog_ng_patterndb_la_LDFLAGS = -no-undefined -libsyslog_ng_patterndb_la_LIBADD = @OPENSSL_LIBS@ @DEPS_LIBS@ +libsyslog_ng_patterndb_la_LIBADD = @OPENSSL_LIBS@ @DEPS_LIBS@ ../../lib/libsyslog-ng.la
module_LTLIBRARIES = libdbparser.la libdbparser_la_SOURCES = \
Thanks, Corinna
-- Bazsi
On Feb 3 08:38, Balazs Scheidler wrote:
Hi,
I got some negative feedback on the introduction of this shared object by the SUSE guys too. So I might go with the suggestion you made about symlinking pdbtool instead of this new shared library route.
Guys, what do you think?
I'm all for the symlink since it's much simpler than creating an extra shared lib, and it works on all platforms.
signed-off by Corinna Vinschen <vinschen@redhat.com>
diff --git a/modules/dbparser/Makefile.am b/modules/dbparser/Makefile.am index c906bcd..ee019bc 100644 --- a/modules/dbparser/Makefile.am +++ b/modules/dbparser/Makefile.am @@ -17,7 +17,7 @@ libsyslog_ng_patterndb_la_SOURCES = radix.c radix.h \ timerwheel.c timerwheel.h \ patternize.c patternize.h libsyslog_ng_patterndb_la_LDFLAGS = -no-undefined -libsyslog_ng_patterndb_la_LIBADD = @OPENSSL_LIBS@ @DEPS_LIBS@ +libsyslog_ng_patterndb_la_LIBADD = @OPENSSL_LIBS@ @DEPS_LIBS@ ../../lib/libsyslog-ng.la
module_LTLIBRARIES = libdbparser.la libdbparser_la_SOURCES = \
OTOH, using your proposal, the fix is rather simple, so I'll not complain if you stick to the shared lib. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat
Ping? Anything new? As it is, syslog-ng does not build on Cygwin. A solution of this tiny problem would be nice. On Feb 3 11:49, Corinna Vinschen wrote:
On Feb 3 08:38, Balazs Scheidler wrote:
Hi,
I got some negative feedback on the introduction of this shared object by the SUSE guys too. So I might go with the suggestion you made about symlinking pdbtool instead of this new shared library route.
Guys, what do you think?
I'm all for the symlink since it's much simpler than creating an extra shared lib, and it works on all platforms.
signed-off by Corinna Vinschen <vinschen@redhat.com>
diff --git a/modules/dbparser/Makefile.am b/modules/dbparser/Makefile.am index c906bcd..ee019bc 100644 --- a/modules/dbparser/Makefile.am +++ b/modules/dbparser/Makefile.am @@ -17,7 +17,7 @@ libsyslog_ng_patterndb_la_SOURCES = radix.c radix.h \ timerwheel.c timerwheel.h \ patternize.c patternize.h libsyslog_ng_patterndb_la_LDFLAGS = -no-undefined -libsyslog_ng_patterndb_la_LIBADD = @OPENSSL_LIBS@ @DEPS_LIBS@ +libsyslog_ng_patterndb_la_LIBADD = @OPENSSL_LIBS@ @DEPS_LIBS@ ../../lib/libsyslog-ng.la
module_LTLIBRARIES = libdbparser.la libdbparser_la_SOURCES = \
OTOH, using your proposal, the fix is rather simple, so I'll not complain if you stick to the shared lib.
Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat
Ping 2? Did I say anything wrong? On Feb 11 20:13, Corinna Vinschen wrote:
Ping?
Anything new? As it is, syslog-ng does not build on Cygwin. A solution of this tiny problem would be nice.
On Feb 3 11:49, Corinna Vinschen wrote:
On Feb 3 08:38, Balazs Scheidler wrote:
Hi,
I got some negative feedback on the introduction of this shared object by the SUSE guys too. So I might go with the suggestion you made about symlinking pdbtool instead of this new shared library route.
Guys, what do you think?
I'm all for the symlink since it's much simpler than creating an extra shared lib, and it works on all platforms.
signed-off by Corinna Vinschen <vinschen@redhat.com>
diff --git a/modules/dbparser/Makefile.am b/modules/dbparser/Makefile.am index c906bcd..ee019bc 100644 --- a/modules/dbparser/Makefile.am +++ b/modules/dbparser/Makefile.am @@ -17,7 +17,7 @@ libsyslog_ng_patterndb_la_SOURCES = radix.c radix.h \ timerwheel.c timerwheel.h \ patternize.c patternize.h libsyslog_ng_patterndb_la_LDFLAGS = -no-undefined -libsyslog_ng_patterndb_la_LIBADD = @OPENSSL_LIBS@ @DEPS_LIBS@ +libsyslog_ng_patterndb_la_LIBADD = @OPENSSL_LIBS@ @DEPS_LIBS@ ../../lib/libsyslog-ng.la
module_LTLIBRARIES = libdbparser.la libdbparser_la_SOURCES = \
OTOH, using your proposal, the fix is rather simple, so I'll not complain if you stick to the shared lib.
Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat
On Mon, 2011-02-21 at 10:55 +0100, Corinna Vinschen wrote:
Ping 2? Did I say anything wrong?
No, not at all. Just the usual stuff. Work, family. I've an idea, let me test if that works. -- Bazsi
What about this patch, e.g. create a static library, which makes pdbtool happy and doesn't introduce another shared object. Peter, Marius what do you think? commit a3c2ab7e095f7638b3fa0ecf452c8a68025c6a07 Author: Balazs Scheidler <bazsi@balabit.hu> Date: Tue Feb 22 15:10:43 2011 +0100 dbparser: don't create a separate shared library for libsyslog-ng-patterndb Use a static library instead, linked into both the db-parser() plugin and the pdbtool binary. This solves the linking issues on Cygwin and doesn't publish an internal shared library from syslog-ng. Reported-By: Corinna Vinschen <vinschen@redhat.com> Signed-off-by: Balazs Scheidler <bazsi@balabit.hu> diff --git a/modules/dbparser/Makefile.am b/modules/dbparser/Makefile.am index c906bcd..84b7f10 100644 --- a/modules/dbparser/Makefile.am +++ b/modules/dbparser/Makefile.am @@ -11,13 +11,12 @@ AM_CPPFLAGS = -I$(top_srcdir)/lib -I../../lib AM_CFLAGS = @CFLAGS_NOWARN_POINTER_SIGN@ export top_srcdir -lib_LTLIBRARIES = libsyslog-ng-patterndb.la -libsyslog_ng_patterndb_la_SOURCES = radix.c radix.h \ +lib_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_la_LDFLAGS = -no-undefined -libsyslog_ng_patterndb_la_LIBADD = @OPENSSL_LIBS@ @DEPS_LIBS@ +libsyslog_ng_patterndb_a_CFLAGS = $(AM_CFLAGS) -fPIC module_LTLIBRARIES = libdbparser.la libdbparser_la_SOURCES = \ @@ -25,13 +24,13 @@ libdbparser_la_SOURCES = \ dbparser-grammar.y dbparser-parser.c dbparser-parser.h dbparser-plugin.c libdbparser_la_CPPFLAGS = $(AM_CPPFLAGS) -libdbparser_la_LIBADD = ../../lib/libsyslog-ng.la libsyslog-ng-patterndb.la +libdbparser_la_LIBADD = ../../lib/libsyslog-ng.la libsyslog-ng-patterndb.a 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.la +pdbtool_LDADD = ../../lib/libsyslog-ng.la libsyslog-ng-patterndb.a @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/pdbtool.c b/modules/dbparser/pdbtool.c index e2368e5..bb6468f 100644 --- a/modules/dbparser/pdbtool.c +++ b/modules/dbparser/pdbtool.c @@ -981,7 +981,6 @@ main(int argc, char *argv[]) msg_init(TRUE); plugin_load_module("syslogformat", configuration, NULL); plugin_load_module("basicfuncs", configuration, NULL); - plugin_load_module("dbparser", configuration, NULL); if (color_out) colors = full_colors; On Tue, 2011-02-22 at 15:02 +0100, Balazs Scheidler wrote:
On Mon, 2011-02-21 at 10:55 +0100, Corinna Vinschen wrote:
Ping 2? Did I say anything wrong?
No, not at all. Just the usual stuff. Work, family. I've an idea, let me test if that works.
-- Bazsi
Hi Balazs, On Feb 22 15:11, Balazs Scheidler wrote:
What about this patch, e.g. create a static library, which makes pdbtool happy and doesn't introduce another shared object.
Unfortunately it doesn't work on Cygwin. I get the following error when trying to link libdbparser: /bin/sh ../../libtool --tag=CC --mode=link gcc -std=gnu99 -Wno-pointer-sign -g -O2 -Wall -avoid-version -module -no-undefined -o libdbparser.la -rpath /usr/lib/syslog-ng libdbparser_la-dbparser.lo libdbparser_la-dbparser-grammar.lo libdbparser_la-dbparser-parser.lo libdbparser_la-dbparser-plugin.lo ../../lib/libsyslog-ng.la libsyslog-ng-patterndb.a *** Warning: Trying to link with static lib archive libsyslog-ng-patterndb.a. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because the file extensions .a of this argument makes me believe *** that it is just a static archive that I should not use here. To get this working on Cygwin as well, you must create both, a static and a shared libsyslog-ng-patterndb. The static one is for linking against pdbtool, the shared one for linking libdbparser.la. Also, when building pdbtool you have to specify libsyslog-ng-patterndb.a prior to ../../lib/libsyslog-ng.la in the LDADD library list, since when linking PE/COFF binaries, the order of libs given on the gcc command line is followed strictly. There's no backward reference possible. Thus the original order fails to link since functions in libsyslog-ng-patterndb.a reference symbols in ../../lib/libsyslog-ng.la. Below's a matching patch against git HEAD. Thanks, Corinna Signed-off-by: Corinna Vinschen <vinschen@redhat.com> diff --git a/modules/dbparser/Makefile.am b/modules/dbparser/Makefile.am index e35edaf..0b4dda7 100644 --- a/modules/dbparser/Makefile.am +++ b/modules/dbparser/Makefile.am @@ -11,6 +11,14 @@ AM_CPPFLAGS = -I$(top_srcdir)/lib -I../../lib AM_CFLAGS = @CFLAGS_NOWARN_POINTER_SIGN@ export top_srcdir +noinst_LTLIBRARIES = libsyslog-ng-patterndb.la +libsyslog_ng_patterndb_la_SOURCES = radix.c radix.h \ + patterndb.c patterndb.h patterndb-int.h \ + timerwheel.c timerwheel.h \ + patternize.c patternize.h +libsyslog_ng_patterndb_la_LDFLAGS = -no-undefined +libsyslog_ng_patterndb_la_LIBADD = @OPENSSL_LIBS@ @DEPS_LIBS@ ../../lib/libsyslog-ng.la + lib_LIBRARIES = libsyslog-ng-patterndb.a libsyslog_ng_patterndb_a_SOURCES = radix.c radix.h \ patterndb.c patterndb.h patterndb-int.h \ @@ -24,13 +32,13 @@ libdbparser_la_SOURCES = \ dbparser-grammar.y dbparser-parser.c dbparser-parser.h dbparser-plugin.c libdbparser_la_CPPFLAGS = $(AM_CPPFLAGS) -libdbparser_la_LIBADD = ../../lib/libsyslog-ng.la libsyslog-ng-patterndb.a +libdbparser_la_LIBADD = ../../lib/libsyslog-ng.la libsyslog-ng-patterndb.la 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 @OPENSSL_LIBS@ @GLIB_LIBS@ +pdbtool_LDADD = libsyslog-ng-patterndb.a ../../lib/libsyslog-ng.la @OPENSSL_LIBS@ @GLIB_LIBS@ BUILT_SOURCES = dbparser-grammar.y dbparser-grammar.c dbparser-grammar.h EXTRA_DIST = $(BUILT_SOURCES) radix-find.c dbparser-grammar.ym -- Corinna Vinschen Cygwin Project Co-Leader Red Hat
On Feb 22 18:39, Corinna Vinschen wrote:
Hi Balazs,
On Feb 22 15:11, Balazs Scheidler wrote:
What about this patch, e.g. create a static library, which makes pdbtool happy and doesn't introduce another shared object.
Unfortunately it doesn't work on Cygwin. I get the following error when trying to link libdbparser:
/bin/sh ../../libtool --tag=CC --mode=link gcc -std=gnu99 -Wno-pointer-sign -g -O2 -Wall -avoid-version -module -no-undefined -o libdbparser.la -rpath /usr/lib/syslog-ng libdbparser_la-dbparser.lo libdbparser_la-dbparser-grammar.lo libdbparser_la-dbparser-parser.lo libdbparser_la-dbparser-plugin.lo ../../lib/libsyslog-ng.la libsyslog-ng-patterndb.a
*** Warning: Trying to link with static lib archive libsyslog-ng-patterndb.a. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because the file extensions .a of this argument makes me believe *** that it is just a static archive that I should not use here.
To get this working on Cygwin as well, you must create both, a static and a shared libsyslog-ng-patterndb. The static one is for linking against pdbtool, the shared one for linking libdbparser.la.
Also, when building pdbtool you have to specify libsyslog-ng-patterndb.a prior to ../../lib/libsyslog-ng.la in the LDADD library list, since when linking PE/COFF binaries, the order of libs given on the gcc command line is followed strictly. There's no backward reference possible. Thus the original order fails to link since functions in libsyslog-ng-patterndb.a reference symbols in ../../lib/libsyslog-ng.la.
Below's another matching patch against git HEAD. With your changes the libsyslog-ng-patterndb.a file gets installed to /usr/lib, but the static lib is a convenience lib as well. So it should be a "noinst" library as well: Signed-off-by: Corinna Vinschen <vinschen@redhat.com> diff --git a/modules/dbparser/Makefile.am b/modules/dbparser/Makefile.am index e35edaf..2edbc56 100644 --- a/modules/dbparser/Makefile.am +++ b/modules/dbparser/Makefile.am @@ -11,7 +11,15 @@ AM_CPPFLAGS = -I$(top_srcdir)/lib -I../../lib AM_CFLAGS = @CFLAGS_NOWARN_POINTER_SIGN@ export top_srcdir -lib_LIBRARIES = libsyslog-ng-patterndb.a +noinst_LTLIBRARIES = libsyslog-ng-patterndb.la +libsyslog_ng_patterndb_la_SOURCES = radix.c radix.h \ + patterndb.c patterndb.h patterndb-int.h \ + timerwheel.c timerwheel.h \ + patternize.c patternize.h +libsyslog_ng_patterndb_la_LDFLAGS = -no-undefined +libsyslog_ng_patterndb_la_LIBADD = @OPENSSL_LIBS@ @DEPS_LIBS@ ../../lib/libsyslog-ng.la + +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 \ @@ -24,13 +32,13 @@ libdbparser_la_SOURCES = \ dbparser-grammar.y dbparser-parser.c dbparser-parser.h dbparser-plugin.c libdbparser_la_CPPFLAGS = $(AM_CPPFLAGS) -libdbparser_la_LIBADD = ../../lib/libsyslog-ng.la libsyslog-ng-patterndb.a +libdbparser_la_LIBADD = ../../lib/libsyslog-ng.la libsyslog-ng-patterndb.la 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 @OPENSSL_LIBS@ @GLIB_LIBS@ +pdbtool_LDADD = libsyslog-ng-patterndb.a ../../lib/libsyslog-ng.la @OPENSSL_LIBS@ @GLIB_LIBS@ BUILT_SOURCES = dbparser-grammar.y dbparser-grammar.c dbparser-grammar.h EXTRA_DIST = $(BUILT_SOURCES) radix-find.c dbparser-grammar.ym Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat
Corinna, why do you need an extra noinst_LIBRARIES = libsyslog-ng-patterndb.a when there is already a noinst_LTLIBRARIES = libsyslog-ng-patterndb.la Does libtool not automatically links statically against noinst_LTLIBRARIES? When I (completely remove noinst_LIBRARIES) and use: -pdbtool_LDADD = libsyslog-ng-patterndb.a ../../lib/libsyslog-ng.la @OPENSSL_LIBS@ @GLIB_LIBS@ +pdbtool_LDADD = libsyslog-ng-patterndb.la ../../lib/libsyslog-ng.la @OPENSSL_LIBS@ @GLIB_LIBS@ it is automatically linked statically against libsyslog-ng-patterndb and dynmically against everything else (libsyslog-ng and another libs). My current problem is to link libdbparser correctly - it gets relinked dynamically against libglib in mixed mode, even it shouldn't (we don't have libglib in /%_lib). [Maybe this is the -pthread flag that seems to be returned inside of the glib libs...]. Don't know... I've to take a closer look at all this when I've a little bit more time... Gruesse / Regards, Marius Tomaschewski <mt@suse.de> <mt@novell.com> -- Server Technologies Team, SUSE LINUX Products GmbH, Nuernberg; GF: Markus Rex; HRB 16746 (AG Nuernberg) GPG/PGP public key fingerprint: DF17 271A AD15 006A 5BB9 6C96 CA2F F3F7 373A 1CC0
Am Mittwoch, 23. Februar 2011, 15:01:18 schrieb Marius Tomaschewski:
Corinna,
why do you need an extra noinst_LIBRARIES = libsyslog-ng-patterndb.a when there is already a noinst_LTLIBRARIES = libsyslog-ng-patterndb.la
forget it. You've explained it in the another mail... Gruesse / Regards, Marius Tomaschewski <mt@suse.de> <mt@novell.com> -- Server Technologies Team, SUSE LINUX Products GmbH, Nuernberg; GF: Markus Rex; HRB 16746 (AG Nuernberg) GPG/PGP public key fingerprint: DF17 271A AD15 006A 5BB9 6C96 CA2F F3F7 373A 1CC0
On Feb 23 15:18, Marius Tomaschewski wrote:
Am Mittwoch, 23. Februar 2011, 15:01:18 schrieb Marius Tomaschewski:
Corinna,
why do you need an extra noinst_LIBRARIES = libsyslog-ng-patterndb.a when there is already a noinst_LTLIBRARIES = libsyslog-ng-patterndb.la
forget it. You've explained it in the another mail...
Uh, I'm glad. Your question really made me nervous at first :-) Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat
Hello, On 02/22/2011 03:11 PM, Balazs Scheidler wrote:
What about this patch, e.g. create a static library, which makes pdbtool happy and doesn't introduce another shared object.
Peter, Marius what do you think?
I tried to compile it at https://build.opensuse.org/package/show?package=syslog-ng&project=home%3Acza... but it failed for older releases. Those use mixed linking, the latest one dynamic linking. Could it be a problem? Bye, CzP
commit a3c2ab7e095f7638b3fa0ecf452c8a68025c6a07 Author: Balazs Scheidler <bazsi@balabit.hu> Date: Tue Feb 22 15:10:43 2011 +0100
dbparser: don't create a separate shared library for libsyslog-ng-patterndb
Use a static library instead, linked into both the db-parser() plugin and the pdbtool binary.
This solves the linking issues on Cygwin and doesn't publish an internal shared library from syslog-ng.
Reported-By: Corinna Vinschen <vinschen@redhat.com> Signed-off-by: Balazs Scheidler <bazsi@balabit.hu>
diff --git a/modules/dbparser/Makefile.am b/modules/dbparser/Makefile.am index c906bcd..84b7f10 100644 --- a/modules/dbparser/Makefile.am +++ b/modules/dbparser/Makefile.am @@ -11,13 +11,12 @@ AM_CPPFLAGS = -I$(top_srcdir)/lib -I../../lib AM_CFLAGS = @CFLAGS_NOWARN_POINTER_SIGN@ export top_srcdir
-lib_LTLIBRARIES = libsyslog-ng-patterndb.la -libsyslog_ng_patterndb_la_SOURCES = radix.c radix.h \ +lib_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_la_LDFLAGS = -no-undefined -libsyslog_ng_patterndb_la_LIBADD = @OPENSSL_LIBS@ @DEPS_LIBS@ +libsyslog_ng_patterndb_a_CFLAGS = $(AM_CFLAGS) -fPIC
module_LTLIBRARIES = libdbparser.la libdbparser_la_SOURCES = \ @@ -25,13 +24,13 @@ libdbparser_la_SOURCES = \ dbparser-grammar.y dbparser-parser.c dbparser-parser.h dbparser-plugin.c
libdbparser_la_CPPFLAGS = $(AM_CPPFLAGS) -libdbparser_la_LIBADD = ../../lib/libsyslog-ng.la libsyslog-ng-patterndb.la +libdbparser_la_LIBADD = ../../lib/libsyslog-ng.la libsyslog-ng-patterndb.a 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.la +pdbtool_LDADD = ../../lib/libsyslog-ng.la libsyslog-ng-patterndb.a @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/pdbtool.c b/modules/dbparser/pdbtool.c index e2368e5..bb6468f 100644 --- a/modules/dbparser/pdbtool.c +++ b/modules/dbparser/pdbtool.c @@ -981,7 +981,6 @@ main(int argc, char *argv[]) msg_init(TRUE); plugin_load_module("syslogformat", configuration, NULL); plugin_load_module("basicfuncs", configuration, NULL); - plugin_load_module("dbparser", configuration, NULL);
if (color_out) colors = full_colors;
On Tue, 2011-02-22 at 15:02 +0100, Balazs Scheidler wrote:
On Mon, 2011-02-21 at 10:55 +0100, Corinna Vinschen wrote:
Ping 2? Did I say anything wrong?
No, not at all. Just the usual stuff. Work, family. I've an idea, let me test if that works.
-- Peter Czanik (CzP) <czanik@balabit.hu> BalaBit IT Security / syslog-ng upstream http://czanik.blogs.balabit.com/
On Feb 23 11:05, Peter Czanik wrote:
Hello,
On 02/22/2011 03:11 PM, Balazs Scheidler wrote:
What about this patch, e.g. create a static library, which makes pdbtool happy and doesn't introduce another shared object.
Peter, Marius what do you think?
I tried to compile it at https://build.opensuse.org/package/show?package=syslog-ng&project=home%3Acza... but it failed for older releases. Those use mixed linking, the latest one dynamic linking. Could it be a problem? Bye, CzP
Maybe it's a libtool problem in old versions of libtool. Unfortunately you didn't send the relevant output of a failed build attept, so there's no way to diagnose the problem from here. However, did you try my patch from https://lists.balabit.hu/pipermail/syslog-ng/2011-February/016007.html ? It might help. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat
Hello, On 02/23/2011 12:14 PM, Corinna Vinschen wrote:
On Feb 23 11:05, Peter Czanik wrote:
Hello,
On 02/22/2011 03:11 PM, Balazs Scheidler wrote:
What about this patch, e.g. create a static library, which makes pdbtool happy and doesn't introduce another shared object.
Peter, Marius what do you think?
I tried to compile it at https://build.opensuse.org/package/show?package=syslog-ng&project=home%3Acza... but it failed for older releases. Those use mixed linking, the latest one dynamic linking. Could it be a problem? Bye, CzP
Maybe it's a libtool problem in old versions of libtool. Unfortunately you didn't send the relevant output of a failed build attept, so there's no way to diagnose the problem from here.
Because all the build logs are available from the openSUSE build service logs I quoted. Just click on the red "faild" link on right and then "download logfile".
However, did you try my patch from https://lists.balabit.hu/pipermail/syslog-ng/2011-February/016007.html ? It might help.
I'll try later today or tomorrow. Right now the OBS is dead slow (release 11.4 is nearing). Bye, -- Peter Czanik (CzP) <czanik@balabit.hu> BalaBit IT Security / syslog-ng upstream http://czanik.blogs.balabit.com/
On Feb 23 12:23, Peter Czanik wrote:
Hello,
On 02/23/2011 12:14 PM, Corinna Vinschen wrote:
On Feb 23 11:05, Peter Czanik wrote:
Hello,
On 02/22/2011 03:11 PM, Balazs Scheidler wrote:
What about this patch, e.g. create a static library, which makes pdbtool happy and doesn't introduce another shared object.
Peter, Marius what do you think?
I tried to compile it at https://build.opensuse.org/package/show?package=syslog-ng&project=home%3Acza... but it failed for older releases. Those use mixed linking, the latest one dynamic linking. Could it be a problem? Bye, CzP
Maybe it's a libtool problem in old versions of libtool. Unfortunately you didn't send the relevant output of a failed build attept, so there's no way to diagnose the problem from here.
Because all the build logs are available from the openSUSE build service logs I quoted. Just click on the red "faild" link on right and then "download logfile".
Uh, I see. Thanks. The link line is gcc -std=gnu99 -Wno-pointer-sign -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -Wall -o .libs/pdbtool pdbtool-pdbtool.o ../../lib/.libs/libsyslog-ng.so libsyslog-ng-patterndb.a -lssl -lcrypto -lz There are important libs missing here, like libevt, libgmodule, libglib. I don't know why that is, because the include paths are available when building the object files, for instance on x86_64: -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/eventlog Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat
On Wed, 2011-02-23 at 11:05 +0100, Peter Czanik wrote:
Hello,
On 02/22/2011 03:11 PM, Balazs Scheidler wrote:
What about this patch, e.g. create a static library, which makes pdbtool happy and doesn't introduce another shared object.
Peter, Marius what do you think?
I tried to compile it at https://build.opensuse.org/package/show?package=syslog-ng&project=home%3Acza... but it failed for older releases. Those use mixed linking, the latest one dynamic linking. Could it be a problem? Bye, CzP
This problem has been fixed by my latest round of linking fixes that I've pushed out today. Earlier mixed linking only worked for the main syslog-ng executable and not for the rest. Now both should work in both modes. -- Bazsi
On Fri, Dec 17, 2010 at 02:07:51PM +0100, Corinna Vinschen wrote:
Here's how you avoid the warning:
diff --git a/configure.in b/configure.in index ea671be..0e534f8 100644 --- a/configure.in +++ b/configure.in @@ -156,7 +156,7 @@ AC_PROG_YACC AM_PROG_LEX AC_PROG_MAKE_SET PKG_PROG_PKG_CONFIG -LT_INIT([disable-static]) +LT_INIT([dlopen disable-static])
dnl *************************************************************************** dnl Validate yacc diff --git a/modules/dbparser/Makefile.am b/modules/dbparser/Makefile.am index 2a08c29..76a6cef 100644 --- a/modules/dbparser/Makefile.am +++ b/modules/dbparser/Makefile.am @@ -26,7 +26,7 @@ libdbparser_la_LDFLAGS = -avoid-version -module bin_PROGRAMS = pdbtool pdbtool_SOURCES = pdbtool.c patternize.c patternize.h pdbtool_CPPFLAGS = $(AM_CPPFLAGS) @OPENSSL_CFLAGS@ -pdbtool_LDADD = ../../lib/libsyslog-ng.la libdbparser.la @OPENSSL_LIBS@ @DEPS_LIBS@ +pdbtool_LDADD = ../../lib/libsyslog-ng.la -dlpreopen libdbparser.la @OPENSSL_LIBS@ @DEPS_LIBS@
BUILT_SOURCES = dbparser-grammar.y dbparser-grammar.c dbparser-grammar.h EXTRA_DIST = $(BUILT_SOURCES) radix-find.c dbparser-grammar.ym
Hi Corinna, Funny you should mention this one. I had a similar problem here where listing the OpenSSL ahead of listing the DEPS_LIBS caused me to pick up the system OpenSSL instead of the more updated OpenSSL in the install prefix. So it seems I'm not the only one who ran into it. For what it's worth on my end I worked around it using LIBS env var which gets subbed into the linker args ahead of where LDFLAGS does so your stuff gets put earlier in the search path. Matthew.
On Dec 17 11:00, Matthew Hall wrote:
On Fri, Dec 17, 2010 at 02:07:51PM +0100, Corinna Vinschen wrote:
Here's how you avoid the warning:
diff --git a/configure.in b/configure.in index ea671be..0e534f8 100644 --- a/configure.in +++ b/configure.in @@ -156,7 +156,7 @@ AC_PROG_YACC AM_PROG_LEX AC_PROG_MAKE_SET PKG_PROG_PKG_CONFIG -LT_INIT([disable-static]) +LT_INIT([dlopen disable-static])
dnl *************************************************************************** dnl Validate yacc diff --git a/modules/dbparser/Makefile.am b/modules/dbparser/Makefile.am index 2a08c29..76a6cef 100644 --- a/modules/dbparser/Makefile.am +++ b/modules/dbparser/Makefile.am @@ -26,7 +26,7 @@ libdbparser_la_LDFLAGS = -avoid-version -module bin_PROGRAMS = pdbtool pdbtool_SOURCES = pdbtool.c patternize.c patternize.h pdbtool_CPPFLAGS = $(AM_CPPFLAGS) @OPENSSL_CFLAGS@ -pdbtool_LDADD = ../../lib/libsyslog-ng.la libdbparser.la @OPENSSL_LIBS@ @DEPS_LIBS@ +pdbtool_LDADD = ../../lib/libsyslog-ng.la -dlpreopen libdbparser.la @OPENSSL_LIBS@ @DEPS_LIBS@
BUILT_SOURCES = dbparser-grammar.y dbparser-grammar.c dbparser-grammar.h EXTRA_DIST = $(BUILT_SOURCES) radix-find.c dbparser-grammar.ym
Hi Corinna,
Funny you should mention this one.
I had a similar problem here where listing the OpenSSL ahead of listing the DEPS_LIBS caused me to pick up the system OpenSSL instead of the more updated OpenSSL in the install prefix.
So it seems I'm not the only one who ran into it.
For what it's worth on my end I worked around it using LIBS env var which gets subbed into the linker args ahead of where LDFLAGS does so your stuff gets put earlier in the search path.
Hi Matthew, I'm sorry, but I don't see how these two items are related. The problem the above patch is trying to fix is to avoid a warning when linking against a dlopen module. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat
Any ideas why Ubuntu uses such an old libtool?
According to http://ftp.gnu.org/gnu/libtool/: libtool-2.4.tar.gz 22-Sep-2010 11:08 Too late by quite some ways to make the freeze cutoff for Ubuntu 10.04 Lucid or even for 10.10 Maverick. Debian only has 2.2.10 even in experimental. GNU skipped 2.3.*. So nobody probably had time to make the update to this real new version yet. Matthew.
On Thu, 2010-12-09 at 13:11 -0800, Matthew Hall wrote:
Any ideas why Ubuntu uses such an old libtool?
According to http://ftp.gnu.org/gnu/libtool/:
libtool-2.4.tar.gz 22-Sep-2010 11:08
Too late by quite some ways to make the freeze cutoff for Ubuntu 10.04 Lucid or even for 10.10 Maverick.
Debian only has 2.2.10 even in experimental. GNU skipped 2.3.*.
So nobody probably had time to make the update to this real new version yet.
So it's not that old after all :) I hope natty will have a newer version, though I guess it needs to be updated in Debian first, which still has 2.2.6b. -- Bazsi
participants (5)
-
Balazs Scheidler
-
Corinna Vinschen
-
Marius Tomaschewski
-
Matthew Hall
-
Peter Czanik