[compatibility] libusbx replaced by libusb-1.0 in most distros

@slyshykO

As of March 2020 on most distros libusbx has been replaced by the maintained libusb-1.0.
This reflects the re-merging of the libusbx-project-fork back into the libusb-project (see https://github.com/libusb/libusb/wiki/FAQ#libusborg_libusbxorg_and_libusbinfo) as referenced by @slyshykO in #782. As mentioned in PR #895, I did some small research on this topic to find out about the current state of support by various distributions currently maintained.

Here is the result from https://pkgs.org/search/?q=libusb (as of Mar 2020):

1.0.23

Alpine Edge
Alpine 3.11
ALT Linux Sisyphus
Arch Linux
Debian Sid
Fedora Rawhide --> libusbx, but compatible, as libusb-codebase is used
KaOS
OpenMandriva Cooker
OpenMandriva Lx 4.1
openSUSE Tumbleweed
Slackware Current
Solus
Ubuntu 20.04 LTS
Ubuntu 19.10

1.0.22

Alpine 3.10
Alpine 3.9
CentOS 8 --> libusbx, but compatible, as libusb-codebase is used
Debian 10 (Buster)
Fedora 31 --> libusbx, but compatible, as libusb-codebase is used
Fedora 30 --> libusbx, but compatible, as libusb-codebase is used
Mageia Cauldron
Mageia 7.1
NetBSD 9.0
NetBSD 8.1
NetBSD 7.2

1.0.21

CentOS 7 --> libusbx, but compatible, as libusb-codebase is used
Debian 9 (Stretch)
openSUSE Leap 15.2
openSUSE Leap 15.1
Ubuntu 18.04 LTS

1.0.20

OpenMandriva Lx 3.0
Slackware 14.2
Ubuntu 16.04 LTS

... older libusb versions --> would no longer be supported

Debian 8 (Jessie) - 1.0.19
Ubuntu 14.04 LTS - 1.0.17
CentOS 6 - 1.0.9
Slackware 14.1 - 1.0.9

Special case
... on FreeBSD libusb is integrated into the system:

FreeBSD 13 - linux_libusb-13.0r358841 --> libusb-codebase 1.0.16 - 1.0.18 used
FreeBSD 12 - linux_libusb-11.0r261448_4 --> libusb-codebase 1.0.16 - 1.0.18 used
FreeBSD 11 - linux_libusb-11.0r261448_4 --> libusb-codebase 1.0.16 - 1.0.18 used

Looking at this, we should set libusb 1.0.20 as the minimum required version (apart from FreeBSD) to ensure widespread compatibility.

@Vascom

This initiated a ongoing discussion in PR #895 which shall be continued here, as the related PR should solely focus on (direct) changes in the code. The beginning of this discussion is now posted here:

Nightwalker-87:
@Vascom: You are on Fedora right? What do you think about this? Why does Fedora still use libusbx BTW? Is your library that outdated as well?

Reply by Vascom:

@Nightwalker-87 I don't know why it still not updated in rawhide. Need to ask maintainer.
But even if this update will be done it will be never updated for current releases of Fedora and RHEL/CentOS.

Reply by slyshykO:

Looks like starting from this commit https://src.fedoraproject.org/rpms/libusbx/commits/master Fedora switched from libusbx to libusb but don't change the package name.

Reply by Vascom:

No.
libusb - for compatibility with 0.1 API.
libusbx - main libusb as I know.

Reply by slyshykO:

@Vascom Yes. My point is they (Fedora) use sources from libusb-project for libusbx-package.

Reply by Vascom:

upstream libusbx has merged back with libusb and is now called libusb again, but we already have a libusb package for the old libusb-compat-0.1, renaming that to libusb-compat while at the same time giving this its name is a bit tricky, lets stick with the libusbx name for now

@Vascom

@Vascom: There are three relevant things:

As @slyshykO mentioned before: the package name is not the relevant thing, but if LIBUSBX_API_VERSION is used by the package which then remains from the libusbx-codebase
Nobody cares about libusb-compat, libusb-0.1 or whatever the older packages for libusb 0.1 compatibility versions are called. These are neither addressed by this issue, nor relevant.
¯\ _(ツ) _/¯
Please test the current development branch with your fedora environment as it comes without any reference to LIBUSBX_API_VERSION. If it works we are fine here, if not, the incompatibility with fedora is present for quite a long time, as previously LIBUSBX_API_VERSION could only be called on FreeBSD systems anyway (where it was not needed anymore, as we found out in [compatibility] LIBUSBX_API_VERSION undef #782 previously).

1.0.23 pushed to Fedora rawhide now https://src.fedoraproject.org/rpms/libusbx/c/5684853d449b7fe3a81112cd59f9336fbc274319?branch=master

That's good news for us.

Similar result for Fedora 30 (oldest supported version):
Here it is libusb 1.0.22 despite the (false) package name: https://src.fedoraproject.org/rpms/libusbx/c/cbd5348ee14638264fe3bb79c3b27a5ed34271ed?branch=f30

One can conclude that this is done equally in Fedora 31, so we are fine here. That's the reason why it works even without any LIBUSBX_API_VERSION remnants currently. 👍

@lhondareyte

@lhondareyte @DanielO: It appears you both use (or used) FreeBSD. Can you provide us some information regarding the libusb versions present on recent releases (11, 12, 13)? pkgs.org was not very helpful in this aspect.

Hi,
For FreeBSD, libusb is in the base system, it's not a package. It's compatible with libusb1 & 2 . You can get more informations with "pkconf":
pkgconf --libs --cflags libusb-1.0
pkgconf --libs --cflags libusb-2.0
pkgconf is, as far I know, specific to FreeBSD.
Hope this help.
Regards

@lhondareyte

@lhondareyte: Thx for the useful feedback. What FreeBSD-Version/Release are you on? Can you also checkout the develop branch and test-compile the stlink-tools? With this we could rule out possible regression when we merge the related PR. By now current FreeBSD Releases seem to be the only left "unknowns" (see list above).

I am running the latest stable version (12.1p1) (almost). I tried to compile the latest snapshot and it actually failed:
/usr/home/luc/stlink/src/usb.c:34:22: error: use of undeclared identifier 'INT_MAX'
The compilation works with

// src/usb.c
#if defined (__FreeBSD__)
#include <sys/limits.h>
#endif

Which commit/branch do you want to try exactly?

About FreeBSD current (latest dev branch), I only use it on ARM platform. I'll give it a try this week-end: just try to compile only (USB support can be tricky)

@DanielO

@DanielO: Thx for checking! Please let us know if this changes someday.

ok, so we actually have to stay on libusb 1.0.16 ... 1.0.18 codebase then for FreeBSD for compatibility reasons. In terms of implementation we will likely check for the 0x01000102 in cmake here.

I'll do a new table for our documentation that is going to list all what we have found out by now.

@slyshykO: Can you extend you PR #895 with the discussed check for windows and maybe also update the cmake routine for FreeBSD?

I've updated the #895. Please, take a look.

[doc] compiling & version support

Updated compiling doc & version support

Navigation Menu

Repository navigation

[compatibility] libusbx replaced by libusb-1.0 in most distros #897

22 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[compatibility] libusbx replaced by libusb-1.0 in most distros #897

Description

Activity

Nightwalker-87 commented on Mar 26, 2020

Nightwalker-87 commented on Mar 26, 2020

Vascom commented on Mar 26, 2020

Nightwalker-87 commented on Mar 26, 2020

Nightwalker-87 commented on Mar 26, 2020

Nightwalker-87 commented on Mar 26, 2020

lhondareyte commented on Mar 26, 2020

Nightwalker-87 commented on Mar 26, 2020

lhondareyte commented on Mar 26, 2020

22 remaining items

Nightwalker-87 commented on Mar 28, 2020

slyshykO commented on Mar 28, 2020

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions