<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; ">Hi Sean,<DIV><BR><DIV><DIV>On 7 Dec 2006, at 22:47, sean finney wrote:</DIV><BR class="Apple-interchange-newline"><BLOCKQUOTE type="cite"><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">On Thu, 2006-12-07 at 17:34 +0000, Ton Voon wrote:</DIV> <BLOCKQUOTE type="cite"><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">1. Linking to ssl libraries.<SPAN class="Apple-converted-space"> </SPAN></DIV> </BLOCKQUOTE><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV> <BLOCKQUOTE type="cite"><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">On Solaris, the predominate openssl installation is via the</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">SunFreeware version which is installed in /usr/local/ssl. When</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">compiling applications against this library, it is not sufficient to</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">set LDFLAG =-L/usr/local/ssl/lib, you have to also set</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">-R/usr/local/ssl/lib in order for the SSL plugins (check_http,</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">check_smtp) to find the openssl directories. I had made a patch for</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">this in configure.in, but Sean removed it, probably rightly (revision</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">1.191 at</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><A href="http://nagiosplug.cvs.sourceforge.net/nagiosplug/nagiosplug/configure.in?view=log">http://nagiosplug.cvs.sourceforge.net/nagiosplug/nagiosplug/configure.in?view=log</A>).</DIV> </BLOCKQUOTE><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">do you still have problems even if you pass --enable-rpath</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">to ./configure? <SPAN class="Apple-converted-space"> </SPAN></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">this problem manifests itself whenever an executable is linked</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">against libraries that exist outside of the default search path, which</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">to the OS is the same as the libraries not existing at all.<SPAN class="Apple-converted-space">  </SPAN>when you</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">compile with -Rfoo, you're explicitly adding directories to be searched</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">when executing a program (stored in the private section of the ELF,</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">try objdump -p check_foo | grep RPATH).</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">from a linux/unix distribution point of view, setting this is generally</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">a bad thing because it leads to inconsistant/non-standard behaviour</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">when run-time linking an object before execution.<SPAN class="Apple-converted-space">  </SPAN>typically the "Right</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Way" to handle this (for distros and admins too), is to add these</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">directories to the default library search path so that they're generally</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">available to all programs that might need them.</DIV></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV>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?</DIV><DIV><BR><BLOCKQUOTE type="cite"><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">there are cases where rpath is a Good Thing, or is at least justifiable,</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">but usually those are cases where "you know what you're doing".<SPAN class="Apple-converted-space">  </SPAN>for</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">example, private libraries that *shouldn't* be shared or would otherwise</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">conflict with standard ones (different versions of libraries with</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">unversioned symbols, is one case)</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV> <BLOCKQUOTE type="cite"><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">However, this means that the plugins will not necessarily run after</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">being compiled. My current workaround is to set</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">LD_RUN_PATH=/usr/local/ssl/lib before compiling. Is there a better</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">way?</DIV> </BLOCKQUOTE><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">if --enable-rpath isn't doing it, something's wrong with our ./configure</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">script.</DIV></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV>--enable-rpath doesn't help. I think this is on by default.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>But...</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>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:</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>checking how to link with libssl... /usr/local/ssl/lib/libssl.so /usr/local/ssl/lib/libcrypto.so -R/usr/local/ssl/lib</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>So it manages to know that -R is required. When run with --disable-rpath as well, the -R is removed.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>(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: <A href="http://thread.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/1610/focus=1610">http://thread.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/1610/focus=1610</A>)</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>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).</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>So, should we switch to using that? Downside is that the configure options will have to change. wget have it defined as:</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>(no SSL flags)     - autodetect SSL lib, OK if none found</DIV><DIV>--with-ssl         - autodetect SSL lib, abort if none found</DIV><DIV>--with-ssl=openssl - use OpenSSL, abort if not found</DIV><DIV>--with-ssl=gnutls  - use GnuTLS, abort if not found</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>(from <A href="http://www.mail-archive.com/wget@sunsite.dk/msg08130.html">http://www.mail-archive.com/wget@sunsite.dk/msg08130.html</A>)</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>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)?</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>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.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><BLOCKQUOTE type="cite"><BLOCKQUOTE type="cite"><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">2. pst3 not working on 64 bit systems</DIV> </BLOCKQUOTE><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV> <BLOCKQUOTE type="cite"><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">I have to admit ignorance here. On my Solaris 9 server, the plugins</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">compile in 32 bit mode. However, pst3 also compiles in 32 bit and then</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">there are errors because the /dev/ksyms holds 64 bit information. What</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">can be done? Should configure work out if the system is 64 bit and</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">compile just pst3 in 64 bit? Or should configure fallback onto using</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">ps?</DIV> </BLOCKQUOTE><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">okay, again it's been a while, but iirc even "32-bit" solaris still runs</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">a 64-bit kernel (just 32-bit userland, right?).<SPAN class="Apple-converted-space">  </SPAN>if that's the case we</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">need to differentiate between building a 32/64 bit program from building</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">a program that reads 32/64-bit data objects from kernel memory.<SPAN class="Apple-converted-space">  </SPAN>even if</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">that's not the case, we still have to do that, only it's a bit harder</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">because we'll have to determine at run time the kernel type.</DIV></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>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.</DIV><BR></DIV>Ton</DIV><DIV><SPAN class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><SPAN class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><SPAN class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><SPAN class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><SPAN class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><SPAN class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><DIV><BR class="khtml-block-placeholder"></DIV><DIV><A href="http://www.altinity.com">http://www.altinity.com</A></DIV><DIV>T: +44 (0)870 787 9243</DIV><DIV>F: +44 (0)845 280 1725</DIV><DIV>Skype: tonvoon</DIV></SPAN></SPAN></SPAN></SPAN></SPAN><BR class="Apple-interchange-newline"></SPAN> </DIV><BR></BODY></HTML>