On Mon, Jan 10, 2011 at 06:25:41PM -0800, Lutz Mutz wrote:

Hey everyone,

I'm trying to compile syslog-ng 3.2.1 on CentOS 5.3 which is running glib 2.12.3-4, and get this error:

./.libs/libdbparser.so: undefined reference to `g_timeout_add_seconds' collect2: ld returned 1 exit status make[5]: *** [pdbtool] Error 1 make[5]: Leaving directory `/usr/local/src/syslog-ng-3.2.1/modules/dbparser' make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory `/usr/local/src/syslog-ng-3.2.1/modules/dbparser' make[3]: *** [all] Error 2 make[3]: Leaving directory `/usr/local/src/syslog-ng-3.2.1/modules/dbparser' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/usr/local/src/syslog-ng-3.2.1/modules' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/src/syslog-ng-3.2.1' make: *** [all] Error 2

As I understand g_timeout_add_seconds was added to glib 2.14, which CentOS doesn't support yet. Now my question is, there was a big filed a while ago about this, does balabit plan on implementing the old api for glib to support 3.2.1 for glib < 2.14 ? Knowing the fact that CentOS is such a popular and wide distribution, why not make it easy for us and patch it? Is my other choice to just compile it statically on a system running glib >= 2.14 and then install the binary on the CentOS system?

Thanks, Lutz Hello,

Using the older API is Bazsi's decision, but I have doubts about it's feasibility. My recommendation is building a GLIB 2.14 and installing it to an alternative directory and link to it(see below). If it doesn't work, I recommend trying the pre-compiled OSE installers built by BalaBit, which bring all their dependencies with them. You can download them from http://www.balabit.com/downloads/files?path=/syslog-ng/sources/3.2.1/setups Building your own binaries: --------------------------- I don't recommend building a statically linked syslog-ng on different (not CentOS machine I presume) machine. Depending the differences between the distributions, you can get a binary that won't even run on CentOS 5.3 because it too needs a newer version of glibc (missing GLIBC_2.X.X symbols error) and/or other dependencies which won't be linked statically but both distributions have incompatible incompatible versions of them(openssl as a prime suspect). I recommend you to compile and install glib 2.14 to an alternative location(but not under /usr/local/lib or any other path listed in ld.so's configuration /etc/ld.so.conf) on the CentOS machine and either link to it statically or use rpath to force the dynamic linker to look for the dependencies in the said path first. To compile with the alternative glib, add '/path/to/glib214/lib/pkgconfig' to the beginning of PKG_CONFIG_PATH. If the alternative directory contains other dependencies which are not managed by pkg-config(1)*, then add the following to CFLAGS variable: -I</path/to/glib214>/include and this to LDFLAGS: -L</path/to/glib214>/lib If you want to use -rpath, say to distribute the compiled binary and it's dependencies to other machines, add '-Wl,-R,/path/to/glib214/lib' to LDFLAGS. Also prepend PATH with /path/to/glib214/bin and LD_LIBRARY_PATH with /path/to/glib214/bin, then run ./configure and build syslog-ng. I don't recommend exporting LDFLAGS and CFLAGS, you better off specifying them on the command line to ./configure: CFLAGS="-I/path/to/glib214/include <other CFLAGS opts>" \ LDFLAGS="-L/path/to/glib214/lib <other linker opts>" \ ./configure ... You can do that with the other needed environment variables (PATH, LD_LIBRARY_PATH and PKG_CONFIG_PATH) too. * the libiconv and gettext libraries on the system might be too old for GLIB 2.14, probably you need to build a custom version of them too. Luckily they don't have dependencies except each other. Adding -I<path> and -L<path> to their LDFLAGS and CFLAGS will do the trick along with adding '--without-libiconv-prefix --without-libintl-prefix' to libiconv's ./configure and '--with-libiconv-prefix=<path> --with-libintl-prefix=<path>' to gettext's ./configure. -- Pal Tamas/Folti folti@balabit.hu