fails to link

[jalla2000]

$ make mkdir -p build cd build && cmake .. -- The C compiler identification is GNU -- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Configuring done -- Generating done -- Build files have been written to: /home/jalla/src/TEMPered/build

Next actions: cd build ; if necessary, reconfigure CMake ; run make

$ cd build/ $ make Scanning dependencies of target tempered-shared [ 11%] Building C object libtempered/CMakeFiles/tempered-shared.dir/core.c.o [ 22%] Building C object libtempered/CMakeFiles/tempered-shared.dir/temper_type.c.o [ 33%] Building C object libtempered/CMakeFiles/tempered-shared.dir/type_hid/common.c.o [ 44%] Building C object libtempered/CMakeFiles/tempered-shared.dir/type_hid/sht1x.c.o [ 55%] Building C object libtempered/CMakeFiles/tempered-shared.dir/type_hid/fm75.c.o [ 66%] Building C object libtempered/CMakeFiles/tempered-shared.dir/type_hid/ntc.c.o /home/jalla/src/TEMPered/libtempered/type_hid/ntc.c: In function ‘tempered_type_hid_read_sensor_group_ntc’: /home/jalla/src/TEMPered/libtempered/type_hid/ntc.c:8:66: warning: unused parameter ‘group’ [-Wunused-parameter] /home/jalla/src/TEMPered/libtempered/type_hid/ntc.c:9:41: warning: unused parameter ‘group_data’ [-Wunused-parameter] /home/jalla/src/TEMPered/libtempered/type_hid/ntc.c: In function ‘tempered_type_hid_get_temperature_ntc’: /home/jalla/src/TEMPered/libtempered/type_hid/ntc.c:20:60: warning: unused parameter ‘tempC’ [-Wunused-parameter] Linking C shared library libtempered.so [ 66%] Built target tempered-shared Scanning dependencies of target enumerate [ 77%] Building C object utils/CMakeFiles/enumerate.dir/enumerate.c.o Linking C executable enumerate /home/jalla/src/hidapi/linux/libhidapi-hidraw.so: undefined reference to udev_new' /home/jalla/src/hidapi/linux/libhidapi-hidraw.so: undefined reference toudev_enumerate_scan_devices' /home/jalla/src/hidapi/linux/libhidapi-hidraw.so: undefined reference to udev_unref' /home/jalla/src/hidapi/linux/libhidapi-hidraw.so: undefined reference toudev_device_get_parent_with_subsystem_devtype' /home/jalla/src/hidapi/linux/libhidapi-hidraw.so: undefined reference to udev_enumerate_new' /home/jalla/src/hidapi/linux/libhidapi-hidraw.so: undefined reference toudev_enumerate_add_match_subsystem' /home/jalla/src/hidapi/linux/libhidapi-hidraw.so: undefined reference to udev_list_entry_get_next' /home/jalla/src/hidapi/linux/libhidapi-hidraw.so: undefined reference toudev_device_new_from_syspath' /home/jalla/src/hidapi/linux/libhidapi-hidraw.so: undefined reference to udev_enumerate_get_list_entry' /home/jalla/src/hidapi/linux/libhidapi-hidraw.so: undefined reference toudev_device_unref' /home/jalla/src/hidapi/linux/libhidapi-hidraw.so: undefined reference to udev_enumerate_unref' /home/jalla/src/hidapi/linux/libhidapi-hidraw.so: undefined reference toudev_device_new_from_devnum' /home/jalla/src/hidapi/linux/libhidapi-hidraw.so: undefined reference to udev_device_get_sysattr_value' /home/jalla/src/hidapi/linux/libhidapi-hidraw.so: undefined reference toudev_list_entry_get_name' /home/jalla/src/hidapi/linux/libhidapi-hidraw.so: undefined reference to `udev_device_get_devnode' collect2: ld returned 1 exit status make[2]: * [utils/enumerate] Error 1 make[1]: * [utils/CMakeFiles/enumerate.dir/all] Error 2 make: *\ [all] Error 2

[edorfaus]

This looks as if you don't have the -dev package for the udev library installed - but it's a bit odd, because if that was the case, it should have failed when you were building hidapi, and not have waited until you were building tempered.

Can you check if all the relevant udev packages are installed on your system?

If that doesn't help, you could try to build tempered against the libusb implementation of hidapi (it's been moved from the linux subdir to the libusb subdir in the current hidapi master). Once you've built that, you could either tell cmake to use it explicitly by reconfiguring it, or simply remove the built hidraw version and start the tempered build from scratch, as it should then find it automatically.

[jalla2000]

hmmm... aptitude says i have the following installed. I clearly have libudev-dev....

i libgudev-1.0-0 - GObject-based wrapper library for libudev
i A libgudev-1.0-0:i386 - GObject-based wrapper library for libudev
p libgudev-1.0-dev - GObject-based wrapper library for libudev -- development files
p libgudev-1.0-dev:i386 - GObject-based wrapper library for libudev -- development files
p libgudev1.0-cil - GObject-based wrapper library for libudev -- CLI bindings
p libgudev1.0-cil-dev - GObject-based wrapper library for libudev -- CLI development files
i libudev-dev - udev library (development files)
p libudev-dev:i386 - udev library (development files)
i libudev0 - udev library
i A libudev0:i386 - udev library
p ludevit - converter from standard Slovak into the L. Štúr version
p monodoc-gudev-manual - compiled XML documentation for gudev-sharp
i udev - rule-based device node and kernel event manager
p udev:i386 - rule-based device node and kernel event manager
p uudeview - Smart multi-file multi-part decoder (command line)
p uudeview:i386 - Smart multi-file multi-part decoder (command line)

[edorfaus]

Can you run ldd on the libhidapi-hidraw.so file? And, what version of udev do you have? (I have version 175-3.1)

[edorfaus]

Hmm, searching online shows quite a few other people with the same problem, for other programs - though they usually say it is caused by replacing udev with systemd-tools (which now includes udev, since udev and systemd apparently have merged upstream, with a new version of udev), and are talking about Arch Linux.

I'm not so sure that that's the problem here, since you appear to have libudev0 installed (and on an apt-based system), but I suppose we could try similar solutions to see if it helps.

A workaround some people have mentioned is to make a libudev.so.0 symlink that points to the new version of libudev.so.* - but as others responded, that's fragile and can cause problems later, even if it works now.

They keep saying that the correct fix is to recompile the program that has the problem - which I believe is technically hidapi in this case, since that's what directly uses udev - so if you could try to rebuild first hidapi and then tempered, just to see if it helps, that would be nice.

[jalla2000]

$ ldd libhidapi-hidraw.so linux-vdso.so.1 => (0x00007fffdc5ff000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f0b890db000) /lib64/ld-linux-x86-64.so.2 (0x00007f0b896b9000)

I'll see what I can find out when I have time.

[edorfaus]

Hmm, OK, that's the problem then - that list is supposed to include a link to udev, like this list from my system:

$ ldd libhidapi-hidraw.so
    linux-gate.so.1 =>  (0xb771c000)
    libudev.so.0 => /lib/i386-linux-gnu/libudev.so.0 (0xb76ec000)
    librt.so.1 => /lib/i386-linux-gnu/i686/cmov/librt.so.1 (0xb76e3000)
    libc.so.6 => /lib/i386-linux-gnu/i686/cmov/libc.so.6 (0xb7585000)
    libpthread.so.0 => /lib/i386-linux-gnu/i686/cmov/libpthread.so.0 (0xb756c000)
    /lib/ld-linux.so.2 (0xb771d000)

(where librt and libpthread are pulled in recursively by libudev). This is so that code using the library doesn't have to know what other libraries it depends on, thus making dependency management much easier (especially if later versions have new dependencies but otherwise works the same).

The problem in your case is that not all of these links are present - hidapi-hidraw.so does not pull in all the libraries it depends on, in particular libudev - which means the linking fails because the linker doesn't know what libraries to load.

We could probably work around this by making the link explicitly when building tempered, but that ought to not be necessary (and is really just a hack), so it would be better to take a look at the hidapi build system and see if we can get it to link properly. I'm not really sure where to start though... so I guess I'll start with the basics.

I'm guessing you're building from hidapi git master? Is it fully up to date with the upstream repository? Do you have any local modifications?

Which distro (and version) are you using? Anything unusual I should know?

No worries about the time thing - I know how it is to have to find time for this stuff among all the other things one has to do.

[jpmorris]

same issue here:

• building against llibusb or linux both have the same problem
• a symbolic link to the new libudev seems to already exist:

:/lib/x86_64-linux-gnu$ ls -lat libudev.so.0 lrwxrwxrwx 1 root root 17 Apr 5 15:18 libudev.so.0 -> libudev.so.0.13.0

Any help you can provide I would greatly appreciate.

[jpmorris]

ok I think this fixed it for me:

http://edorfaus.wordpress.com/2012/04/28/devices-arrived/#comment-18

[edorfaus]

dhwndk: Linking hidapi statically worked? That's sort of odd, as I would have thought it would end up with the same missing link to libudev, but I guess not...

May I ask which version of what Linux distribution you're running into the problem on? Hopefully that can help me reproduce the problem, so I can try to fix it... (If you're not sure, running cat /etc/issue should show what it is.)

[jpmorris]

12.04 ubuntu, and it is definitely working for me

[jalla2000]

I did as described in dhwndk's link and it compiled. I'm running Ubuntu 12.04 with 3.2.0-25-generic x86_64 GNU/Linux.

[jalla2000]

Tested it with my sensor. Works. Though, tempered tells me it's close to 31C, and that seems a bit high. Is there anything I should tweak?

./enumerate Found device: 0c45:7402 1 | /dev/hidraw1 | TEMPer2HumiV1.x

sudo ./tempered /dev/hidraw1 0: temperature 30.18°C, relative humidity 38.4%, dew point 14.5°C

[jpmorris]

jalla2000 these temperS seem to be rather inaccurate. (I think mine is off 4deg F and probably a few % points in humidity) I doubt we can dunk them in ice water to calibrate, so I had to get a cheap indoor temp/hum monitor to calibrate and then hard code the change in my application (munin plugin). if you are using edorfaus' code by itself maybe he'll tell you how to calibrate

[edorfaus]

The TEMPer devices tend to be somewhat inaccurate, yes.

I have now added a way to get the tempered application to calibrate the returned temperature values, as long as you can give it the calibration factors. The option for this is --calibrate-temp or -c, that takes as a parameter a colon-separated list of calibration factors, for increasing powers of the measured temperature.

If all you have is a single correction addend (e.g. that the temperature is always too high by 4.3°C), all you have to do is give the option -c -4.3 and tempered will automatically subtract 4.3°C from the measured temperatures.