(from cvs) sensors binary compile probs on rh8

Mark D. Studebaker mds at paradyne.com
Thu Dec 19 04:46:18 CET 2002


my man page for ld.so clearly says that /usr/lib and /lib are last.
You can also see this from the output of 'ldconfig -v'.

Is yours different?

Also note that the email we got a few days ago from the user,
he was picking up the library in /usr/local/lib...
so I'm really confused now...

Philip Edelbrock wrote:
> 
> (I can't remember if I've replied to this yet)
> 
> I didn't have to add /usr/local/lib to it (I've added it a long time
> ago), but it looks in /usr/lib first.  In fact, I think /lib and
> /usr/lib are built into the lib search path and don't need to be in
> ld.so.conf?
> 
> I wonder if we can add a checking function in the include header to test
> for the lib version (and call it when sensors is run).  The header
> version and the lib version should always be indentical, right?
> 
> Phil
> 
> Mark Studebaker wrote:
> 
> >> 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.
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >>
> >



More information about the lm-sensors mailing list