[syslog-ng] Solaris 10 support(?) in latest versions (e.g. 3.3.2)
Marvin Nipper
Marvin.Nipper at stream.com
Thu Dec 22 22:17:09 CET 2011
See (long reply) below at [Marvin Nipper] tag.
-----Original Message-----
From: syslog-ng-bounces at lists.balabit.hu [mailto:syslog-ng-bounces at 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 at 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.
More information about the syslog-ng
mailing list