[Nagiosplug-devel] Solaris problems

[Ton Voon]

Hi Sean,

On 7 Dec 2006, at 22:47, sean finney wrote:

>
> On Thu, 2006-12-07 at 17:34 +0000, Ton Voon wrote:
>> 1. Linking to ssl libraries.
>
>> On Solaris, the predominate openssl installation is via the
>> SunFreeware version which is installed in /usr/local/ssl. When
>> compiling applications against this library, it is not sufficient to
>> set LDFLAG =-L/usr/local/ssl/lib, you have to also set
>> -R/usr/local/ssl/lib in order for the SSL plugins (check_http,
>> check_smtp) to find the openssl directories. I had made a patch for
>> this in configure.in, but Sean removed it, probably rightly (revision
>> 1.191 at
>> http://nagiosplug.cvs.sourceforge.net/nagiosplug/nagiosplug/ 
>> configure.in?view=log).
>
> do you still have problems even if you pass --enable-rpath
> to ./configure?
>
> this problem manifests itself whenever an executable is linked
> against libraries that exist outside of the default search path, which
> to the OS is the same as the libraries not existing at all.  when you
> compile with -Rfoo, you're explicitly adding directories to be  
> searched
> when executing a program (stored in the private section of the ELF,
> try objdump -p check_foo | grep RPATH).
>
> from a linux/unix distribution point of view, setting this is  
> generally
> a bad thing because it leads to inconsistant/non-standard behaviour
> when run-time linking an object before execution.  typically the  
> "Right
> Way" to handle this (for distros and admins too), is to add these
> directories to the default library search path so that they're  
> generally
> available to all programs that might need them.

Thanks for the explanation. Maybe we should raise a bug with  
SunFreeware that openssl should be installed and then added to the  
default library search path system-wide?

> there are cases where rpath is a Good Thing, or is at least  
> justifiable,
> but usually those are cases where "you know what you're doing".  for
> example, private libraries that *shouldn't* be shared or would  
> otherwise
> conflict with standard ones (different versions of libraries with
> unversioned symbols, is one case)
>
>
>> However, this means that the plugins will not necessarily run after
>> being compiled. My current workaround is to set
>> LD_RUN_PATH=/usr/local/ssl/lib before compiling. Is there a better
>> way?
>
> if --enable-rpath isn't doing it, something's wrong with our ./ 
> configure
> script.

--enable-rpath doesn't help. I think this is on by default.

But...

I've been looking at wget's configure.in script and they use a macro  
called AC_LIB_HAVE_LINKFLAGS. This is defined in the lib-link.m4  
macro which we distribute (originally from gettext). Running ./ 
configure on my Sol9 server, it doesn't detect openssl (because of  
the default search paths). However, if I define --with-libssl-prefix=/ 
usr/local/ssl, then it does see the openssl and also comes up with  
this lovely line:

checking how to link with libssl... /usr/local/ssl/lib/libssl.so /usr/ 
local/ssl/lib/libcrypto.so -R/usr/local/ssl/lib

So it manages to know that -R is required. When run with --disable- 
rpath as well, the -R is removed.

(There's some interesting comments in this thread where the opencdk  
project was adding pkg-config support, but was moving to  
AC_LIB_HAVE_LINKFLAGS instead: http://thread.gmane.org/ 
gmane.comp.encryption.gpg.gnutls.devel/1610/focus=1610)

wget also has support for gnutls as well (which you'll be pleased  
about!). AND they don't use libtool - so we could take all the  
libtool code out (there is a dependency on config.rpath, but that's a  
single file rather than libtool's huge list).

So, should we switch to using that? Downside is that the configure  
options will have to change. wget have it defined as:

(no SSL flags)     - autodetect SSL lib, OK if none found
--with-ssl         - autodetect SSL lib, abort if none found
--with-ssl=openssl - use OpenSSL, abort if not found
--with-ssl=gnutls  - use GnuTLS, abort if not found

(from http://www.mail-archive.com/wget@sunsite.dk/msg08130.html)

You define the directory using --with-libssl-prefix=/usr/local/ssl.  
We would lose our autodetection of SSL directories, but I guess that  
is a good way to go for package maintainers (define exactly which ssl  
implementations to use)?

I'm happy to do the work (we lose lots of libtool files & lots of  
code gets removed from configure.in - whoopie!) if there's a  
consensus on this.

>> 2. pst3 not working on 64 bit systems
>
>> I have to admit ignorance here. On my Solaris 9 server, the plugins
>> compile in 32 bit mode. However, pst3 also compiles in 32 bit and  
>> then
>> there are errors because the /dev/ksyms holds 64 bit information.  
>> What
>> can be done? Should configure work out if the system is 64 bit and
>> compile just pst3 in 64 bit? Or should configure fallback onto using
>> ps?
>
> okay, again it's been a while, but iirc even "32-bit" solaris still  
> runs
> a 64-bit kernel (just 32-bit userland, right?).  if that's the case we
> need to differentiate between building a 32/64 bit program from  
> building
> a program that reads 32/64-bit data objects from kernel memory.   
> even if
> that's not the case, we still have to do that, only it's a bit harder
> because we'll have to determine at run time the kernel type.

Here's the ignorance bit - I don't know what you're talking about at  
all. I'll probably need to see some example code to understand what  
this work entails.

Ton

http://www.altinity.com
T: +44 (0)870 787 9243
F: +44 (0)845 280 1725
Skype: tonvoon


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nagios-plugins.org/archive/devel/attachments/20061208/9ffa0e6a/attachment.html>