Re: [Discuss-gnuradio] FunCube Dongle pro +

[Volker Schroer]

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ü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