>From reading 'man ld.so' and 'man ldconfig', it's apparent that /usr/lib and /lib are searched _after_ all the libraries listed in /etc/ld.so.conf. So the only problem is if /usr/local/lib is not listed in /etc/ld.so.conf at all. Did you have /usr/local/lib/ in /etc/ld.so.conf or did you have to add it? If Redhat doesn't have /usr/local/lib in there, I think that's the check we need to have. Philip Edelbrock wrote: > > 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. >>>>> >>>> >>>> >>> >> >> >
