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 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. -----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) 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 ______________________________________________________________________________ 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.