libusb and libusb-compat: conflict

libusb and libusb-compat: conflict

[Mike (mwester)]

There appears to be a conflict between libusb and libusb-compat -- both
stage usr/lib/libusb.a.

Many packages in OE use libusb-compat; some others use libusb.  I can't
say why this conflict hasn't come up before -- perhaps its a build order
thing that has just popped up on my system -- but attempting to link
openocd or dfu-util (which DEPEND on libusb) against the libusb.a in
staging will fail, if it was libusb-compat that was staged overtop of
libusb.

I think step one would be to put a "CONFLICTS" line in each of libusb
and libusb-compat's bb files -- but I suspect that will break a lot of
builds.  So I'll send an email out for comments and suggestions on how
to handle this little problem.

It would be good if people can check their tmpdirs to see if both libusb
and libusb-compat are being built (libusb1 is fine - not the similarity
in name).  How big a problem is this?

Regards,
Mike (mwester)

Re: libusb and libusb-compat: conflict

[Philip Balister]

[-- Attachment #1: Type: text/plain, Size: 1412 bytes --]

Can you get the packages that use libusb to use libusb-compat? The only 
package I know of that does not work with libusb1 is gnuradio (gnuradio 
looks inside private libusb structures).

Philip

Mike (mwester) wrote:
> There appears to be a conflict between libusb and libusb-compat -- both
> stage usr/lib/libusb.a.
> 
> Many packages in OE use libusb-compat; some others use libusb.  I can't
> say why this conflict hasn't come up before -- perhaps its a build order
> thing that has just popped up on my system -- but attempting to link
> openocd or dfu-util (which DEPEND on libusb) against the libusb.a in
> staging will fail, if it was libusb-compat that was staged overtop of
> libusb.
> 
> I think step one would be to put a "CONFLICTS" line in each of libusb
> and libusb-compat's bb files -- but I suspect that will break a lot of
> builds.  So I'll send an email out for comments and suggestions on how
> to handle this little problem.
> 
> It would be good if people can check their tmpdirs to see if both libusb
> and libusb-compat are being built (libusb1 is fine - not the similarity
> in name).  How big a problem is this?
> 
> Regards,
> Mike (mwester)
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> 

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3303 bytes --]

Re: libusb and libusb-compat: conflict

[Koen Kooi]

Mike (mwester) wrote:
> There appears to be a conflict between libusb and libusb-compat -- both
> stage usr/lib/libusb.a.
>
> Many packages in OE use libusb-compat; some others use libusb.  I can't
> say why this conflict hasn't come up before -- perhaps its a build order
> thing that has just popped up on my system -- but attempting to link
> openocd or dfu-util (which DEPEND on libusb) against the libusb.a in
> staging will fail, if it was libusb-compat that was staged overtop of
> libusb.
>
> I think step one would be to put a "CONFLICTS" line in each of libusb
> and libusb-compat's bb files -- but I suspect that will break a lot of
> builds.  So I'll send an email out for comments and suggestions on how
> to handle this little problem.
>
> It would be good if people can check their tmpdirs to see if both libusb
> and libusb-compat are being built (libusb1 is fine - not the similarity
> in name).  How big a problem is this?

Some background: libusb1 is the rewrite of libusb which brings up 
goodness as better performance and more powersaving, but its ABI is 
incompatible with libusb. That is why the libusb people create 
libusb-compat, it's a drop-in replacement for libusb.

When I added it to OE I made sure the runtime situation worked and 
changed all packages to libusb-compat. It seems I missed a few.

It should be safe to change everything over to libusb-compat, unless 
your favourite apps abuses private libusb API (as gnuradio does).

And there's no such thing as CONFLICTS in OE, only RCONFLICTS.

regards,

Koen

Re: libusb and libusb-compat: conflict

[Philip Balister]

