Re: FunCube Dongle pro +

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
:slight_smile:

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 :confused: 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
Marcus

Sylvain

Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio