Forum: GNU Radio followup: libgnuradio-fcd-3.7.3git.so.0.0.0: undefined reference to `libusb_handle_events_completed'

25b20d4a81a4808147927b1ca70160d5?d=identicon&s=25 ikjtel (Guest)
on 2014-01-08 16:23
(Received via mailing list)
OK, this error seems to be all fixed now, but as a result I now have a
doubt about pybombs .

[The background of the problem is in the previous posting (yesterday)
about this, but essentially the problem started when I changed the
pybombs recipe for libusb in order to force pybombs to build libusb from
source rather than to use the libusb-1.0-0-dev (that was originally set
in "satisfy_deb"). ]

Once this was changed, pybombs did in fact fetch the libusb source and
built that - however, subsequent compiles were still looking in
/usr/include for the .h files (and finding the old, bad ones). I
bypassed that error.

Then the linker also bombed out, again where pybombs should have looked
in its own built-from-source copy of libusb. At that point I posted the
first message about the linker problem late last night...


I offer the following message as 'documentation' of the claim that
pybombs is still trying to link against the system copy of libusb and
not its own local copy of libusb that it built from source... Note that
it prints the library location...


make[2]: *** No rule to make target
`/usr/lib/x86_64-linux-gnu/libusb-1.0.so', needed by
`gr-fcd/lib/libgnuradio-fcd-3.7.3git.so.0.0.0'. Stop.


After I fixed that, gnuradio compiled cleanly under pybombs...

Best

Max
Bb19124b22a2ffb09cd0fc951561d55c?d=identicon&s=25 George Refseth (Guest)
on 2014-01-08 17:18
(Received via mailing list)
On 01/08/2014 04:19 PM, ikjtel wrote:
> built that - however, subsequent compiles were still looking in
> /usr/include for the .h files (and finding the old, bad ones).  I
> bypassed that error.
>
> Then the linker also bombed out, again where pybombs should have
> looked in its own built-from-source copy of libusb.  At that point I
> posted the first message about the linker problem late last night...

Same problem with libfaad2, fix recipe, and fix the cmake file that set
up where to look for both header files and library.
That was your solution also? Btw. I was working with gr-drm in a pybombs
environment.

regards
George
Bb19124b22a2ffb09cd0fc951561d55c?d=identicon&s=25 George Refseth (Guest)
on 2014-01-08 17:49
(Received via mailing list)
On 01/08/2014 04:19 PM, ikjtel wrote:
> built that - however, subsequent compiles were still looking in
> that it prints the library location...
Same problem with libfaad2, fix recipe, and fix the cmake file that set
up where to look for both header files and library.
That was your solution also?

regards
George
Please log in before posting. Registration is free and takes only a minute.
Existing account

NEW: Do you have a Google/GoogleMail, Yahoo or Facebook account? No registration required!
Log in with Google account | Log in with Yahoo account | Log in with Facebook account
No account? Register here.