[Nagiosplug-devel] Solaris problems

[sean finney]

hey ton,

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.

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.

> To be fair, I've downloaded top, curl and wget and they all have the
> same issue. The solution could just be a README.solaris.

bob mentioned crle, which is probably what you want to mess around with
as an analog to ld.so.conf.  i haven't had to do this in a while, so i'd
defer to the fine manual for the specifics.

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


	sean
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <https://www.monitoring-plugins.org/archive/devel/attachments/20061207/d40954dd/attachment.sig>