This is because the version of the libusb library you have is too old to have
that particular API call in it.
I use ubuntu 12.04 and libusb-1.0-0-dev
Do you what version of libusb is compatible?
This is because the version of the libusb library you have is too old to have
that particular API call in it.
I use ubuntu 12.04 and libusb-1.0-0-dev
Do you what version of libusb is compatible?
The problem is that Ubuntu 12.04 seems to carry 1.0.9 around, so this
seems strange.
I’m a bit conflicted – the missing symbol looks like it should belong
to libudev and not libusb-versionhell.
This might indicate that you’re bound to update libudev, which is rather
system central, and which might be a bit of a hassle; I’d personally
recommend updating to Ubuntu 14.04 LTS or the brand new 14.10 [1].
It feels like the module should link against libudev, as it includes
libudev.h and uses symbols from that library, but I can’t find a single
reference to udev in the cmake files of gr-fcdproplus.
this is but a shot in the dark, but could you delete the contents of
your build folder, and rund cmake with “-DCMAKE_CXX_FLAGS=-ludev”
Greetings,
Marcus
[1]
https://wiki.ubuntu.com/TrustyTahr/ReleaseNotes#Upgrading_from_Ubuntu_12.04_LTS_or_Ubuntu_13.10
On 10/31/2014 06:27 PM, Daniel B. wrote:
This is because the version of the libusb library you have is too old
to have that particular API call in it.I use ubuntu 12.04 and libusb-1.0-0-dev
Do you what version of libusb is compatible?
I think that 1.0.9 and newer are compatible.
If I was forced to make a wild guess I’d probably assume it uses some
USB-HID interface for configuration, and udev for hotplug detection.
I think I’ll have the libery of including Mr. Schroer in this discussion
Greetings,
Marcus
What I find strange is that the symbol error is found at runtime and
not at link-time. That suggest either there is two libudev and the one
used for runtime is different than the one found for link-time, or
that this library was copied over from another system.
Cheers,
Sylvain
On 10/31/2014 07:00 PM, Marcus M. wrote:
single reference to udev in the cmake files of gr-fcdproplus.
On 10/31/2014 06:27 PM, Daniel B. wrote:
This is because the version of the libusb library you have is too
old to have that particular API call in it.I use ubuntu 12.04 and libusb-1.0-0-dev
Do you what version of libusb is compatible?
I think that 1.0.9 and newer are compatible.
Hmm, I wonder why it cares about udev? When I saw “enumerate” I thought
this was a libusb thing, but clearly not.
I thought that FCD devices just “manifested” as audio anyway–no direct
libusb required?
Oh indeed, good point!
Sylvain: you’re right.
How gr-fcdproplus ends up being able to compile and link is still a
mystery to me. I was expecting a horrible “symbol export forwarding
hack” involving libusb, but no:
$>nm -D /lib64/libusb-1.so
U udev_device_get_action
U udev_device_get_devnode
U udev_device_get_sysname
U udev_device_new_from_syspath
U udev_device_unref
U udev_enumerate_add_match_subsystem
U udev_enumerate_get_list_entry
U udev_enumerate_new
…
gives me all of the udev symbols as undefined, which obviously is
correct, because they should be dynamically loaded from libusb:
$>ldd /lib64/libusb-1.0.so
libusb-1.0.so|grep udev
linux-vdso.so.1 => (0x00007fff6b7fc000)
libudev.so.1 (0x00000038b6600000)
…
Trying to build this now, but I’m currently on a machine where I haven’t
even installed GR yet this might take a second.
Greetings,
Marcus
Tracing this down; Daniel, could you share what
pkg-config --static --libs libsub-1.0
says?
in your build directory, can you do a
ldd lib/libgnuradio-fcdproplus.so
Greetings, and good night (forgot the time)
Marcus
udev_enumerate_new is called from the latest hidapi code.
Some distros provide a hidapi package. So the actual fcdproplus tries to
detect if an hidapi package is installed. Otherwise it uses the hidapi
code provided with fcdproplus, which uses udev_enumerate_new.
So it would be interesting waht cmake has reported.
Near the end of the cmake output you see something like this ( in the
case that the hidapi package is installed):
GNURADIO_PMT_FOUND = TRUE
– checking for module ‘alsa’
– found alsa, version 1.0.28
– Found ALSA 1.0.28
– checking for module ‘libusb-1.0’
– found libusb-1.0, version 1.0.19
– Found libusb-1.0: /usr/include/libusb-1.0, /usr/lib64/libusb-1.0.so
– Found Doxygen: /usr/bin/doxygen (found version “1.8.5”)
– System Hidapi Lib /usr/lib64/libhidapi-libusb.so is used
– Audio LIBS: /usr/local/gnuradio-orig/lib/libgnuradio-audio.so
As Marcus already proposed, it might be helpfull to see the output of
ldd lib/libgnuradio-fcdproplus.so
inside the build directory
and additionally from the gnuradio install directory.
I think udev_enumerate_new is provided from newer versions of libudev.
If you want to use a hidapi version without udev_enumerate_new
just checkout the with_hidapi release.
– Volker
Am 01.11.2014 um 01:39 schrieb Marcus M.:
Thank you all for your help!
As Marcus suggested, by passing the “-DCMAKE_CXX_FLAGS=-ludev” in cmake,
I managed to solve the problem.
I report here the output of the command “pkg-config --static --libs
libusb-1.0”:
-pthread -lusb-1.0 -lrt
and the output of the command: “ldd lib/libgnuradio-fcdproplus.so”
linux-vdso.so.1 => (0x00007fff107ff000)
libhidapi-libusb.so.0 => /usr/local/lib/libhidapi-libusb.so.0
(0x00007fcdf2952000)
libboost_system.so.1.48.0 => /usr/lib/libboost_system.so.1.48.0
(0x00007fcdf2736000)
libgnuradio-runtime-3.7.5.1.so.0.0.0 =>
/usr/local/lib/libgnuradio-runtime-3.7.5.1.so.0.0.0 (0x00007fcdf2459000)
libgnuradio-blocks-3.7.5.1.so.0.0.0 =>
/usr/local/lib/libgnuradio-blocks-3.7.5.1.so.0.0.0 (0x00007fcdf1fbe000)
libgnuradio-audio-3.7.5.1.so.0.0.0 =>
/usr/local/lib/libgnuradio-audio-3.7.5.1.so.0.0.0 (0x00007fcdf1d8c000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
(0x00007fcdf1a8b000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
(0x00007fcdf1875000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fcdf14b6000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fcdf12ad000)
libusb-1.0.so.0 => /lib/x86_64-linux-gnu/libusb-1.0.so.0
(0x00007fcdf109e000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x00007fcdf0e81000)
libvolk.so.0.0.0 => /usr/local/lib/libvolk.so.0.0.0
(0x00007fcdf0b66000)
libgnuradio-pmt-3.7.5.1.so.0.0.0 =>
/usr/local/lib/libgnuradio-pmt-3.7.5.1.so.0.0.0 (0x00007fcdf0923000)
libboost_filesystem.so.1.48.0 =>
/usr/lib/libboost_filesystem.so.1.48.0 (0x00007fcdf0704000)
libboost_thread.so.1.48.0 => /usr/lib/libboost_thread.so.1.48.0
(0x00007fcdf04e8000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fcdf01ec000)
libasound.so.2 => /usr/lib/x86_64-linux-gnu/libasound.so.2
(0x00007fcdefefe000)
/lib64/ld-linux-x86-64.so.2 (0x00007fcdf2d6b000)
liborc-0.4.so.0 => /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0
(0x00007fcdefc83000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fcdefa7f000)
Although FCDpro+ run now, grnuradio crashes. I see nothing on FFT and a
lot of “aOaOaOaOaOaOaO” in Reports area.
Thank you again
On Saturday, November 1, 2014 12:01 PM, Volker S. [email protected]
wrote:
udev_enumerate_new is called from the latest hidapi code.
Some distros provide a hidapi package. So the actual fcdproplus tries to
detect if an hidapi package is installed. Otherwise it uses the hidapi
code provided with fcdproplus, which uses udev_enumerate_new.
So it would be interesting waht cmake has reported.
Near the end of the cmake output you see something like this ( in the
case that the hidapi package is installed):
GNURADIO_PMT_FOUND = TRUE
– checking for module ‘alsa’
– found alsa, version 1.0.28
– Found ALSA 1.0.28
– checking for module ‘libusb-1.0’
– found libusb-1.0, version 1.0.19
– Found libusb-1.0: /usr/include/libusb-1.0, /usr/lib64/libusb-1.0.so
– Found Doxygen: /usr/bin/doxygen (found version “1.8.5”)
– System Hidapi Lib /usr/lib64/libhidapi-libusb.so is used
– Audio LIBS: /usr/local/gnuradio-orig/lib/libgnuradio-audio.so
As Marcus already proposed, it might be helpfull to see the output of
ldd lib/libgnuradio-fcdproplus.so
inside the build directory
and additionally from the gnuradio install directory.
I think udev_enumerate_new is provided from newer versions of libudev.
If you want to use a hidapi version without udev_enumerate_new
just checkout the with_hidapi release.
– Volker
Am 01.11.2014 um 01:39 schrieb Marcus M.:
On 11/01/2014 01:04 AM, Marcus M. wrote:
U udev_device_new_from_syspath
$>ldd /lib64/libusb-1.0.so
MarcusSylvain
Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs