(from cvs) sensors binary compile probs on rh8

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Ah, I found the trouble. I've got too many libsensors installed, and 
when sensors is compiled, it will link against an old one. At some 
point, we changed the default lib installation directory from /usr/lib 
to /usr/local/lib. Bins get linked against /usr/lib/libsensors.so 
instead of the newer /usr/local/libsensors.so.

So, in essence, a newer include for the lib is used to link against an 
old lib.

Once I deleted the old libs from /usr/lib and got it linking to the new 
lib, it worked fine.

Should we have a check for an old lib? Or explicitly link against 
libsensors.1.4.0.so (if this is possible?).


Phil


Mark Studebaker wrote:

> guess you saw the mail that it's a libc 2.3 thing...
> Can you recompile w/ -g (sensors and libsensors) and get a better bt?
> could be something I did to libsensors...
>
> Philip Edelbrock wrote:
>
>> :'(
>>
>> [phil at drtheopolis phil]$ sensors -v
>> sensors version 2.7.0
>>
>> [phil at drtheopolis phil]$ sensors
>> Segmentation fault (core dumped)
>>
>> [phil at drtheopolis phil]$ gdb sensors
>> GNU gdb Red Hat Linux (5.2.1-4)
>> Copyright 2002 Free Software Foundation, Inc.
>> GDB is free software, covered by the GNU General Public License, and 
>> you are
>> welcome to change it and/or distribute copies of it under certain 
>> conditions.
>> Type "show copying" to see the conditions.
>> There is absolutely no warranty for GDB. Type "show warranty" for 
>> details.
>> This GDB was configured as "i386-redhat-linux"...
>> (gdb) run
>> Starting program: /usr/local/bin/sensors
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x4207931a in strcmp () from /lib/i686/libc.so.6
>> (gdb) bt
>> #0 0x4207931a in strcmp () from /lib/i686/libc.so.6
>> #1 0x40028bd9 in sensors_match_chip () from /usr/lib/libsensors.so.1
>> #2 0x08049171 in do_the_real_work ()
>> #3 0x08049073 in main ()
>> #4 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6
>>
>>
>> It's possible that it's just my strange computer. This isn't a RH8 
>> install from scratch, but an upgrade. There could be a legacy lib or 
>> something causing trouble which may not appear on another Athlon 
>> running RH8.... has anybody else tried on an Athlon?
>>
>>
>> Phil
>>
>>
>> Mark Studebaker wrote:
>>
>>> Phil, what processor are you compiling for? Or what's wrong with 
>>> <math.h>?
>>> It works for me, but gcc is generating floating point assembler 
>>> instructions
>>> and so it doesn't need -lm.
>>> If we do add a -lm it should be added to lib/Module.mk for the library,
>>> not in prog/sensors/Module.mk for sensors.
>>>
>>>
>>> Jean Delvare wrote:
>>>
>>>>> FYI-
>>>>>
>>>>> gcc -o prog/sensors/sensors prog/sensors/main.ro 
>>>>> prog/sensors/chips.ro
>>>>> -Llib -lsensors
>>>>> lib/libsensors.so: undefined reference to `log'
>>>>> lib/libsensors.so: undefined reference to `exp'
>>>>> collect2: ld returned 1 exit stat
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Looks like we need an extra "-lm" on the command line.
>>>>
>>>
>>>
>>
>
>



[Index of Archives]     [Linux Kernel]     [Linux Hardware Monitoring]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux