All of lore.kernel.org
 help / color / mirror / Atom feed
From: Philip Balister <philip@balister.org>
To: openembedded-devel@lists.openembedded.org
Subject: Re: libusb and libusb-compat: conflict
Date: Wed, 10 Sep 2008 07:24:02 -0400	[thread overview]
Message-ID: <48C7AE52.7080209@balister.org> (raw)
In-Reply-To: <ga81it$e8i$1@ger.gmane.org>

[-- 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 --]

  reply	other threads:[~2008-09-10 11:26 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-10  1:22 libusb and libusb-compat: conflict Mike (mwester)
2008-09-10  2:30 ` Philip Balister
2008-09-10  8:47 ` Koen Kooi
2008-09-10 11:24   ` Philip Balister [this message]
2008-09-10 13:24   ` Mike (mwester)
2008-09-10 16:18     ` Matt Darland

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=48C7AE52.7080209@balister.org \
    --to=philip@balister.org \
    --cc=openembedded-devel@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.