Opened 11 years ago

Closed 11 years ago

#3181 closed defect (fixed)

build with cmake fails because linker cannot find -lusb1-.0

Reported by: gf Owned by: stefansat sat
Priority: minor Component: General
Severity: low Keywords: cmake build
Cc: Sensitive: no


OSCam revision r8401 (defconfig) fails to build on my machine using cmake because the linker complains about:

Linking C executable oscam
/usr/lib/gcc/i486-slackware-linux/4.7.2/../../../../i486-slackware-linux/bin/ld: cannot find -lusb-1.0
collect2: error: ld returned 1 exit status

I have libusb installed, make libusb works, cmake founds my libusb:

-- Looking for time.h - found
--   librt found (needed by libusb).
-- Looking for libusb-1.0/libusb.h
-- Looking for libusb-1.0/libusb.h - found
-- Looking for libusb-1.0/libusb.h
-- Looking for libusb-1.0/libusb.h - found
--  libusb 1.0 found . Adding smartreader support

Full build log is attached.

Attachments (3)

cmake_build.log (9.8 KB ) - added by gf 11 years ago.
cmake.log (9.9 KB ) - added by today 11 years ago.
cmake-libusb-dynamic.patch (1.9 KB ) - added by manu 11 years ago.

Download all attachments as: .zip

Change History (24)

by gf, 11 years ago

Attachment: cmake_build.log added

by today, 11 years ago

Attachment: cmake.log added

comment:1 by today, 11 years ago

Just tested with cmake without problem here.

comment:2 by gf, 11 years ago

It used be no problem on my end too, but now it just breaks and I have no idea how to debug or fix it. I don't use cmake so I don't care that much, but I would be happy to see this fixed.

comment:3 by gf, 11 years ago

Debug log:

Linking C executable oscam
/usr/bin/cmake -E cmake_link_script CMakeFiles/oscam.dir/link.txt --verbose=1
/usr/bin/cc  -O2  -s CMakeFiles/oscam.dir/oscam.o  -o oscam  libcsoscam.a libcsmodules.a libcsreaders.a csctapi/libcsctapi.a cscrypt/libcscrypt.a minilzo/libminilzo.a -Wl,-Bstatic -lusb-1.0 -Wl,-Bdynamic -lrt -lpthread -lcrypto -lpcsclite 
/usr/lib/gcc/i486-slackware-linux/4.7.2/../../../../i486-slackware-linux/bin/ld: cannot find -lusb-1.0
collect2: error: ld returned 1 exit status
make[3]: *** [oscam] Error 1
make[3]: Leaving directory `/home/gf/git/oscam/1'
make[2]: *** [CMakeFiles/oscam.dir/all] Error 2
make[2]: Leaving directory `/home/gf/git/oscam/1'
make[1]: *** [CMakeFiles/oscam.dir/rule] Error 2
make[1]: Leaving directory `/home/gf/git/oscam/1'
make: *** [oscam] Error 2

comment:4 by stefansat sat, 11 years ago

Just ter info first.

Is it a local build ? (or crosscompile) as -lusb-1.0 does refer to the gcc's known usb location. Here it's just using the same settings as in make. according the path used off cc /usr/bin/cc it seems to be local compilation.

for local compilation link.txt by me is

/usr/bin/gcc -O2 -s CMakeFiles/oscam.dir/oscam.o -o oscam libcsoscam.a libcsmodules.a libcsreaders.a csctapi/libcsctapi.a cscrypt/libcscrypt.a minilzo/libminilzo.a -lusb-1.0 -lrt -lpthread -lssl -lcrypto -lpcsclite

for cross for dm8000

/home/christophe/cross/toolchainsslMipsgcc4-6/mipsel-unknown-linux-gnu/bin/mipsel-unknown-linux-gnu-gcc-4.6.3 -O2 -s CMakeFiles/oscam.dir/oscam.o -o oscam libcsoscam.a libcsmodules.a libcsreaders.a csctapi/libcsctapi.a cscrypt/libcscrypt.a minilzo/libminilzo.a -lusb-1.0 -lrt -lpthread -lssl -lcrypto -lpcsclite -ldl

And it does compile perfect in bith cases

comment:5 by stefansat sat, 11 years ago

I'm using ubuntu 12.04 64 bit

comment:6 by manu, 11 years ago

Please try the attached patch. I've no idea why this was set to static all the time. But I've to admin I've no idea what the cmake file is doing anyway and why it's that damn long.

comment:7 by MadMaxx, 11 years ago

static compilation make sense for me on some linux-distributions, like debian lenny & squeeze, here the libusb is older (1.0.8) then from sourceforge (1.0.9).
So with static Version the compatibility is less a problem, i think...

Less external libs makes less problems on devices i figured out often in the past.

comment:8 by stefansat sat, 11 years ago

Yes it was set static all the time. This we will leave like that and is absolutely not the cause off gf's problem. But it is like that for de reason MadMaxx told. So it will remain compatible if You build on older for older system's. Where sometimes libusb isn't present.

But if you wan't it , it will always use dynamic link if you add parameter


To be honnest, When I took it over (the cmake maintenance) In first instance I made it compile trough cmake always dynamic. But since many persons which used the cmake from begin phase of oscam (very very long time users) I changed this bak again like it was, Standard static inclution of target's libusb-1.0.a static .

I well introduced as conterpart the possibility to add libusb dynamiccally. What You just have to do to force dynamic libusb-1.0 ld link is just adding the above parameter. you cmake command will then be

cmake -DSTATIC_LIBUSB=0 +all your others ..

I wanted to add this to doc's but they are gone.

before I changed it oscam with libusb-1.0 support for smartreader was always static there was no way to change that.

Last edited 11 years ago by stefansat sat (previous) (diff)

by manu, 11 years ago

Attachment: cmake-libusb-dynamic.patch added

comment:9 by gf, 11 years ago

@manu: With that patch cmake no longer fails to build oscam on my machine.

@stefansat, can you commit it, please (with appropriate commit message). And since I have your attention, can you look at ticket #3182.

in reply to:  8 comment:10 by manu, 11 years ago

Replying to stefansat:

Yes it was set static all the time. This we will leave like that and is absolutely

Well. You're partly right.
The real issue is LIBUSBDIR isn't defined/set at configure time.
The second issue is that it'll check for $LIBUSBDIR/lib/.. only, no support for x64 or multilib environments ($LIBUSBDIR/lib64/..).
And the third issue is: cmake will only check for a dynamic usb library iff a libusb archive exists and STATIC_LIBUSB=0 (wtf?). if there's no libusb archive, it'll just bail out (line 300).

/me is wrong. just ignore the stuff above.

@gf: as stefansat said, cmake -DSTATIC_LIBUSB=0 is the way to go with the current cmake config.

Last edited 11 years ago by manu (previous) (diff)

comment:11 by stefansat sat, 11 years ago

A will look at the 3182,

But first no this patch can't be passed because it will compile all oscam dynamic, by doing that most long time users will end up with a non compiling oscam. or not working. If You add by You into
cmake command

cmake -DSTATIC_LIBUSB=0 it will work. (the WSSP has nothing to do with the way of compiling its just a extra message parameter for me).

comment:12 by manu, 11 years ago

@stefansat: maybe you can extend the configuration information for the implicit STATIC_LIBUSB=1, just like you did if WSSP is set.

using static system libusb (run with -DSTATIC_LIBUSB=1 to use dynamic)
using dynamic system libusb (run with -DSTATIC_LIBUSB=0 to use static)

instead of a simple "use libusb functions"

or more preferred by me: use dynamic lib if available and STATIC_LIBUSB is not set to 1. use static lib if there's no dynamic. so prefer dynamic over static, unless explicitly defined.

Last edited 11 years ago by manu (previous) (diff)

comment:13 by stefansat sat, 11 years ago

@gf I think well thet I know you're problem, Normally when the dev files for libusb are isntalled, which you find in /usr/include or /usr/local/ the dev package containes as well the libusb-1.0.a files for static inclution. This seems not to work by you, is the libusb-1.0.a file missing ?

comment:14 by stefansat sat, 11 years ago

@manu, Yes you're wright, but I did this cause I've had some problems with a person.

like I told before cmake always did compile libusb static. When I took it over because they wanted to stop cmake, I changed that, but the result was that by many persons it did not worked out anymore. As they where working with systems whitout libusb (or only libusb but with dev's containing the libusb-1.0 dev files. or compiled for a box such like dreambox, which does not have libusb standard installed.

I decided to bring it back to static, but with ,a new option then to be able for dynamic linking libusb-1.0 as well (it should have been the other way around logically, but i tried to not disturb those persons which since long used cmake)

On that pff.. yes long message I had sudden an complain from someone that it now's include usb lib stattically because I let it see in cmake log. I was not able to let him understand that oscam always compiled with libusb statically before (when using cmake) and that if he wanted he just had to add the parameter -DSTATIC_LIBUSB=0 and then would have dynamic.

That's why i just changed the message with that WSSP if set on 1 you see which libusb you have if you set nothing or 0 you just receive global message that libusb is include. It's actually a personal parameter that I can see what's happen.

If you add in you're cmake command

cmake -DWSSP=1 ...(and all the rest) You will have the extended cmake log.

Last edited 11 years ago by stefansat sat (previous) (diff)

comment:15 by gf, 11 years ago

  1. The configure phase messages are misleading (it never said it would try to use static libusb, just said libusb found, everything is fine).
  2. It checks for one thing (if -lusb-1.0 works) and then assumes that static linking will work (which may not in my case as seen in this ticket).

The right thing to do is first to not mislead the user and say that it will try to use static libusb and second if there is dynamic libusb it shouldn't assume that there is a static one.

Third I just realized that
-Wl,-Bstatic -lusb-1.0 -Wl,-Bdynamic
means turn on static linking, link with this, turn on dynamic linking.

I didn't know that trick and that is the other reason why I couldn't figure out why the build failed. It clearly wanted -lusb-1.0 and I have that :)

comment:16 by stefansat sat, 11 years ago

Now its because the linkage is bassically static. If the static file is not present it will fail.
(this static was like that because oscam did like that before and this is kept to not brake the builds by other persons who uses cmake.)
Now if You want to have dynamic libusb (and I use this by me as well) just add -DSTATIC_LIBUSB = 0 into you're cmake command. I well will add a protection for local compile (non cross) which will compile dynamic if and only if the libusb-1.0.a file is missing. The dev files also includes the /usr/include needed headers when You install these (with ubuntu) the libusb-1.0.a commes with as well. Or if you compile the libusb-1.0 from source yourself it will include the /usr/include headers and the static libusb-1.0.a unless you specifically ask for not compiling or installing the static libs.

I fully agree that its better to standardize the dynamic linking if present, but ..... it wasn't like that before and that's the point.

I'm thinking what a will do with it and it should come out today with protection anyway.

comment:17 by manu, 11 years ago

As for me: just change it. If someone wants to do static linking, he/she should explicitly define that. Also makes both build setups identical in their default configuration.
Just because something was done before, doesn't make it right. Just make it clear in the commit message, for people using cmake right now.

In Makefile.extra we have the following additional targets: static, static-libusb, static-libcrypto, static-ssl

Maybe use:

-DSTATIC=1 ...use static libs only
-DSTATIC_USB=1 ...use static libusb

and regarding libusb-1.0.a: On redhat/fedora based distribution the archives are packed into a separate libfoo-static package. As there's simply no need to have them on your system when you can do dynamic linking.

Last edited 11 years ago by manu (previous) (diff)

comment:18 by stefansat sat, 11 years ago

Now that ticket 3182 is closed, I'm working on the review off libusb implementation.

Taking into account the years off use CMAKE for crosscompiling whit a missing crucial parameter,
called CMAKE_FIND_ROOT_PATH . This leaded to the introduction off the LIBUSBDIR parameter by some person. Which was a hackis way around and not needed normally.But now it's in I leave it in, for not breaking down builds of those who uses it.

For the non cross compile, I will change the behaviour to standard use dynamic linking. As You're supposed to compile for you're own system and if it's present its' a bit stupid to include static libusb.

The end result will be :

case off cross-compile standard static inclution of libusb (the most set top boxes do not have the libusb standard installed so it requires static libusb) . Overridable by parameter -DSTATIC_LIBUSB=0 .

case off non cross-compile standard dynamic ld inclution of libusb. Overridable by parameter -DSTATIC_LIBUSB = 1 .

And then also a couple off protection's that if You requested libusb self with -DHAVE_LIBUSB=1 and there is no libusb static or dynamic on your system or in dev files, It will not issue a report wich says libusb and smartreader support is included while it is not. But warn you about the fact that you requested libusb but that it can not be included and just will compile whitout libusb.

comment:19 by stefansat sat, 11 years ago

Owner: set to stefansat sat

comment:20 by stefansat sat, 11 years ago

A further review let me decide to change the default compilation from static to dynamic for libusb.

The current way of working now.
If no parameter is added and libusb is present on you're system white a correct(standard) installation.(and the header dev files are installed as well)

Oscam will be compiled With libusb included, dynamic linked. Smartreader support included.

Some usefull parameters

-DSTATIC_LIBUSB=1 to force static libusb (will cause error if the libusb-1.0.a file is missing)

Also very usefull if you compile on you're mac binary which is to be used by users who do not have
X-code and no libusb installed on there mac they will be able to use smartreader then.
For most set top boxes I advice to compile with this parameter as they do not have standard libusb

-DSTATIC_LIBUSB=0 Force dynamic libusb maybe be used but is not needed anymore.

The parameter to disable libusb support is still the same :


-DHAVE_LIBUSB=1 to force libusb , but this parameter is not needed as libusb is added automatically if you're system is equiped with libusb and the needed dev headers. It even may cause compile error's by forcing libusb if the needed library's ar not installed.

comment:21 by stefansat sat, 11 years ago

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.