[-- Attachment #1: Type: text/plain, Size: 2193 bytes --]

Koen Kooi wrote:
> Mike (mwester) wrote:
>> There appears to be a conflict between libusb and libusb-compat -- both
>> stage usr/lib/libusb.a.
>>
>> Many packages in OE use libusb-compat; some others use libusb.  I can't
>> say why this conflict hasn't come up before -- perhaps its a build order
>> thing that has just popped up on my system -- but attempting to link
>> openocd or dfu-util (which DEPEND on libusb) against the libusb.a in
>> staging will fail, if it was libusb-compat that was staged overtop of
>> libusb.
>>
>> I think step one would be to put a "CONFLICTS" line in each of libusb
>> and libusb-compat's bb files -- but I suspect that will break a lot of
>> builds.  So I'll send an email out for comments and suggestions on how
>> to handle this little problem.
>>
>> It would be good if people can check their tmpdirs to see if both libusb
>> and libusb-compat are being built (libusb1 is fine - not the similarity
>> in name).  How big a problem is this?
> 
> Some background: libusb1 is the rewrite of libusb which brings up 
> goodness as better performance and more powersaving, but its ABI is 
> incompatible with libusb. That is why the libusb people create 
> libusb-compat, it's a drop-in replacement for libusb.
> 
> When I added it to OE I made sure the runtime situation worked and 
> changed all packages to libusb-compat. It seems I missed a few.
> 
> It should be safe to change everything over to libusb-compat, unless 
> your favourite apps abuses private libusb API (as gnuradio does).
> 
> And there's no such thing as CONFLICTS in OE, only RCONFLICTS.

Is there an easy way to select between the two? Until I get time to go 
through the gnu radio code, I'm using a collection to keep the gnuradio 
stuff in a state where it builds.

I would really like to get the gnuradio stuff working with libusb1, 
since I suspect it would benefit from the upgrade :)

Philip

> 
> regards,
> 
> Koen
> 
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> 

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3303 bytes --]

Re: libusb and libusb-compat: conflict

[Mike (mwester)]

Koen Kooi wrote:
...
> Some background: libusb1 is the rewrite of libusb which brings up
> goodness as better performance and more powersaving, but its ABI is
> incompatible with libusb. That is why the libusb people create
> libusb-compat, it's a drop-in replacement for libusb.
> 
> When I added it to OE I made sure the runtime situation worked and
> changed all packages to libusb-compat. It seems I missed a few.

Grep comes up with a bunch, but probably a lot of those are just older
recipes -- dfu-util and openocd are definitely broken, though.

> It should be safe to change everything over to libusb-compat, unless
> your favourite apps abuses private libusb API (as gnuradio does).

I encountered simple linker failures (symbols not found).  I'll get rid
of libusb out of staging entirely and see if dfu-util and openocd will
link correctly against libusb-compat.  I can test dfu-util, but I hope
someone else can test openocd.

> And there's no such thing as CONFLICTS in OE, only RCONFLICTS.

Bummer.  That would mean that we would need to switch to
"virtual/libusb" I guess.  That seems a lot of effort for something
that's obsolete -- it might be better to warn people if libusb is being
built instead of libusb-compat.  I wonder if this might be a use case
for a "WARNING" metadata item in a bitbake recipe.

I will do nothing with any metadata then except attempt to build
dfu-util and openocd with libusb-compat.

> regards,
> 
> Koen

Mike (mwester)

Re: libusb and libusb-compat: conflict

[Matt Darland]

FYI, libusb1 is broken on 2.6.26 kernels. If it tries to use sysfs, then it 
will expect every USB device to have a 'descriptors' file in sysfs, but that 
isn't necessarily the case in recent kernels.

http://sourceforge.net/mailarchive/message.php?msg_name=20080731112725.55310%40gmx.net


On Wednesday 10 September 2008 08:24:37 am Mike (mwester) wrote:
> Koen Kooi wrote:
> ...
>
> > Some background: libusb1 is the rewrite of libusb which brings up
> > goodness as better performance and more powersaving, but its ABI is
> > incompatible with libusb. That is why the libusb people create
> > libusb-compat, it's a drop-in replacement for libusb.
> >
> > When I added it to OE I made sure the runtime situation worked and
> > changed all packages to libusb-compat. It seems I missed a few.
>
> Grep comes up with a bunch, but probably a lot of those are just older
> recipes -- dfu-util and openocd are definitely broken, though.
>
> > It should be safe to change everything over to libusb-compat, unless
> > your favourite apps abuses private libusb API (as gnuradio does).
>
> I encountered simple linker failures (symbols not found).  I'll get rid
> of libusb out of staging entirely and see if dfu-util and openocd will
> link correctly against libusb-compat.  I can test dfu-util, but I hope
> someone else can test openocd.
>
> > And there's no such thing as CONFLICTS in OE, only RCONFLICTS.
>
> Bummer.  That would mean that we would need to switch to
> "virtual/libusb" I guess.  That seems a lot of effort for something
> that's obsolete -- it might be better to warn people if libusb is being
> built instead of libusb-compat.  I wonder if this might be a use case
> for a "WARNING" metadata item in a bitbake recipe.
>
> I will do nothing with any metadata then except attempt to build
> dfu-util and openocd with libusb-compat.
>
> > regards,
> >
> > Koen
>
> Mike (mwester)
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel