[Nagiosplug-help] Problems with check_procs/pst3 on Solaris

[Michael Beachler]

Thank you for your quick response.  I'm surprised that I overlooked the 
-m64 on the first gcc line and included it on the second but thank you 
for pointing out my mistake.

It worked like a champ.

Thanks,

-Michael Beachler-

Andreas Ericsson wrote:
> Michael Beachler wrote:
>> Hello,
>>
>> I am currently having problems getting check_procs/pst3 to work 
>> properly on both Solaris 7 and Solaris 8 boxes.
>>
>> It appears that my box is running in 64-bit mode:
>>
>> isainfo -v
>> 64-bit sparcv9 applications
>> 32-bit sparc applications
>>
>> Here is the error that I receive:
>>
>> check_procs -vvvv
>> CMD: /opt/bcs/packages/nagios-2.3.1/libexec/pst3
>> CRITICAL - Plugin timed out after 10 seconds
>>
>> /opt/bcs/packages/nagios-2.3.1/libexec/pst3
>> /opt/bcs/packages/nagios-2.3.1/libexec/pst3: /dev/ksyms is not a 
>> 32-bit kernel namelist
>> pst3: Failed to open kernel memory: Error 0
>>
>> Thinking that this was a 32-bit vs. 64-bit problem I decided to play 
>> around with pst3 a bit.  I downloaded the latest nagios-plugins-HEAD 
>> tarball.  I located the pst3.c file within the plugins-root dir and 
>> tried to compile it manually.
>>
>> I am able to build the file manually by doing the following:
>>
>> gcc -DLOCALEDIR=\"/usr/local/nagios/share/locale\" -DHAVE_CONFIG_H -I. 
>> -I. -I.. -I.. -I../lib -I../intl -I../plugins -I/usr/lib 
>> -I/usr/local/include  -I/usr/local/include  -g -O2 -c pst3.c
>>
>> gcc -o pst3 pst3.o /usr/lib/libkvm.so.1
>>
>> Now I have a pst3 executable and I can reproduce the error listed 
>> earlier:
>>
>> bash-3.00# ./pst3
>> ./pst3: /dev/ksyms is not a 32-bit kernel namelist
>> pst3: Failed to open kernel memory: Error 0
>>
>> I attempted to build a 64 bit executable via the following command:
>>
>> gcc -m64 -o pst3 pst3.o /usr/lib/libkvm.so.1
>>
>> I get this error:
>>
>> /usr/lib/libkvm.so.1: could not read symbols: File in wrong format
>> collect2: ld returned 1 exit status
>>
>> I "think" the reason I get this error is due to the shared object file 
>> being a 32 bit file:
>>
>> /usr/lib/libkvm.so.1:   ELF 32-bit MSB dynamic lib SPARC Version 1, 
>> dynamically linked, not stripped
>>
>> I found a 64 bit shared object for libkvm located in /usr/lib/sparcv9:
>>
>> /usr/lib/sparcv9/libkvm.so:     ELF 64-bit MSB dynamic lib SPARCV9 
>> Version 1, dynamically linked, not stripped
>>
>> When I try to compile pst3 with the 64 bit shared object using this 
>> command:
>>
>> gcc -m64 -o pst3 pst3.o /usr/lib/sparcv9/libkvm.so.1
>>
>> I now get this error:
>>
>> /opt/bcs/bin/ld: warning: sparc architecture of input file `pst3.o' is 
>> incompatible with sparc:v9 output
>> pst3.o:(.debug_aranges+0x10): relocation truncated to fit: 
>> R_SPARC_UA32 against `.text'
>> pst3.o:(.debug_info+0x10): relocation truncated to fit: R_SPARC_UA32 
>> against `.text'
>> pst3.o:(.debug_info+0x14): relocation truncated to fit: R_SPARC_UA32 
>> against `.text'
>> pst3.o:(.debug_info+0x280e): relocation truncated to fit: R_SPARC_UA32 
>> against `.text'
>> pst3.o:(.debug_info+0x2812): relocation truncated to fit: R_SPARC_UA32 
>> against `.text'
>> pst3.o:(.debug_info+0x2862): relocation truncated to fit: R_SPARC_UA32 
>> against `.text'
>> pst3.o:(.debug_info+0x2866): relocation truncated to fit: R_SPARC_UA32 
>> against `.text'
>> pst3.o:(.debug_info+0x28a0): relocation truncated to fit: R_SPARC_UA32 
>> against `.text'
>> pst3.o:(.debug_info+0x28a4): relocation truncated to fit: R_SPARC_UA32 
>> against `.text'
>> pst3.o:(.debug_info+0x28b3): relocation truncated to fit: R_SPARC_UA32 
>> against `.text'
>> pst3.o:(.debug_info+0x28b7): additional relocation overflows omitted 
>> from the output
>> collect2: ld returned 1 exit status
>>
>> I don't have a whole lot of experience mucking with source code.  I 
>> did notice however at the top of the pst3.c file that the author has 
>> tested this in both 32-bit and 64-bit versions.
>>
>> Anyone have any thoughts, suggestions, and/or ideas?
>>
> 
> Compiling is the act of transforming human-readable source-code to a 
> binary object-code format. Linking is the act of coupling that 
> object-code with the library functions it needs to make a complete 
> executable of it. Might seem like nit-picking, but in this case the 
> distinction is important.
> 
> You need to first *compile* the file in 64-bit mode, then *link* it in 
> the same mode as you compiled it. Otherwise it will have all the wrong 
> sizes of certain items (such as stack-pointers, variables, function 
> pointers, data structures, ...) as can be seen by the output.
> 
> In short, the solution is to add -m64 to the string you pass to gcc when 
> running it on the .c-file as well as when running it on the .o-file.
> 
> Totally untested, but should work gallantly.
>