[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] FunCube Dongle pro +

From: Daniel Batista
Subject: Re: [Discuss-gnuradio] FunCube Dongle pro +
Date: Sat, 1 Nov 2014 08:26:02 -0700

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- => /usr/local/lib/libgnuradio-runtime- (0x00007fcdf2459000)
    libgnuradio-blocks- => /usr/local/lib/libgnuradio-blocks- (0x00007fcdf1fbe000)
    libgnuradio-audio- => /usr/local/lib/libgnuradio-audio- (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- => /usr/local/lib/libgnuradio-pmt- (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 Schroer <address@hidden> 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):

-- 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üller:
> 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
> On 11/01/2014 01:04 AM, Marcus Müller wrote:
>> 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
>> On 11/01/2014 12:43 AM, Sylvain Munaut wrote:
>>> 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
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Discuss-gnuradio mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]