On Tue, 2011-11-15 at 17:36 +0100, Pal Tamas wrote:

Hi,

On Tue, Nov 15, 2011 at 10:09:50AM -0600, Marvin Nipper wrote:

...

Apologies upfront for the length, but this addresses two different problems.

Environment: Solaris 10 x64 U10, fully patched (i.e. pretty much "new"). Currently operating (successfully) with 3.0.5, compiled on that platform, and distributed to a number of other Solaris 10 x64 targets.

Problem: Trying to "make the leap" to 3.3.2, and get current, but that version seems to have numerous Solaris compatibility issues. Just trying to understand the status of Solaris support.

Problem #1 Latest packaging no longer works with Solaris-based "make".

After a clean configure (output here): syslog-ng Open Source Edition 3.3.2 configured Compiler options: compiler : gcc -std=gnu99 compiler options : -g -O2 -Wall -pthread -D_REENTRANT -D_PTHREADS -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/ include/eventlog -I/usr/local/ssl/include -DLIBNET_LIL_ENDIAN -I$ (top_srcdir)/lib/ivykis/lib/include -I$(top_builddir)/lib/ivykis/lib/include -I$(top_srcdir)/lib/ivykis/modules/include -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 linker flags : -R/usr/local/lib -lpthread prefix : /usr/local linking mode : dynamic __thread keyword : yes Submodules: ivykis : internal libmongo-client : internal Features: Debug symbols : no GCC profiling : no Memtrace : no IPV6 support : yes spoof-source support : yes tcp-wrapper support : no Linux capability support : no PCRE support : no Env wrapper support : no systemd support : no (unit dir: none) Modules: Module search path : /usr/local/lib/syslog-ng Default module list : affile,afprog,afsocket,afuser,basicfuncs,csvparser,dbparser,syslogformat,afstreams Sun STREAMS support (module): yes SSL support (module) : yes SQL support (module) : no PACCT module (EXPERIMENTAL) : no MongoDB destination (module): yes JSON support (module) : no (using no)

..... a simple "make" attempt now immediately results in this: # make make all-recursive Making all in lib make: Fatal error in reader: Makefile, line 991: Unexpected end of line seen Current working directory /var/opt/packages/syslog-ng-3.3.2/lib *** Error code 1 The following command caused the error: fail= failcom='exit 1'; \ for f in x $MAKEFLAGS; do \ case $f in \ *=* | --[!k]*);; \ *k*) failcom='fail=yes';; \ esac; \ done; \ dot_seen=no; \ target=`echo all-recursive | sed s/-recursive//`; \ list='lib modules syslog-ng scripts tests doc contrib scl debian tgz2build build'; for subdir in $list; do \ echo "Making $target in $subdir"; \ if test "$subdir" = "."; then \ dot_seen=yes; \ local_target="$target-am"; \ else \ local_target="$target"; \ fi; \ (CDPATH="${ZSH_VERSION+.}:" && cd $subdir && make $local_target) \ || eval $failcom; \ done; \ if test "$dot_seen" = "no"; then \ make "$target-am" || exit 1; \ fi; test -z "$fail" make: Fatal error: Command failed for target `all-recursive' Current working directory /var/opt/packages/syslog-ng-3.3.2 *** Error code 1 make: Fatal error: Command failed for target `all'

Not being a developer, per se, I spent time in Google-land, the general result that I find is: "These are caused because Solaris "make" doesn't accept the ‘GNU multi-line Makefile format’. Use gmake instead." But there are obviously folks who also say that this can be fixed by "correcting" the problems in the Makefiles (so that would seem to be a preferable alternative). The syslog-ng uses the "autoconfuse" (automake and autoconf tools) system to generate the makefiles needed for build. Since both autoconf and automake are part of the GNU project, the Makefiles generated by them are GNU make specific. Sorry there's no way around it.

If you hadn't done it, please install the SUNWgcmn (Common GNU package) and the SUNWgmake from your Solaris install media. It'll put a gmake into /usr/sfw/bin.

...

Problem #2 Can no longer perform successful compilations, due to this error: ld: fatal: relocation error: R_386_GOTOFF

Same configure output as previously shown, followed by gmake (to get around the first problem).

Numerous modules compile successfully, but then this happens: gcc -DHAVE_CONFIG_H -I. -I../.. -D_GNU_SOURCE -I../../lib/include -I../../lib/ include -I../../modules/include -Wall -g -O2 -D_REENTRANT -D_POSIX_C_SOURCE= 199506L -D_POSIX_PTHREAD_SEMANTICS -D_XPG4_2 -MT iv_event_test.o -MD -MP -MF .deps/iv_event_test.Tpo -c -o iv_event_test.o iv_event_test.c mv -f .deps/iv_event_test.Tpo .deps/iv_event_test.Po /bin/bash ../../libtool --tag=CC --mode=link gcc -Wall -g -O2 -D_REENTRANT -D_POSIX_C_SOURCE=199506L -D_POSIX_PTHREAD_SEMANTICS -D_XPG4_2 -R/usr/local/ lib -o iv_event_test iv_event_test.o ../../lib/libivykis.la ../ libivykis-modules.la -lrt -lpthread -lsocket libtool: link: gcc -Wall -g -O2 -D_REENTRANT -D_POSIX_C_SOURCE=199506L -D_POSIX_PTHREAD_SEMANTICS -D_XPG4_2 -o iv_event_test iv_event_test.o ../../ lib/.libs/libivykis.a ../.libs/libivykis-modules.a /var/opt/packages/ syslog-ng-3.3.2/lib/ivykis/lib/.libs/libivykis.a -lrt -lpthread -lsocket -R/usr /local/lib ld: fatal: relocation error: R_386_GOTOFF: file ../.libs/libivykis-modules.a (iv_event.o): symbol __tls: relocation illegal for TLS symbol ld: fatal: relocation error: R_386_GOTOFF: file ../.libs/libivykis-modules.a (iv_event.o): symbol __tls: relocation illegal for TLS symbol ld: fatal: relocation error: R_386_GOTOFF: file ../.libs/libivykis-modules.a (iv_event.o): symbol __tls: relocation illegal for TLS symbol ld: fatal: relocation error: R_386_GOTOFF: file ../.libs/libivykis-modules.a (iv_event.o): symbol __tls: relocation illegal for TLS symbol collect2: ld returned 1 exit status gmake[7]: *** [iv_event_test] Error 1 gmake[7]: Leaving directory `/var/opt/packages/syslog-ng-3.3.2/lib/ivykis/ modules/test' gmake[6]: *** [all-recursive] Error 1 gmake[6]: Leaving directory `/var/opt/packages/syslog-ng-3.3.2/lib/ivykis/ modules' gmake[5]: *** [all-recursive] Error 1 gmake[5]: Leaving directory `/var/opt/packages/syslog-ng-3.3.2/lib/ivykis' gmake[4]: *** [all] Error 2 gmake[4]: Leaving directory `/var/opt/packages/syslog-ng-3.3.2/lib/ivykis' gmake[3]: *** [all-recursive] Error 1 gmake[3]: Leaving directory `/var/opt/packages/syslog-ng-3.3.2/lib' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/var/opt/packages/syslog-ng-3.3.2/lib' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/var/opt/packages/syslog-ng-3.3.2' gmake: *** [all] Error 2

Again, adopting the "Google is my friend" approach, this appears to be an issue with "Solaris not supporting Visibility". (http://www.ilkda.com/compile/ Build_Problems.htm) Most of the sites where I see this being discussed, with other (various) source components, I also see the developers subsequently modifying their environment to "adjust for" the Visibility issue in Solaris.

So, again, not being a C developer myself, I guess I'm wondering whether I'm just doing something wrong with 3.3.2 (i.e. something that I need to do different from my 3.0.5 compilation), or whether this is truly just a "Solaris thing" that has not been accounted for in the current code base?

Looks like your gcc doesn't support TLS (Thread Local Storage) properly. The only way we were able to solve it by building a new (4.6.0) gcc following the steps in this blog post: http://jblopen.com/node/16

There's a bundled library in syslog-ng code, ivykis. The error happens when linking one of the test programs for ivykis. I'm not sure why that happens, it does link for us properly, but maybe because we use a different compiler (as described by Folti). However TLS (=Thread Local Storage) is not a mandatory compiler feature, both syslog-ng and ivykis can operate without it, the issue is that the configure script detects that your compiler/linker is supposed to support it. Check out syslog-ng-3.3.2/config.log and syslog-ng-3.3.2/lib/ivykis/config.log, and look for "__thread" in the logs, alternatively check config.h for both directories and check if * syslog-ng/config.h: HAVE_THREAD_KEYWORD is defined * syslog-ng/lib/ivykis/config.h: HAVE_TLS is defined. It'll probably be defined. You can retry compilation by changing the config.h files and undef those and recompile. The only question is why it gets detected and not work at the end. This test is used for both: AC_LINK_IFELSE([AC_LANG_PROGRAM( [[#include <pthread.h> __thread int a; ]], [a=0;])], [ac_cv_have_tls=yes; AC_DEFINE_UNQUOTED(HAVE_THREAD_KEYWORD, 1, "Whether Transport Layer Security is supported by the system")]) I'm not sure if we can actually reliably detect if TLS is available. It could make sense to make it a configure parameter after all. (which I'm usually against...). syslog-ng does support Solaris (the PE staff regularly compiles & tests it under Solaris 8, 9, 10; sparc, i386, amd64), however it is not just Solaris, gcc/binutils/etc are all part of the picture. Keeping a "good" build environment on these platforms is not always easy. The use of __thread is completely optional in the codebase itself. -- Bazsi

Bazsi, As a follow-up to my last email, I did change the values in the two header files that you mentioned trying. The compilation then went much further, but failed at a later point, for similar reasons as before: libtool: link: gcc -std=gnu99 -shared -Wl,-z -Wl,text -Wl,-h -Wl,libsyslog-ng-3.3.2.so -o .libs/libsyslog-ng-3.3.2.so .libs/afinter.o .libs/alarms.o .libs/apphook.o .libs/block-ref-parser.o .libs/center.o .libs/cfg.o .libs/cfg-lexer.o .libs/cfg-parser.o .libs/children.o .libs/compat.o .libs/control.o .libs/dgroup.o .libs/dnscache.o .libs/driver.o .libs/filter.o .libs/filter-expr-parser.o .libs/globals.o .libs/gprocess.o .libs/gsockaddr.o .libs/gsocket.o .libs/logmatcher.o .libs/logmpx.o .libs/logmsg.o .libs/logparser.o .libs/logpipe.o .libs/logprocess.o .libs/logproto.o .libs/logqueue.o .libs/logqueue-fifo.o .libs/logreader.o .libs/logrewrite.o .libs/logsource.o .libs/logstamp.o .libs/logtransport.o .libs/logwriter.o .libs/mainloop.o .libs/memtrace.o .libs/messages.o .libs/misc.o .libs/msg-format.o .libs/nvtable.o .libs/parser-expr-parser.o .libs/persist-state.o .libs/plugin.o .libs/pragma-parser.o .libs/rewrite-expr-parser.o .libs/scratch-buffers.o .libs/serialize.o .libs/sgroup.o .libs/stats.o .libs/str-format.o .libs/syslog-names.o .libs/tags.o .libs/templates.o .libs/timeutils.o .libs/utils.o .libs/value-pairs.o .libs/cfg-lex.o .libs/cfg-grammar.o .libs/filter-expr-grammar.o .libs/block-ref-grammar.o .libs/pragma-grammar.o .libs/parser-expr-grammar.o .libs/rewrite-expr-grammar.o -R/usr/local/lib -R/usr/local/lib -L/var/opt/packages/syslog-ng-3.3.2/lib/ivykis/lib/.libs -ldoor -lsocket -lnsl -L/usr/local/lib /usr/local/lib/libgmodule-2.0.so /usr/local/lib/libgthread-2.0.so -lthread -lrt /usr/local/lib/libglib-2.0.so /usr/local/lib/libevtlog.so -lresolv -ldl -L/var/opt/packages/syslog-ng-3.3.2/lib/ivykis/lib /var/opt/packages/syslog-ng-3.3.2/lib/ivykis/lib/.libs/libivykis.a -L/var/opt/packages/syslog-ng-3.3.2/lib/ivykis/modules /var/opt/packages/syslog-ng-3.3.2/lib/ivykis/modules/.libs/libivykis-modules.a -lpthread -lc -pthread -Wl,--whole-archive -Wl,--no-whole-archive -pthread gcc: unrecognized option `-pthread' gcc: unrecognized option `-pthread' ld: fatal: relocation error: R_386_GOTOFF: file .libs/mainloop.o: symbol __tls: relocation illegal for TLS symbol ld: fatal: relocation error: R_386_GOTOFF: file .libs/mainloop.o: symbol __tls: relocation illegal for TLS symbol ld: fatal: relocation error: R_386_GOTOFF: file .libs/mainloop.o: symbol __tls: relocation illegal for TLS symbol ld: fatal: relocation error: R_386_GOTOFF: file .libs/mainloop.o: symbol __tls: relocation illegal for TLS symbol ld: fatal: relocation error: R_386_GOTOFF: file .libs/mainloop.o: symbol __tls: relocation illegal for TLS symbol collect2: ld returned 1 exit status gmake[4]: *** [libsyslog-ng.la] Error 1 gmake[4]: Leaving directory `/var/opt/packages/syslog-ng-3.3.2/lib' gmake[3]: *** [all-recursive] Error 1 gmake[3]: Leaving directory `/var/opt/packages/syslog-ng-3.3.2/lib' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/var/opt/packages/syslog-ng-3.3.2/lib' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/var/opt/packages/syslog-ng-3.3.2' gmake: *** [all] Error 2 Also note that the compiler (throughout all of the compilations) does continually complain about the -pthread option. All of this is just FYI, in case you do attempt to tackle this. Thanks again. -----Original Message----- From: Marvin Nipper Sent: Tuesday, November 15, 2011 12:54 PM To: 'Syslog-ng users' and developers' mailing list' Subject: RE: [syslog-ng] Solaris 10 support(?) in latest versions (e.g. 3.3.2) See below, tagged with my name. -----Original Message----- From: syslog-ng-bounces@lists.balabit.hu [mailto:syslog-ng-bounces@lists.balabit.hu] On Behalf Of Balazs Scheidler Sent: Tuesday, November 15, 2011 12:12 PM To: Syslog-ng users' and developers' mailing list Subject: Re: [syslog-ng] Solaris 10 support(?) in latest versions (e.g. 3.3.2) [Marvin Nipper] ---Purging content, due to email size---- There's a bundled library in syslog-ng code, ivykis. The error happens when linking one of the test programs for ivykis. I'm not sure why that happens, it does link for us properly, but maybe because we use a different compiler (as described by Folti). However TLS (=Thread Local Storage) is not a mandatory compiler feature, both syslog-ng and ivykis can operate without it, the issue is that the configure script detects that your compiler/linker is supposed to support it. Check out syslog-ng-3.3.2/config.log and syslog-ng-3.3.2/lib/ivykis/config.log, and look for "__thread" in the logs, [Marvin Nipper] FYI, neither of these has any instance of this string. alternatively check config.h for both directories and check if * syslog-ng/config.h: HAVE_THREAD_KEYWORD is defined [Marvin Nipper] Yes: #define HAVE_THREAD_KEYWORD 1 * syslog-ng/lib/ivykis/config.h: HAVE_TLS is defined. [Marvin Nipper] Yes: #define HAVE_TLS 1 It'll probably be defined. You can retry compilation by changing the config.h files and undef those and recompile. The only question is why it gets detected and not work at the end. This test is used for both: AC_LINK_IFELSE([AC_LANG_PROGRAM( [[#include <pthread.h> __thread int a; ]], [a=0;])], [ac_cv_have_tls=yes; AC_DEFINE_UNQUOTED(HAVE_THREAD_KEYWORD, 1, "Whether Transport Layer Security is supported by the system")]) [Marvin Nipper] making an assumption about the syntax of this test, my pthread.h (in /usr/include) has no instance of ac_cv_have_tls. I'm not sure if we can actually reliably detect if TLS is available. It could make sense to make it a configure parameter after all. (which I'm usually against...). syslog-ng does support Solaris (the PE staff regularly compiles & tests it under Solaris 8, 9, 10; sparc, i386, amd64), however it is not just Solaris, gcc/binutils/etc are all part of the picture. Keeping a "good" build environment on these platforms is not always easy. [Marvin Nipper] "Annoyingly", I "blew away" the previous version of my Dev server, which was a patched up version of Solaris 10 U4, and replaced it with a "brand spanking new" U10 deployment (as previously mentioned). My primary reason for doing that was that I'd HOPED, in the MANY years between the U4 and U10 versions, that maybe Sun(Oracle) has actually "done something useful", and brought their GCC components up to something beyond 3.4.3. Of course, I was horribly disappointed to find out that the development components in their sfw deployment, were still just as "ancient" as before. I had also (at that same time) looked into the GNU instructions for building a current version of GCC, but there are a TON of dependencies (and it looked "messy", which is probably an understatement). I really didn't have time to mess with it, when I checked it out, and I also figured that I probably only had a 50/50 chance of producing something that would work properly (based on all of the dependent components). I DID just check out that jblopen.com blog, from Pal's email, and that seems like a FAR EASIER set of instructions for producing a newer version of GCC. I'll try to set aside some time, at some point in the not-too-distant future, to see if I can build a better compiler. Obviously, if you see anything from my input above, that would allow this to compile properly on the "stock version" of Solaris 10 (U10), that would also be helpful. I WILL try messing with the "config" header files, to see if I can use that for now, and again, if you need me to test anything, I'm glad to do that as well. !!!!!!!!!!! THANKS to everyone who responded so quickly !!!!!!!!!!!!! M. The use of __thread is completely optional in the codebase itself. -- Bazsi ______________________________________________________________________________ Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: http://www.balabit.com/wiki/syslog-ng-faq This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

On Tue, Nov 15, 2011 at 08:11:34PM +0100, Balazs Scheidler wrote:

On Tue, 2011-11-15 at 17:36 +0100, Pal Tamas wrote:

...

Hi,

On Tue, Nov 15, 2011 at 10:09:50AM -0600, Marvin Nipper wrote:

...

Apologies upfront for the length, but this addresses two different problems.

Environment: Solaris 10 x64 U10, fully patched (i.e. pretty much "new"). Currently operating (successfully) with 3.0.5, compiled on that platform, and distributed to a number of other Solaris 10 x64 targets.

Problem: Trying to "make the leap" to 3.3.2, and get current, but that version seems to have numerous Solaris compatibility issues. Just trying to understand the status of Solaris support.

Problem #1 Latest packaging no longer works with Solaris-based "make".

After a clean configure (output here): syslog-ng Open Source Edition 3.3.2 configured Compiler options: compiler : gcc -std=gnu99 compiler options : -g -O2 -Wall -pthread -D_REENTRANT -D_PTHREADS -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/ include/eventlog -I/usr/local/ssl/include -DLIBNET_LIL_ENDIAN -I$ (top_srcdir)/lib/ivykis/lib/include -I$(top_builddir)/lib/ivykis/lib/include -I$(top_srcdir)/lib/ivykis/modules/include -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 linker flags : -R/usr/local/lib -lpthread prefix : /usr/local linking mode : dynamic __thread keyword : yes Submodules: ivykis : internal libmongo-client : internal Features: Debug symbols : no GCC profiling : no Memtrace : no IPV6 support : yes spoof-source support : yes tcp-wrapper support : no Linux capability support : no PCRE support : no Env wrapper support : no systemd support : no (unit dir: none) Modules: Module search path : /usr/local/lib/syslog-ng Default module list : affile,afprog,afsocket,afuser,basicfuncs,csvparser,dbparser,syslogformat,afstreams Sun STREAMS support (module): yes SSL support (module) : yes SQL support (module) : no PACCT module (EXPERIMENTAL) : no MongoDB destination (module): yes JSON support (module) : no (using no)

..... a simple "make" attempt now immediately results in this: # make make all-recursive Making all in lib make: Fatal error in reader: Makefile, line 991: Unexpected end of line seen Current working directory /var/opt/packages/syslog-ng-3.3.2/lib *** Error code 1 The following command caused the error: fail= failcom='exit 1'; \ for f in x $MAKEFLAGS; do \ case $f in \ *=* | --[!k]*);; \ *k*) failcom='fail=yes';; \ esac; \ done; \ dot_seen=no; \ target=`echo all-recursive | sed s/-recursive//`; \ list='lib modules syslog-ng scripts tests doc contrib scl debian tgz2build build'; for subdir in $list; do \ echo "Making $target in $subdir"; \ if test "$subdir" = "."; then \ dot_seen=yes; \ local_target="$target-am"; \ else \ local_target="$target"; \ fi; \ (CDPATH="${ZSH_VERSION+.}:" && cd $subdir && make $local_target) \ || eval $failcom; \ done; \ if test "$dot_seen" = "no"; then \ make "$target-am" || exit 1; \ fi; test -z "$fail" make: Fatal error: Command failed for target `all-recursive' Current working directory /var/opt/packages/syslog-ng-3.3.2 *** Error code 1 make: Fatal error: Command failed for target `all'

Not being a developer, per se, I spent time in Google-land, the general result that I find is: "These are caused because Solaris "make" doesn't accept the ‘GNU multi-line Makefile format’. Use gmake instead." But there are obviously folks who also say that this can be fixed by "correcting" the problems in the Makefiles (so that would seem to be a preferable alternative). The syslog-ng uses the "autoconfuse" (automake and autoconf tools) system to generate the makefiles needed for build. Since both autoconf and automake are part of the GNU project, the Makefiles generated by them are GNU make specific. Sorry there's no way around it.

If you hadn't done it, please install the SUNWgcmn (Common GNU package) and the SUNWgmake from your Solaris install media. It'll put a gmake into /usr/sfw/bin.

...

Problem #2 Can no longer perform successful compilations, due to this error: ld: fatal: relocation error: R_386_GOTOFF

Same configure output as previously shown, followed by gmake (to get around the first problem).

Numerous modules compile successfully, but then this happens: gcc -DHAVE_CONFIG_H -I. -I../.. -D_GNU_SOURCE -I../../lib/include -I../../lib/ include -I../../modules/include -Wall -g -O2 -D_REENTRANT -D_POSIX_C_SOURCE= 199506L -D_POSIX_PTHREAD_SEMANTICS -D_XPG4_2 -MT iv_event_test.o -MD -MP -MF .deps/iv_event_test.Tpo -c -o iv_event_test.o iv_event_test.c mv -f .deps/iv_event_test.Tpo .deps/iv_event_test.Po /bin/bash ../../libtool --tag=CC --mode=link gcc -Wall -g -O2 -D_REENTRANT -D_POSIX_C_SOURCE=199506L -D_POSIX_PTHREAD_SEMANTICS -D_XPG4_2 -R/usr/local/ lib -o iv_event_test iv_event_test.o ../../lib/libivykis.la ../ libivykis-modules.la -lrt -lpthread -lsocket libtool: link: gcc -Wall -g -O2 -D_REENTRANT -D_POSIX_C_SOURCE=199506L -D_POSIX_PTHREAD_SEMANTICS -D_XPG4_2 -o iv_event_test iv_event_test.o ../../ lib/.libs/libivykis.a ../.libs/libivykis-modules.a /var/opt/packages/ syslog-ng-3.3.2/lib/ivykis/lib/.libs/libivykis.a -lrt -lpthread -lsocket -R/usr /local/lib ld: fatal: relocation error: R_386_GOTOFF: file ../.libs/libivykis-modules.a (iv_event.o): symbol __tls: relocation illegal for TLS symbol ld: fatal: relocation error: R_386_GOTOFF: file ../.libs/libivykis-modules.a (iv_event.o): symbol __tls: relocation illegal for TLS symbol ld: fatal: relocation error: R_386_GOTOFF: file ../.libs/libivykis-modules.a (iv_event.o): symbol __tls: relocation illegal for TLS symbol ld: fatal: relocation error: R_386_GOTOFF: file ../.libs/libivykis-modules.a (iv_event.o): symbol __tls: relocation illegal for TLS symbol collect2: ld returned 1 exit status gmake[7]: *** [iv_event_test] Error 1 gmake[7]: Leaving directory `/var/opt/packages/syslog-ng-3.3.2/lib/ivykis/ modules/test' gmake[6]: *** [all-recursive] Error 1 gmake[6]: Leaving directory `/var/opt/packages/syslog-ng-3.3.2/lib/ivykis/ modules' gmake[5]: *** [all-recursive] Error 1 gmake[5]: Leaving directory `/var/opt/packages/syslog-ng-3.3.2/lib/ivykis' gmake[4]: *** [all] Error 2 gmake[4]: Leaving directory `/var/opt/packages/syslog-ng-3.3.2/lib/ivykis' gmake[3]: *** [all-recursive] Error 1 gmake[3]: Leaving directory `/var/opt/packages/syslog-ng-3.3.2/lib' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/var/opt/packages/syslog-ng-3.3.2/lib' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/var/opt/packages/syslog-ng-3.3.2' gmake: *** [all] Error 2

Again, adopting the "Google is my friend" approach, this appears to be an issue with "Solaris not supporting Visibility". (http://www.ilkda.com/compile/ Build_Problems.htm) Most of the sites where I see this being discussed, with other (various) source components, I also see the developers subsequently modifying their environment to "adjust for" the Visibility issue in Solaris.

So, again, not being a C developer myself, I guess I'm wondering whether I'm just doing something wrong with 3.3.2 (i.e. something that I need to do different from my 3.0.5 compilation), or whether this is truly just a "Solaris thing" that has not been accounted for in the current code base?

Looks like your gcc doesn't support TLS (Thread Local Storage) properly. The only way we were able to solve it by building a new (4.6.0) gcc following the steps in this blog post: http://jblopen.com/node/16

There's a bundled library in syslog-ng code, ivykis. The error happens when linking one of the test programs for ivykis. I'm not sure why that happens, it does link for us properly, but maybe because we use a different compiler (as described by Folti).

However TLS (=Thread Local Storage) is not a mandatory compiler feature, both syslog-ng and ivykis can operate without it, the issue is that the configure script detects that your compiler/linker is supposed to support it.

Check out syslog-ng-3.3.2/config.log and syslog-ng-3.3.2/lib/ivykis/config.log, and look for "__thread" in the logs, alternatively check config.h for both directories and check if * syslog-ng/config.h: HAVE_THREAD_KEYWORD is defined * syslog-ng/lib/ivykis/config.h: HAVE_TLS is defined.

It'll probably be defined. You can retry compilation by changing the config.h files and undef those and recompile.

The only question is why it gets detected and not work at the end. This test is used for both:

AC_LINK_IFELSE([AC_LANG_PROGRAM( [[#include <pthread.h> __thread int a; ]], [a=0;])], [ac_cv_have_tls=yes; AC_DEFINE_UNQUOTED(HAVE_THREAD_KEYWORD, 1, "Whether Transport Layer Security is supported by the system")])

I'm not sure if we can actually reliably detect if TLS is available. It could make sense to make it a configure parameter after all. (which I'm usually against...). Because on a vanilla Solaris __thread works as long as you use it in an executable. If you use it in a library then try to link said library to an executeble, you'll get the error. Probably we would be better off in the long run, if we provide a configure parameter to disable TLS on systems where it's broken by default.

syslog-ng does support Solaris (the PE staff regularly compiles & tests it under Solaris 8, 9, 10; sparc, i386, amd64), however it is not just Solaris, gcc/binutils/etc are all part of the picture. Also patches. Our u4 builderbox has been patches applied which modify the linker too. These are: 120830-05 118833-36 120011-14 125095-15

-- Pal Tamas/Folti folti@balabit.hu

On Thu, 2011-11-17 at 13:27 -0600, Marvin Nipper wrote:

OK. After a "day and a half" of "hoop jumping", I managed to build a gcc 4.4.2 compiler on Solaris 10. That's definitely _not_ a straightforward effort, and I had to "pick and choose" things from a number of different sites, to get that to work correctly.

So... I have successfully used that new compiler to rebuild my working syslog-ng 3.0.5 executable, so I know that it works. (And I completely recompiled all of the underlying components, including pkg-config, libnet, glib, eventlog, and, openssl, so that none of the original gcc 3.4.3 "stuff" would be used.) I even validated (with ldd) that the new executable had correctly linked the new gcc components (and nothing from the old gcc 3.4.3 world).

So THEN, I tried, again, to compile the syslog-ng 3.3.2 components.

The good news is that it did not abend on the previously reported TLS-related portion of the code! (a "small success"!).

The bad news is that it now gets to this point in the process (obviously a really long line): /bin/bash ../libtool --tag=CC --mode=link gcc -std=gnu99 -g -O2 -Wall -pthrea d -no-undefined -release 3.3.2 -R/usr/local/lib -o libsyslog-ng.la -rpath /usr/l ocal/lib afinter.lo alarms.lo apphook.lo block-ref-parser.lo center.lo cfg.lo cf g-lexer.lo cfg-parser.lo children.lo compat.lo control.lo dgroup.lo dnscache.lo driver.lo filter.lo filter-expr-parser.lo globals.lo gprocess.lo gsockaddr.lo gs ocket.lo logmatcher.lo logmpx.lo logmsg.lo logparser.lo logpipe.lo logprocess.lo logproto.lo logqueue.lo logqueue-fifo.lo logreader.lo logrewrite.lo logsource.l o logstamp.lo logtransport.lo logwriter.lo mainloop.lo memtrace.lo messages.lo m isc.lo msg-format.lo nvtable.lo parser-expr-parser.lo persist-state.lo plugin.lo pragma-parser.lo rewrite-expr-parser.lo scratch-buffers.lo serialize.lo sgroup. lo stats.lo str-format.lo syslog-names.lo tags.lo templates.lo timeutils.lo util s.lo value-pairs.lo cfg-lex.lo cfg-grammar.lo filter-expr-grammar.lo block-ref-g rammar.lo pragma-grammar.lo parser-expr-grammar.lo rewrite-expr-grammar.lo -lpth read -ldoor -lsocket -lrt -lnsl -L/usr/local/lib -lgmodule-2.0 -lgthread-2.0 - lpthread -lthread -lrt -lglib-2.0 -L/usr/local/lib -levtlog -lresolv -ldl -Wl,--whole-archive -L../lib/ivykis/lib -livykis -L../lib/ivykis/modules -livyk is-modules -Wl,--no-whole-archive -lpthread

And then starts throwing out these errors: ld: fatal: symbol 'g_trash_stack_push' is multiply-defined: (file .libs/afinter.o type=FUNC; file .libs/alarms.o type=FUNC); ld: fatal: symbol 'g_trash_stack_pop' is multiply-defined: (file .libs/afinter.o type=FUNC; file .libs/alarms.o type=FUNC); ld: fatal: symbol 'g_trash_stack_peek' is multiply-defined: (file .libs/afinter.o type=FUNC; file .libs/alarms.o type=FUNC); ld: fatal: symbol 'g_trash_stack_height' is multiply-defined: (file .libs/afinter.o type=FUNC; file .libs/alarms.o type=FUNC); ld: fatal: symbol 'g_bit_nth_msf' is multiply-defined: (file .libs/afinter.o type=FUNC; file .libs/alarms.o type=FUNC); ld: fatal: symbol 'g_bit_nth_lsf' is multiply-defined: (file .libs/afinter.o type=FUNC; file .libs/alarms.o type=FUNC); ld: fatal: symbol 'g_bit_storage' is multiply-defined: (file .libs/afinter.o type=FUNC; file .libs/alarms.o type=FUNC); ld: fatal: symbol 'g_trash_stack_push' is multiply-defined: (file .libs/afinter.o type=FUNC; file .libs/apphook.o type=FUNC); ld: fatal: symbol 'g_trash_stack_pop' is multiply-defined: (file .libs/afinter.o type=FUNC; file .libs/apphook.o type=FUNC); ld: fatal: symbol 'g_trash_stack_peek' is multiply-defined: (file .libs/afinter.o type=FUNC; file .libs/apphook.o type=FUNC); ld: fatal: symbol 'g_trash_stack_height' is multiply-defined: (file .libs/afinter.o type=FUNC; file .libs/apphook.o type=FUNC); ld: fatal: symbol 'g_bit_nth_msf' is multiply-defined:

It issues 427 "multiply-defined" error lines, similar to the ones above, before eventually ending with this final block of output: ld: fatal: symbol 'g_bit_nth_lsf' is multiply-defined: (file .libs/afinter.o type=FUNC; file .libs/rewrite-expr-grammar.o type=FUNC); ld: fatal: symbol 'g_bit_storage' is multiply-defined: (file .libs/afinter.o type=FUNC; file .libs/rewrite-expr-grammar.o type=FUNC); ld: fatal: file processing errors. No output written to .libs/libsyslog-ng-3.3.2.so

hmm.. this seems like a glib header <> library mess, as if it was defined in the header, and becoming part of the compiled module everywhere where the header was included into. This is how g_trash_stack_push() is defined in the glib headers (we're using 2.14.6): G_INLINE_FUNC void g_trash_stack_push (GTrashStack **stack_p, gpointer data_p); G_INLINE_FUNC is defined as a macro in the same file, this way: #if defined (G_HAVE_INLINE) && defined (__GNUC__) && defined (__STRICT_ANSI__) # undef inline # define inline __inline__ #elif !defined (G_HAVE_INLINE) # undef inline # if defined (G_HAVE___INLINE__) # define inline __inline__ # elif defined (G_HAVE___INLINE) # define inline __inline # else /* !inline && !__inline__ && !__inline */ # define inline /* don't inline, then */ # endif #endif #ifdef G_IMPLEMENT_INLINES # define G_INLINE_FUNC # undef G_CAN_INLINE #elif defined (__GNUC__) # if __GNUC_PREREQ (4,2) && defined (__STDC_VERSION__) \ && __STDC_VERSION__ >= 199901L # define G_INLINE_FUNC extern __inline __attribute__ ((__gnu_inline__)) # else # define G_INLINE_FUNC extern __inline # endif #elif defined (G_CAN_INLINE) # define G_INLINE_FUNC static inline #else /* can't inline */ # define G_INLINE_FUNC #endif /* !G_INLINE_FUNC */ The macros that this macro definition depends on are defined in glibconfig.h, usually installed in $prefix/lib/glib-2.0/include/glibconfig.h How do you tell syslog-ng where the glib libraries are? Are those autodetected? are you using pkg-config?

collect2: ld returned 1 exit status gmake[4]: *** [libsyslog-ng.la] Error 1 gmake[4]: Leaving directory `/var/opt/packages/syslog-ng-3.3.2/lib' gmake[3]: *** [all-recursive] Error 1 gmake[3]: Leaving directory `/var/opt/packages/syslog-ng-3.3.2/lib' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/var/opt/packages/syslog-ng-3.3.2/lib' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/var/opt/packages/syslog-ng-3.3.2' gmake: *** [all] Error 2

So, once again, I'm looking for some guidance. My system environment is mentioned in the original thread (below). This is a "really new" Solaris 10 setup (i.e. not some "ancient" version), and now with an operational 4.x gcc compiler, and I still can't seem to make this work.

Sorry to be a pest. I really do appreciate ALL of the assistance that has been given.

no problem, it's just getting a Solaris box up-to-speed for compiling GNU stuff is not easy. sunfreeware makes that easier though. -- Bazsi

On Thu, 2011-11-17 at 21:17 -0600, Marvin Nipper wrote:

-----Original Message----- From: syslog-ng-bounces@lists.balabit.hu [mailto:syslog-ng-bounces@lists.balabit.hu] On Behalf Of Balazs Scheidler Sent: Thursday, November 17, 2011 1:47 PM To: Syslog-ng users' and developers' mailing list Subject: Re: [syslog-ng] Solaris 10 support(?) in latest versions (e.g. 3.3.2)

On Thu, 2011-11-17 at 13:27 -0600, Marvin Nipper wrote:

...

OK. After a "day and a half" of "hoop jumping", I managed to build a gcc 4.4.2 compiler on Solaris 10. That's definitely _not_ a straightforward effort, and I had to "pick and choose" things from a number of different sites, to get that to work correctly.

So... I have successfully used that new compiler to rebuild my working syslog-ng 3.0.5 executable, so I know that it works. (And I completely recompiled all of the underlying components, including pkg-config, libnet, glib, eventlog, and, openssl, so that none of the original gcc 3.4.3 "stuff" would be used.) I even validated (with ldd) that the new executable had correctly linked the new gcc components (and nothing from the old gcc 3.4.3 world).

So THEN, I tried, again, to compile the syslog-ng 3.3.2 components.

The good news is that it did not abend on the previously reported TLS-related portion of the code! (a "small success"!).

The bad news is that it now gets to this point in the process (obviously a really long line): /bin/bash ../libtool --tag=CC --mode=link gcc -std=gnu99 -g -O2 -Wall -pthrea d -no-undefined -release 3.3.2 -R/usr/local/lib -o libsyslog-ng.la -rpath /usr/l ocal/lib afinter.lo alarms.lo apphook.lo block-ref-parser.lo center.lo cfg.lo cf g-lexer.lo cfg-parser.lo children.lo compat.lo control.lo dgroup.lo dnscache.lo driver.lo filter.lo filter-expr-parser.lo globals.lo gprocess.lo gsockaddr.lo gs ocket.lo logmatcher.lo logmpx.lo logmsg.lo logparser.lo logpipe.lo logprocess.lo logproto.lo logqueue.lo logqueue-fifo.lo logreader.lo logrewrite.lo logsource.l o logstamp.lo logtransport.lo logwriter.lo mainloop.lo memtrace.lo messages.lo m isc.lo msg-format.lo nvtable.lo parser-expr-parser.lo persist-state.lo plugin.lo pragma-parser.lo rewrite-expr-parser.lo scratch-buffers.lo serialize.lo sgroup. lo stats.lo str-format.lo syslog-names.lo tags.lo templates.lo timeutils.lo util s.lo value-pairs.lo cfg-lex.lo cfg-grammar.lo filter-expr-grammar.lo block-ref-g rammar.lo pragma-grammar.lo parser-expr-grammar.lo rewrite-expr-grammar.lo -lpth read -ldoor -lsocket -lrt -lnsl -L/usr/local/lib -lgmodule-2.0 -lgthread-2.0 - lpthread -lthread -lrt -lglib-2.0 -L/usr/local/lib -levtlog -lresolv -ldl -Wl,--whole-archive -L../lib/ivykis/lib -livykis -L../lib/ivykis/modules -livyk is-modules -Wl,--no-whole-archive -lpthread

And then starts throwing out these errors: ld: fatal: symbol 'g_trash_stack_push' is multiply-defined: (file .libs/afinter.o type=FUNC; file .libs/alarms.o type=FUNC); ld: fatal: symbol 'g_trash_stack_pop' is multiply-defined: (file .libs/afinter.o type=FUNC; file .libs/alarms.o type=FUNC); ld: fatal: symbol 'g_trash_stack_peek' is multiply-defined: (file .libs/afinter.o type=FUNC; file .libs/alarms.o type=FUNC); ld: fatal: symbol 'g_trash_stack_height' is multiply-defined: (file .libs/afinter.o type=FUNC; file .libs/alarms.o type=FUNC); ld: fatal: symbol 'g_bit_nth_msf' is multiply-defined: (file .libs/afinter.o type=FUNC; file .libs/alarms.o type=FUNC); ld: fatal: symbol 'g_bit_nth_lsf' is multiply-defined: (file .libs/afinter.o type=FUNC; file .libs/alarms.o type=FUNC); ld: fatal: symbol 'g_bit_storage' is multiply-defined: (file .libs/afinter.o type=FUNC; file .libs/alarms.o type=FUNC); ld: fatal: symbol 'g_trash_stack_push' is multiply-defined: (file .libs/afinter.o type=FUNC; file .libs/apphook.o type=FUNC); ld: fatal: symbol 'g_trash_stack_pop' is multiply-defined: (file .libs/afinter.o type=FUNC; file .libs/apphook.o type=FUNC); ld: fatal: symbol 'g_trash_stack_peek' is multiply-defined: (file .libs/afinter.o type=FUNC; file .libs/apphook.o type=FUNC); ld: fatal: symbol 'g_trash_stack_height' is multiply-defined: (file .libs/afinter.o type=FUNC; file .libs/apphook.o type=FUNC); ld: fatal: symbol 'g_bit_nth_msf' is multiply-defined:

It issues 427 "multiply-defined" error lines, similar to the ones above, before eventually ending with this final block of output: ld: fatal: symbol 'g_bit_nth_lsf' is multiply-defined: (file .libs/afinter.o type=FUNC; file .libs/rewrite-expr-grammar.o type=FUNC); ld: fatal: symbol 'g_bit_storage' is multiply-defined: (file .libs/afinter.o type=FUNC; file .libs/rewrite-expr-grammar.o type=FUNC); ld: fatal: file processing errors. No output written to .libs/libsyslog-ng-3.3.2.so

hmm.. this seems like a glib header <> library mess, as if it was defined in the header, and becoming part of the compiled module everywhere where the header was included into.

This is how g_trash_stack_push() is defined in the glib headers (we're using 2.14.6):

G_INLINE_FUNC void g_trash_stack_push (GTrashStack **stack_p, gpointer data_p);

G_INLINE_FUNC is defined as a macro in the same file, this way:

#if defined (G_HAVE_INLINE) && defined (__GNUC__) && defined (__STRICT_ANSI__) # undef inline # define inline __inline__ #elif !defined (G_HAVE_INLINE) # undef inline # if defined (G_HAVE___INLINE__) # define inline __inline__ # elif defined (G_HAVE___INLINE) # define inline __inline # else /* !inline && !__inline__ && !__inline */ # define inline /* don't inline, then */ # endif #endif #ifdef G_IMPLEMENT_INLINES # define G_INLINE_FUNC # undef G_CAN_INLINE #elif defined (__GNUC__) # if __GNUC_PREREQ (4,2) && defined (__STDC_VERSION__) \ && __STDC_VERSION__ >= 199901L # define G_INLINE_FUNC extern __inline __attribute__ ((__gnu_inline__)) # else # define G_INLINE_FUNC extern __inline # endif #elif defined (G_CAN_INLINE) # define G_INLINE_FUNC static inline #else /* can't inline */ # define G_INLINE_FUNC #endif /* !G_INLINE_FUNC */

The macros that this macro definition depends on are defined in glibconfig.h, usually installed in $prefix/lib/glib-2.0/include/glibconfig.h

How do you tell syslog-ng where the glib libraries are? Are those autodetected? are you using pkg-config? [Marvin Nipper] I'm using pkg-config. When building GLIB, I set this variable, before the configure: PKG_CONFIG=/usr/local/bin/pkg-config And when building syslog-ng, I set these variables before running configure: PKG_CONFIG=/usr/local/bin/pkg-config PKG_CONFIG_PATH="$PKG_CONFIG_PATH:/usr/local/lib/pkgconfig:/usr/local/ssl/lib/pkgconfig"

BUT... I downloaded and built the exact version of GLIB that you are using. I then kicked off the 3.3.2 build process again. I did NOT get the "multiply-defined" errors from before, so that seems to be resolved. But annoyingly, I now am having what seems to be a whole new, libnet related problem. It all starts with this stuff: libtool: link: gcc -std=gnu99 -shared -Wl,-z -Wl,text -Wl,-h -Wl,libafsocket-not ls.so -o .libs/libafsocket-notls.so .libs/libafsocket_notls_la-afsocket.o .libs /libafsocket_notls_la-afunix.o .libs/libafsocket_notls_la-afinet.o .libs/libafso cket_notls_la-afsocket-grammar.o .libs/libafsocket_notls_la-afsocket-parser.o .l ibs/libafsocket_notls_la-afsocket-plugin.o -R/var/opt/packages/syslog-ng-3.3.2 /lib/.libs -R/usr/local/lib ../../lib/.libs/libsyslog-ng.so -L/usr/local/lib -L/ var/opt/packages/syslog-ng-3.3.2/lib/ivykis/lib -L/var/opt/packages/syslog-ng-3. 3.2/lib/ivykis/modules -L/var/opt/packages/syslog-ng-3.3.2/lib/ivykis/lib/.libs -lsocket -lnsl -lnet -lpthread -lc -pthread -pthread^M Text relocation remains referenced^M against symbol offset in file^M .rodata (section) 0x7 /usr/lib/libnet.a(libnet_build_i p.o)^M .rodata.str1.1 (merged string section) 0xc /usr/lib/libnet.a(libnet _build_ip.o)^M .rodata (section) 0xdd /usr/lib/libnet.a(libnet_build_i p.o)^M .rodata.str1.1 (merged string section) 0xe2 /usr/lib/libnet.a(libnet _build_ip.o)^M .rodata (section) 0x122 /usr/lib/libnet.a(libnet_build_i p.o)^M .rodata.str1.1 (merged string section) 0x127 /usr/lib/libnet.a(libnet _build_ip.o)^M

After MANY more similar lines (i.e. similar to the lines above), it eventually ends up here: errno 0x375 /usr/lib/libnet.a(libnet_if_addr .o)^M strpbrk 0x318 /usr/lib/libnet.a(libnet_link_dl pi.o)^M ld: fatal: relocations remain against allocatable but non-writable sections^M collect2: ld returned 1 exit status^M gmake[4]: *** [libafsocket-notls.la] Error 1^M gmake[4]: Leaving directory `/var/opt/packages/syslog-ng-3.3.2/modules/afsocket' ^M gmake[3]: *** [all] Error 2^M gmake[3]: Leaving directory `/var/opt/packages/syslog-ng-3.3.2/modules/afsocket' ^M gmake[2]: *** [all-recursive] Error 1^M gmake[2]: Leaving directory `/var/opt/packages/syslog-ng-3.3.2/modules'^M gmake[1]: *** [all-recursive] Error 1^M gmake[1]: Leaving directory `/var/opt/packages/syslog-ng-3.3.2'^M gmake: *** [all] Error 2^M

I just feel like I'm going down the rabbit hole with all of this. I really do wonder how you build your Solaris 10 components, because no matter what I do (newest version of Solaris 10, newly built GCC 4.4.2 compiler, same GLIB, etc.), I just keep stepping into a new mess.

I'm running libnet 1.1.2.1, which is the very same version that I've been using for MANY years, to build MANY versions of syslog-ng, up through 3.0.5, and it has worked flawlessly. So why this is now going bonkers, with that same version, is beyond me?? The only other version of libnet that I've ever found was libnet 0.10.11, and I could never get that to compile on Solaris.

So... sorry for the whining. I've just put a lot of time and effort into trying to make this work, and feel like a dog chasing its tail. No matter what I "fix", or "upgrade", I just continue to find some "new thing" that seems to need to be changed, in order to try to make this work. If I had never previously built syslog-ng, I might understand that, but I have built many versions over the years, with no problems, and then it just seems to have "diverged" from a codebase that seems to be usable without a serious amount of augmentation to the stock Solaris components.

Anyway... again, any and all input appreciated. I "seem to be" closer to getting this compiled, than I have been for a very long time. It would really be nice to see this compile clean. THANKS, as always, for your help.

I understand the frustration. syslog-ng has changed a lot in 3.2 and 3.3 and where only a single binary was produced, now a set of .so-s and programs are created, not to mention threading, and TLS (=thread local storage) variables, which we compile out unless dedected. So building got a lot more difficult than in 3.0 times. This time, your libnet library is probably not built with -fPIC, which causes the linking to fail when trying to link it into libafsocket.so, which is now a shared object, whereas it used to be part of a monolithic executable. Believe me, Solaris is one of the easier UNIXes to get on with, when building relatively modern software. AIX is arcane beyond imagination (e.g. shared objects embedded in .a files), HP-UX is buggy when it comes to shared objects and relatively simple things like handling LD_LIBRARY_PATH or rpath properly. We've got dedicated staff to work with these UNIXes to keep syslog-ng in a compilable state. We generally use a customized version of gcc, binutils, etc. That's why I stopped providing OSE binaries: lots of work which I have no time for, I'm sometimes happy that I can tag & publish a release tarball. (two kids and a company to run) The PE team is doing it as that's one of the driving force behind PE sales, but it needs a top-notch guy who knows build tools and UNIXes quite well. -- Bazsi

On Tue, 2011-11-29 at 08:35 -0600, Marvin Nipper wrote:

So, I recompiled libnet, using -fPIC, and that seems to have moved me past the problems with the libnet components. (Thanks for that guidance.)

However, now I run into problems, apparently with the openssl components, at this point in the process:

libtool: link: gcc -std=gnu99 -shared -Wl,-z -Wl,text -Wl,-h -Wl,libafsocket-tls.so -o .libs/libafsocket-tls.so .libs/libafsocket_tls_la-afsocket.o .libs/libafsocket_tls_la-afunix.o .libs/libafsocket_tls_la-afinet.o .libs/libafsocket_tls_la-afsocket-grammar.o .libs/libafsocket_tls_la-afsocket-parser.o .libs/libafsocket_tls_la-afsocket-plugin.o -R/var/opt/packages/syslog-ng-3.3.3/lib/.libs -R/usr/local/lib -R/usr/local/lib/syslog-ng -L/var/opt/packages/syslog-ng-3.3.3/lib/.libs ../../lib/.libs/libsyslog-ng.so -L/usr/local/lib -L/var/opt/packages/syslog-ng-3.3.3/lib/ivykis/lib -L/var/opt/packages/syslog-ng-3.3.3/lib/ivykis/modules -L/var/opt/packages/syslog-ng-3.3.3/lib/ivykis/lib/.libs ../../lib/.libs/libsyslog-ng-crypto.so -L/usr/local/ssl/lib -lssl -lcrypto -ldl -lsocket -lnsl -lnet -lpthread -lc -pthread -pthread Text relocation remains referenced against symbol offset in file OPENSSL_cpuid_setup 0x1 /usr/local/ssl/lib/libcrypto.a(x86cpuid.o) CAST_S_table0 0x40 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table0 0x87 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table0 0xce /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table0 0x115 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table0 0x15c /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table0 0x1a3 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table0 0x1ea /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table0 0x231 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table0 0x278 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table0 0x2bf /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table0 0x306 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table0 0x34d /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table0 0x39d /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table0 0x3e4 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table0 0x42b /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table0 0x472 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table0 0x4f7 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table0 0x53e /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table0 0x585 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table0 0x5cc /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table0 0x613 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table0 0x65a /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table0 0x6a1 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table0 0x6e8 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table0 0x72f /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table0 0x776 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table0 0x7bd /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table0 0x804 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table0 0x84b /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table0 0x892 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table0 0x8d9 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table0 0x920 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table1 0x47 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table1 0x8e /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table1 0xd5 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table1 0x11c /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table1 0x163 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table1 0x1aa /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table1 0x1f1 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table1 0x238 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table1 0x27f /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table1 0x2c6 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table1 0x30d /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table1 0x354 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table1 0x3a4 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table1 0x3eb /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table1 0x432 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table1 0x479 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table1 0x4fe /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table1 0x545 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table1 0x58c /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table1 0x5d3 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table1 0x61a /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table1 0x661 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table1 0x6a8 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table1 0x6ef /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table1 0x736 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table1 0x77d /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table1 0x7c4 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table1 0x80b /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table1 0x852 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table1 0x899 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table1 0x8e0 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table1 0x927 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table2 0x50 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table2 0x97 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table2 0xde /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table2 0x125 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table2 0x16c /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table2 0x1b3 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table2 0x1fa /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table2 0x241 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table2 0x288 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table2 0x2cf /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table2 0x316 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table2 0x35d /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table2 0x3ad /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table2 0x3f4 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table2 0x43b /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table2 0x482 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table2 0x507 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table2 0x54e /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table2 0x595 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table2 0x5dc /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table2 0x623 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table2 0x66a /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table2 0x6b1 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table2 0x6f8 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table2 0x73f /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table2 0x786 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table2 0x7cd /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table2 0x814 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table2 0x85b /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table2 0x8a2 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table2 0x8e9 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table2 0x930 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table3 0x59 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table3 0xa0 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table3 0xe7 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table3 0x12e /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table3 0x175 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table3 0x1bc /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table3 0x203 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table3 0x24a /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table3 0x291 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table3 0x2d8 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table3 0x31f /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table3 0x366 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table3 0x3b6 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table3 0x3fd /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table3 0x444 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table3 0x48b /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table3 0x510 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table3 0x557 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table3 0x59e /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table3 0x5e5 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table3 0x62c /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table3 0x673 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table3 0x6ba /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table3 0x701 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table3 0x748 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table3 0x78f /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table3 0x7d6 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table3 0x81d /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table3 0x864 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table3 0x8ab /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table3 0x8f2 /usr/local/ssl/lib/libcrypto.a(cast-586.o) CAST_S_table3 0x939 /usr/local/ssl/lib/libcrypto.a(cast-586.o) ld: fatal: relocations remain against allocatable but non-writable sections collect2: ld returned 1 exit status gmake[4]: *** [libafsocket-tls.la] Error 1 gmake[4]: Leaving directory `/var/opt/packages/syslog-ng-3.3.3/modules/afsocket' gmake[3]: *** [all] Error 2 gmake[3]: Leaving directory `/var/opt/packages/syslog-ng-3.3.3/modules/afsocket' gmake[2]: *** [all-recursive] Error 1 gmake[2]: Leaving directory `/var/opt/packages/syslog-ng-3.3.3/modules' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/var/opt/packages/syslog-ng-3.3.3' gmake: *** [all] Error 2

Once again, these are openssl components that have worked for many years, with both BIND and syslog-ng (up through at least 3.0.5). And when I say that they have worked, I mean many different version of openssl, right up thru the current version that I'm using (openssl 1.0.0e), so this is again, super frustrating. (I.E. what is 3.3.3 doing, that now makes it unable to use these components?)

Again, openssl is a static library and syslog-ng tries to link it into a shared object. It either needs to be compiled with -fPIC or SSL disabled, like you did.

As can be seen from the directory structure, this is now being done with 3.3.3, and using this execution of configure:

LDFLAGS="-R/usr/local/lib" \ PKG_CONFIG=/usr/local/bin/pkg-config \ PKG_CONFIG_PATH="$PKG_CONFIG_PATH:/usr/local/lib/pkgconfig:/usr/local/ssl/lib/pkgconfig" \ ./configure --enable-spoof-source --enable-dynamic-linking --enable-tcp-wrapper=no

As I actually don't need SSL with my current syslog-ng configuration, I attempted to leave that out (--enable-ssl=no), but then it got unhappy while trying to compile afmongodb components, apparently unable to find an openssl header file:

gmake[7]: Entering directory `/var/opt/packages/syslog-ng-3.3.3/modules/afmongodb/libmongo-client/src' CC libmongo_client_la-compat.lo CC libmongo_client_la-bson.lo CC libmongo_client_la-mongo-wire.lo CC libmongo_client_la-mongo-client.lo CC libmongo_client_la-mongo-utils.lo CC libmongo_client_la-mongo-sync.lo CC libmongo_client_la-mongo-sync-cursor.lo CC libmongo_client_la-mongo-sync-pool.lo CC libmongo_client_la-sync-gridfs.lo CC libmongo_client_la-sync-gridfs-chunk.lo CC libmongo_client_la-sync-gridfs-stream.lo CCLD libmongo-client.la gmake[7]: Leaving directory `/var/opt/packages/syslog-ng-3.3.3/modules/afmongodb/libmongo-client/src' Making all in tests gmake[7]: Entering directory `/var/opt/packages/syslog-ng-3.3.3/modules/afmongodb/libmongo-client/tests' Making all in libtap gmake[8]: Entering directory `/var/opt/packages/syslog-ng-3.3.3/modules/afmongodb/libmongo-client/tests/libtap' CC libtap_la-tap.lo CC libtap_la-test.lo In file included from ../../src/libmongo-private.h:26, from test.h:8, from test.c:1: ../../src/compat.h:24:25: error: openssl/md5.h: No such file or directory test.c: In function 'test_bson_generate_full': test.c:39: warning: integer constant is too large for 'long' type test.c:40: warning: integer constant is too large for 'long' type gmake[8]: *** [libtap_la-test.lo] Error 1 gmake[8]: Leaving directory `/var/opt/packages/syslog-ng-3.3.3/modules/afmongodb/libmongo-client/tests/libtap' gmake[7]: *** [all-recursive] Error 1 gmake[7]: Leaving directory `/var/opt/packages/syslog-ng-3.3.3/modules/afmongodb/libmongo-client/tests' gmake[6]: *** [all-recursive] Error 1 gmake[6]: Leaving directory `/var/opt/packages/syslog-ng-3.3.3/modules/afmongodb/libmongo-client' gmake[5]: *** [all] Error 2 gmake[5]: Leaving directory `/var/opt/packages/syslog-ng-3.3.3/modules/afmongodb/libmongo-client' gmake[4]: *** [all-recursive] Error 1 gmake[4]: Leaving directory `/var/opt/packages/syslog-ng-3.3.3/modules/afmongodb' gmake[3]: *** [all] Error 2 gmake[3]: Leaving directory `/var/opt/packages/syslog-ng-3.3.3/modules/afmongodb' gmake[2]: *** [all-recursive] Error 1 gmake[2]: Leaving directory `/var/opt/packages/syslog-ng-3.3.3/modules' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/var/opt/packages/syslog-ng-3.3.3' gmake: *** [all] Error 2

This is a bug then, libmongo-client shouldn't have been built if disabled by configure. Until I find this, you can remove the "afmongodb" string from modules/Makefile so that it doesn't recurse there. -- Bazsi

See (long reply) below at [Marvin Nipper] tag. -----Original Message----- From: syslog-ng-bounces@lists.balabit.hu [mailto:syslog-ng-bounces@lists.balabit.hu] On Behalf Of Gergely Nagy Sent: Thursday, December 22, 2011 8:23 AM To: Syslog-ng users' and developers' mailing list Subject: Re: [syslog-ng] Solaris 10 support(?) in latest versions (e.g. 3.3.2) Balazs Scheidler <bazsi@balabit.hu> writes:

...

As can be seen from the directory structure, this is now being done with 3.3.3, and using this execution of configure:

LDFLAGS="-R/usr/local/lib" \ PKG_CONFIG=/usr/local/bin/pkg-config \ PKG_CONFIG_PATH="$PKG_CONFIG_PATH:/usr/local/lib/pkgconfig:/usr/local/ssl/lib/pkgconfig" \ ./configure --enable-spoof-source --enable-dynamic-linking --enable-tcp-wrapper=no

As I actually don't need SSL with my current syslog-ng configuration, I attempted to leave that out (--enable-ssl=no), but then it got unhappy while trying to compile afmongodb components, apparently unable to find an openssl header file:

Hrm, this is interesting. libmongo-client should fail at configure time if it figures out that it needs openssl, but it's not available. Perhaps it's some strange interaction with the parent configure - I'll investigate. Meanwhile, as Bazsi suggested, --disable-mongodb should help. (The other option is to upgrade your glib, so that libmongo-client won't try to fall back to using OpenSSL for md5 stuff). [Marvin Nipper] Welcome to "more fun with Solaris 10". Responding to the comment about using a newer version of GLIB, the last version of GLIB that I've been able to successfully compile on Solaris 10 was 2.14.6. E.G. when I try to compile something very recent, such as 2.28.8 in this example, using the native Solaris "make", I end up with this nonsense: make all-recursive Making all in . Making all in m4macros Making all in glib GEN glibconfig-stamp config.status: executing glib/glibconfig.h commands config.status: glib/glibconfig.h is unchanged dtrace -C -h -s -o glib_probes.h.tmp dtrace: failed to open -o: No such file or directory *** Error code 1 make: Fatal error: Command failed for target `glib_probes.h' Current working directory /var/opt/packages/glib-2.28.8/glib *** Error code 1 The following command caused the error: fail= failcom='exit 1'; \ for f in x $MAKEFLAGS; do \ case $f in \ *=* | --[!k]*);; \ *k*) failcom='fail=yes';; \ esac; \ done; \ And if I attempt to use gmake instead, it runs for awhile (longer than with "make"), and ends up with a completely different problem: CCLD libglib-2.0.la *** Warning: Linking the shared library libglib-2.0.la against the non-libtool *** objects glib_probes.o is not portable! CC gtester.o CCLD gtester Undefined first referenced symbol in file __dtrace_glib___slice(float, long double,...)(...) ./.libs/libglib-2.0.so __dtrace_glib___mem__alloc ./.libs/libglib-2.0.so __dtrace_glib___slice__alloc ./.libs/libglib-2.0.so __dtrace_glib___mem(float, long double,...)(...) ./.libs/libglib-2.0.so __dtrace_glib___mem__realloc ./.libs/libglib-2.0.so __dtrace_glib___quark__new ./.libs/libglib-2.0.so ld: fatal: symbol referencing errors. No output written to .libs/gtester collect2: ld returned 1 exit status And both of the above make problems occur, after running configure with either of the following: PKG_CONFIG=/usr/local/bin/pkg-config ./configure --enable-static PKG_CONFIG=/usr/local/bin/pkg-config ./configure NOW, obviously, I may simply be in the "don't know what the hell I'm doing" bucket (I FULLY admit that), and that is the cause of all of my problems and frustration. Admittedly, I had to "back my way into" my entire syslog-ng compilation process, years ago, when I first started with the earliest versions of the product, so and/all of the above GLIB compilation process may be flawed. All I know is that my previous scripting for the varied components, worked. GLIB (like syslog-ng) is just "one more thing" that I was building for a number of years, with no problems, and then suddenly, the release components changed, and everything went sideways. So, I continued to use the version that compiled cleanly, which now (per the comment above) seems to be problematic with respect to what syslog-ng would ideally like to see. Note, that the "Solaris fun" just continues from the above GLIB compilation failure. Having seen someone suggest (after remembering that "Google is your friend") that I can avoid the above problem by just eliminating dtrace, I added in "--disable-dtrace", to the GLIB configure process. Lo and behold, the thing cranked away for 10 minutes, compiling its heart out, and I thought FINALLY, I'll have a new version of GLIB, except that it eventually died at this point: CC socket.o CCLD socket ld: warning: file /var/opt/packages/glib-2.28.8/gobject/.libs/libgobject-2.0.so: linked to ../../gobject/.libs/libgobject-2.0.so: attempted multiple inclusion of file ld: warning: file /var/opt/packages/glib-2.28.8/gthread/.libs/libgthread-2.0.so: linked to ../../gthread/.libs/libgthread-2.0.so: attempted multiple inclusion of file ld: warning: file /var/opt/packages/glib-2.28.8/glib/.libs/libglib-2.0.so: linked to ../../glib/.libs/libglib-2.0.so: attempted multiple inclusion of file Undefined first referenced symbol in file socketpair socket.o (symbol belongs to implicit dependency /usr/lib/libsocket.so.1) socket socket.o (symbol belongs to implicit dependency /usr/lib/libsocket.so.1) ld: fatal: symbol referencing errors. No output written to .libs/socket collect2: ld returned 1 exit status *** Error code 1 The following command caused the error: echo " CCLD " socket;/bin/bash ../../libtool --silent --tag=CC --mode=link gcc -g -O2 -Wall -o socket socket.o ../../glib/libglib-2.0.la ../../gthread/libgthread-2.0.la ../../gobject/libgobject-2.0.la ../../gio/libgio-2.0.la make: Fatal error: Command failed for target `socket' And, in typical nightmare fashion, in Googling this, I find that this problem was reported as (... wait for it....) a "Solaris specific issue", all the way back in GLIB 2.24.1, but was supposed to have been fixed with a patch that was committed in August of 2010, which obviously begs the question, if that was fixed so long ago, why did the problem still exist in the 2.28 source. So... going further down the rabbit hole, just today (while writing this response), I grabbed the very latest 2.30.2 GLIB source, and tried to compile that. Of course it instantly complained (during configure) that I had on instance of libffi, so I located and downloaded that. The libffi configure ran cleanly, and even correctly identified my x86 Solaris system, but the attempt to run make (or gmake) resulted in a failure, when it attempted to "make everything" (i.e. all-all), but actually "made nothing at all". So, I had to manually leap into the i386-pc-solaris2.10 subdirectory, and run the make (and install) myself. (No doubt, this is yet another package with some goofy incompatibility with Solaris.) So... with the newly compiled libffi, GLIB 2.30.2 configures properly, and seems like it's going to compile just fine. It cleanly compiles for a considerable time, and then comes to this point in the process: Making all in gio make all-recursive Making all in gdbus-2.0/codegen GEN gdbus-codegen At that point, it all comes to a screeching halt (literally). The CPU idles out on the system, and it never goes beyond that point. (Tried multiple times, always hangs at the same point.) So, obviously the latest "stable" version of GLIB won't even compile on Solaris (and it doesn't even fail in a manner making it possible to research some specific error). So what the heck, I figured I'd try the latest development release, 2.31.6, but that doesn't even make it past the configure, because it complains (with some new test, specific to 2.31) about the architecture of my system (even though this is a high-end box, about a year old). It does with this nonsense: checking for lock-free atomic intrinsics... no configure: error: GLib must be build with -march=i486 or later So, in desperation, I jumped into the GLIB 2.29 territory (even though I'm unclear as to whether any 2.29 version was ever considered "stable". Certainly, the 2.29.92 version (as well as other mid-to-late 2.29 versions) simply hang up in exactly the same place as the 2.30.2 version (i.e. on the " GEN gdbus-codegen" line), and as with the 2.30 versions, you eventually just have to Ctrl+c the make process. In trying the very first version of 2.29, it errors out in the compilation of gatomic, which is a problem that I've seen in GLIB versions for a number of years, and which I am assuming to be another platform-specific problem, because it appears to have (finally) been fixed somewhere ABOVE the 2.29.2 version. Bottom line... I didn't try all of the 2.29 versions, hoping to stumble into something that works, but you get the general idea of how exciting this is, trying to find a GLIB version that will ever successfully get to the end of the make process. So. FINALLY (if you've made it this far?), what is the lesson of all of this craziness? Well... It would be REALLY (REALLY) helpful, if you guys could share version and configuration specifics, for your build out process on a given platform (e.g. in this case Solaris 10 x86). I mean, just as a very basic example: saying that syslog-ng "uses GLIB", or even (as in the email to which I'm replying) that I should be using a "newer version" of GLIB, is very nondescript. There are a bazillion versions of GLIB, and they vary drastically in terms of the nature of the underlying code, and even in (as with the libffi situation, in 2.30) their prerequisite components. And also, knowing, for a given platform, what command line (i.e. configuration) options were actually used in YOUR successful compilation of syslog-ng, and all of its prerequisite components, would also be useful. And has been discussed in earlier threads, modifications that you've made to the stock installation environment (e.g. I upgraded to gcc 4.4.2 due to previous discussions, but it begs questions about whether you are using stock a Solaris linker, the GNU linker, and/or varieties of other non-Solaris components in order to somehow be successful in producing a working Solaris 10 x86 syslog-ng version). Certainly, after many (many, many) man-hours of beating my head against the wall (still with no success for this new version), I can only describe this as nothing less than a "very black art" (of the darkest kind). In the end, I will attempt to manually modify the syslog-ng Makefile, to eliminate the afmongodb component, and see if I can get syslog-ng to compile/link with the older GLIB components. I never got to that today, because of all of the time I spent on the efforts depicted above. Obviously, my longer-term concern with all of this, is that even if I manage to get a working 3.3.x component (by hacking the config process), I'm still going to feel like I'm only managing to get to working by using a lot of paper clips and tape. Thanks (if you did get this far) for bothering to listen to all of this. As always, any/all input appreciated.

This is a bug then, libmongo-client shouldn't have been built if disabled by configure.

Until I find this, you can remove the "afmongodb" string from modules/Makefile so that it doesn't recurse there.

libmongo-client is not disabled, I think. OpenSSL is, but libmongo-client will try to detect OpenSSL if the installed glib version is too old. But when running with --disable-ssl, that might not happen, and things get screwed up. At least, that is my suspicion at the moment, without testing it.. -- |8] ______________________________________________________________________________ Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: http://www.balabit.com/wiki/syslog-ng-faq This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.