[Nagiosplug-devel] Solaris problems

[sean finney]

On Fri, 2006-12-08 at 00:34 +0000, Ton Voon wrote:

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

okay, sounds reasonable.

> 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 fine with this as an alternative.  i'm fairly ambivalent on the
matter as long as there's a way for me to continue keeping rpath out.  i
guess it's the people on solaris who care a little more :)

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

and i'm instantly much more in favor of it :) 


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

okay.  this all  goes with a disclaimer that my memory on what solaris
actually does is a bit hazy.  but, the general problem and concepts
are still the same in any event.

- pst3 is reading stuff in kernel memory, so many datatypes therein will
  have different sizes based on whether the kernel is 32-bit or 64-bit
  (pointers, offsets, etc).
- the userland can be 32-bit or 64-bit, so we need to be careful about
  the size of datatypes used to store values (use off_t/size_t not int, 
  etc).
- there *might* not be a direct correlation between the running
  kernel and the type of userland (64 bit kernel, 32 bit userland),
  and the running kernel can only be detected at runtime.  in that
  case things are even more complicated since using off_t/size_t
  and the like will definitely not work.


	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/20061208/81f6508f/attachment.sig>