Stlink: [Kompatibilität] libusbx in den meisten Distributionen durch libusb-1.0 ersetzt

Dies löste eine laufende Diskussion in PR #895 aus, die hier fortgesetzt werden soll, da sich die zugehörige PR ausschließlich auf (direkte) Änderungen im Code konzentrieren sollte. Der Beginn dieser Diskussion ist nun hier gepostet:

Nachtwandler-87:
@Vascom : Du bist auf Fedora richtig? Was denkst du darüber? Warum verwendet Fedora immer noch libusbx BTW? Ist Ihre Bibliothek auch so veraltet?

Antwort von Vascom:

@ Nightwalker-87 Ich weiß nicht, warum es immer noch nicht in Rohhaut aktualisiert wurde. Betreuer fragen müssen.
Aber selbst wenn dieses Update durchgeführt wird, wird es niemals für aktuelle Versionen von Fedora und RHEL/CentOS aktualisiert.

Antwort von slyshykO:

Sieht so aus, als würde Fedora ab diesem Commit https://src.fedoraproject.org/rpms/libusbx/commits/master von libusbx zu libusb wechseln, aber den Paketnamen nicht ändern.

Antwort von Vascom:

Nein.
libusb - für Kompatibilität mit 0.1 API.
libusbx - Haupt-libusb, wie ich weiß.

Antwort von slyshykO:

@ Vascom Ja. Mein Punkt ist, dass sie (Fedora) Quellen aus dem libusb-Projekt für das libusbx-Paket verwenden.

Antwort von Vascom:

Upstream libusbx hat sich wieder mit libusb verschmolzen und heißt jetzt wieder libusb, aber wir haben bereits ein libusb-Paket für das alte libusb-compat-0.1, das in libusb-compat umzubenennen, während ihm gleichzeitig sein Name gegeben wird, ist ein bisschen schwierig, Bleiben wir erstmal beim Namen libusbx

@Vascom : Es gibt drei relevante Dinge:
1) Wie @slyshykO bereits erwähnt hat: der Paketname ist _nicht_ das Relevante, aber wenn LIBUSBX_API_VERSION vom Paket verwendet wird, bleibt das aus der libusbx-Codebase
2) Niemand kümmert sich um libusb-compat , libusb-0.1 oder wie auch immer die älteren Pakete für Kompatibilitätsversionen von libusb 0.1 heißen. Diese werden in diesem Thema weder angesprochen noch sind sie relevant.
¯\ _(ツ) _/¯
3) Bitte testen Sie den aktuellen Entwicklungszweig mit Ihrer Fedora-Umgebung, da er ohne Bezugnahme auf LIBUSBX_API_VERSION wird. Wenn es funktioniert, sind wir hier in Ordnung, wenn nicht , ist die Inkompatibilität mit Fedora schon ziemlich lange vorhanden, da LIBUSBX_API_VERSION früher sowieso nur auf FreeBSD-Systemen aufgerufen werden konnte (wo es nicht mehr benötigt wurde, wie wir fanden zuvor in #782).

1.0.23 jetzt auf Fedora-Rohhaut gepusht https://src.fedoraproject.org/rpms/libusbx/c/5684853d449b7fe3a81112cd59f9336fbc274319?branch=master

Das sind gute Nachrichten für uns.

Ähnliches Ergebnis für Fedora 30 (älteste unterstützte Version):
Hier ist es trotz des (falschen) Paketnamens libusb 1.0.22: https://src.fedoraproject.org/rpms/libusbx/c/cbd5348ee14638264fe3bb79c3b27a5ed34271ed?branch=f30

Man kann daraus schließen, dass dies in Fedora 31 gleichermaßen geschieht, also sind wir hier in Ordnung. Das ist der Grund _warum_ es derzeit auch ohne LIBUSBX_API_VERSION Reste funktioniert. :+1:

@lhondareyte @DanielO : Es scheint, dass Sie beide FreeBSD verwenden (oder verwendet haben). Können Sie uns einige Informationen zu den libusb -Versionen geben, die in den letzten Releases (11, 12, 13) vorhanden sind? pkgs.org war in dieser Hinsicht nicht sehr hilfreich.

Hallo,
Für FreeBSD ist libusb im Basissystem, es ist kein Paket. Es ist kompatibel mit libusb1 & 2 . Weitere Informationen erhalten Sie mit "pkconf":
pkgconf --libs --cflags libusb-1.0
pkgconf --libs --cflags libusb-2.0
pkgconf ist, soweit ich weiß, spezifisch für FreeBSD.
Ich hoffe das hilft.
Grüße

@lhondareyte : Danke für das nützliche Feedback. Welche FreeBSD-Version/Release verwenden Sie? Kannst du auch den Entwicklungszweig auschecken und die Stlink-Tools testweise kompilieren? Damit könnten wir eine mögliche Regression ausschließen, wenn wir die zugehörige PR zusammenführen. Mittlerweile scheinen aktuelle FreeBSD-Releases die einzigen "Unbekannten" zu sein (siehe Liste oben).

Ich verwende die neueste stabile Version (12.1p1) (fast). Ich habe versucht, den neuesten Snapshot zu kompilieren, und es ist tatsächlich fehlgeschlagen:
/usr/home/luc/stlink/src/usb.c:34:22: error: use of undeclared identifier 'INT_MAX'
Die Zusammenstellung funktioniert mit

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

Welchen Commit/Branch möchten Sie genau ausprobieren?

Über FreeBSD Current (neuester Entwicklungszweig) verwende ich es nur auf der ARM-Plattform. Ich werde es dieses Wochenende versuchen: Versuchen Sie einfach, nur zu kompilieren (USB-Unterstützung kann schwierig sein)

Das neuste develop wäre völlig in Ordnung, da wir noch entscheiden müssen, welche Codezeilen hinzugefügt werden müssen, damit es in FreeBSD-Umgebungen kompiliert werden kann. Thx für die Hilfe dabei. :+1:

Für mich sieht es so aus, als hätte sich, abgesehen von sehr wenigen Einzelbeiträgen, vorher noch niemand groß um FreeBSD gekümmert. Beginnend mit v1.6.1 möchte ich sicherstellen, welche Distributionen (inkl. Versionen) funktionieren und dies auch in unsere Dokumentation aufnehmen, um hier die ständigen Probleme "Kompilierung auf xyz-System nicht möglich" zu reduzieren. Ich habe es satt, diese zu sehen.

Ich verstehe, aber mach dir keine Sorgen um FreeBSD: stlink ist im Ports-Tree (na ja, nicht die neueste Version) mit einem aktiven Betreuer. Und die meisten FreeBSD-Benutzer verwenden Ports ;)
Und ich checke regelmäßig den neusten Snapshot auf FreeBSD und macOS (via rudix)
Ich werde es jedoch mit FreeBSD 13 versuchen

... nun, es macht doch Sinn, aktuelle Fixes und Features auch an diese Usergroup zu verteilen, oder? Alte Pakete sind hier keine Hilfe, insbesondere nicht für verfügbare Betreuer auf dieser Plattform.

_Hinweis:_ Indem wir die minimale Versionsanforderung für libusb auf 1.0.20 setzen, könnten wir dies für alle unterstützten Systeme (Windows, macOS und sogar die meisten der ältesten unterstützten Linux/Unix-Distributionen) gleich machen und es somit beibehalten einfach und einprägsam.

Hallo,
Für FreeBSD ist libusb im Basissystem, es ist kein Paket. Es ist kompatibel mit libusb1 & 2 . Weitere Informationen erhalten Sie mit "pkconf":
pkgconf --libs --cflags libusb-1.0
pkgconf --libs --cflags libusb-2.0
pkgconf ist, soweit ich weiß, spezifisch für FreeBSD.

FreeBSD wird mit pkg-config-Dateien für libusb-0.1, libusb-1.0 und libusb-2.0 ausgeliefert (2.0 ist eine FreeBSD-spezifische).
z.B..

[delamerelts 1:44] ~> pkg-config --cflags --libs libusb-0.1
-lusb
[delamerelts 1:44] ~> pkg-config --cflags --libs libusb-1.0
-lusb
[delamerelts 1:45] ~> pkg-config --cflags --libs libusb-2.0
-lusb

Das funktioniert auch unter Linux (bei mir)

[ubuntu 12:17] ~ >pkg-config --cflags --libs libusb-1.0
-I/usr/include/libusb-1.0 -lusb-1.0

Ich denke, wir sollten das neueste libusb verwenden, das wir können. Auf allen Plattformen.

_Hinweis:_ Es gibt einen Unterschied zwischen _funktionierenden_ Versionen und der _erforderlichen Mindestversion_ .
Dies schließt nicht aus, dass Nutzer (durch einen Hinweis in der Dokumentation) angehalten werden sollten, die neueste verfügbare Version auf ihrem jeweiligen System zu installieren. Es bedeutet nur, dass die Tools _noch_ in der Lage wären, mit der ältesten definierten Version zu kompilieren und zu laufen. Unter Ubuntu 16.04 LTS ist beispielsweise 1.0.20 die neueste verfügbare Version, wie Sie in der Liste sehen können (und es wird keine neuere Version für diese Version mehr geben).

@DanielO : Was sind die genauen Versionszeichenfolgen (z. B. 1.0.22 usw.)? Das wäre hier der relevante Punkt...

@DanielO : ja, du hast recht: pkg-config ist ein Link zu pkgconf
@ Nightwalker-87 :
libusb_get_version() gibt 1.0.0.2016 mit diesem Code zurück:

version = libusb_get_version();
printf("%d.%d.%d.%d\n", version->major, \
                        version->minor, \
                        version->micro, \ 
                        version->nano);

uname -r
12.1-RELEASE-p2

@lhondareyte : oO Darum habe ich gebeten, aber es scheint überhaupt nicht zu helfen. Ich habe kein anderes Versionierungsschema erwartet als das, das das libusb-Projekt verwendet ...

libusb definieren LIB_API_VERSION seit v1.0.13, die enthaltene Features beschreiben. Alle Betriebssysteme, die Sie auflisten, haben diese Definition. Warum wollen Sie sich also mit der lib-Version statt der API-Version befassen?
Derzeit definieren alle unterstützten FreeBSD-Versionen (11,12) und aktuelle dies
#define LIBUSB_API_VERSION 0x01000102
Vielleicht vermisse ich etwas, wenn ja, lass es mich wissen.
Mit freundlichen Grüßen

Das LIB_API_VERSION ist hier nicht der relevante Punkt, da es bereits in der Codebasis der stlink-tools verwendet wird. Dies haben wir in #782 behandelt. Jetzt geht es nur noch darum, wie aktuell das Paket libusb _mindestens_ sein muss. Wir können nichts dafür, dass FreeBSD libusb integriert hat und ein anderes Versionierungsschema als das libusb-Projekt verwendet, was es schwierig macht, beide Codebasen miteinander zu vergleichen. Wir können also nicht sagen, dass libusb 1.0.0.2016 auf FreeBSD von dem Paket libusb-1.0.20 des libusb-Projekts oder ähnlichem stammt. Wir können dies für alle anderen Betriebssysteme tun.

In dieser Ausgabe ist das LIBUSBX_API_VERSION das Problem. LIBUSBX_API_VERSION ist in libusb fast als veraltet markiert und existiert nicht auf FreeBSD:

/* The following is kept for compatibility, but will be deprecated in the future */
#define LIBUSBX_API_VERSION LIBUSB_API_VERSION

Das hat nichts mit FreeBSD zu tun. Das Versionierungsschema für API_VERSION ist das gleiche wie bei anderen Betriebssystemen. Und viele Portierungen verwenden ohne Probleme die native FreeBSD-Version.

Was wäre also eine Lösung dafür (außer darauf zu vertrauen, dass es läuft und ohne eine Version auf FreeBSD zu verfolgen)? Ich fühle mich dabei unwohl, da man sich diesen Sonderfall jedes Mal ansehen müsste, wenn eine neue Version auf FreeBSD veröffentlicht wird, und es manuell testen müsste.

Ich werde einen Blick darauf werfen. Kurz gesagt, jeder Verweis auf LIBUSBX_API_VERSION sollte aus dem stlink -Code entfernt werden.
Kennen Sie die minimale API_VERSION, die mit stlink funktioniert? In der Tat, welche Funktionen benötigen Sie?
Aber es kommt mir seltsam vor, dass Sie so viel Zeit für Ubuntu 12.04 aufwenden, das seit 2017 nicht mehr unterstützt wird

Ich werde einen Blick darauf werfen. Kurz gesagt, jeder Verweis auf LIBUSBX_API_VERSION sollte aus dem stlink -Code entfernt werden.

Dies ist bereits im develop -Zweig der Fall, da ich dieses veraltete Zeug loswerden wollte.

Kennen Sie die minimale API_VERSION, die mit stlink funktioniert? In der Tat, welche Funktionen benötigen Sie?

Nein, habe ich nicht, aber das ist es, wonach ich suche. Wenn wir die LIBUSB_API_VERSION des 1.0.20-Pakets herausfinden können, können wir sie mit der in FreeBSD vergleichen. Vielleicht ist das ein weiterer Ansatz, um festzustellen, woher die Codebasis stammt.

All diese Unbekannten, mit denen wir uns bisher auseinandergesetzt haben, möchte ich nicht mehr sehen. Da wir mehrere Tickets im Zusammenhang mit libusb-Problemen haben, hilft es nicht, dies nicht klar definiert zu haben. Ich habe das Gefühl, dass dies die Wartung in diesem Projekt behindert.

Ich habe eine Bestandsaufnahme der neuesten offiziellen Veröffentlichungen erstellt:

• 1.0.12 und höher definieren *API_VERSION nicht
• 1.0.13 bis 1.0.17 definieren nur LIBUSBX_API_VERSION
• seit 1.0.18 sind sowohl LIBUSB_API_VERSION als auch LIBUSBX_API_VERSION wie folgt definiert

define LIBUSB_API_VERSION 0x010001xx
define LIBUSBX_API_VERSION LIBUSB_API_VERSION

LIBUSBX_API_VERSION erschien in 1.0.13 und LIBUSB_API_VERSION in 1.0.18

Eine einfache Lösung könnte für alle Betriebssysteme sein:

#include <libusb.h>

#if !defined ( LIBUSBX_API_VERSION )
 #if defined (__FreeBSD__)
   #define LIBUSBX_API_VVERSION LIBUSB_API_VERSION
 #elif !defined (LIBUSB_API_VERSION)
   #error unsupported libusb version
 #endif
#endif

#define MINIMAL_API_VERSION 0x01000102

#if ( LIBUSB_API_VERSION < MINIMAL_API_VERSION )
 #error unsupported libusb version
#endif

Ok auf FB12 und macOS10.14

Über LIBUSBX_API_VERSION / LIBUSB_API_VERSION :

v1.0.13 : 0x01000100
v1.0.14 : 0x010000FF
v1.0.15 : 0x01000101
v1.0.16 : 0x01000102
v1.0.17 : 0x01000102
v1.0.18 : 0x01000102
v1.0.19 : 0x01000103
v1.0.20 : 0x01000104
v1.0.21 : 0x01000105
v1.0.22 : 0x01000106
v1.0.23 : 0x01000107

@lhondareyte : Ausgezeichnet, und was ist der String LIBUSB_API_VERSION , der auf jedem FreeBSD 11, 12, 13 vorhanden ist? Kann man das irgendwo im Netz nachlesen? Damit sind wir endlich in der Lage, diese Informationen über den mühseligen Weg zu bekommen... Ich kann dann die obige Auflistung vervollständigen und eine endgültige Entscheidung treffen.

Sie sind alle 0x01000102:
11.0.0 – https://svnweb.freebsd.org/base/release/11.0.0/lib/libusb/libusb.h?revision=354337&view=markup#l38
12.1.0 – https://svnweb.freebsd.org/base/release/12.1.0/lib/libusb/libusb.h?revision=354337&view=markup#l38
Kopf - https://svnweb.freebsd.org/base/head/lib/libusb/libusb.h?revision=326219&view=markup#l38

Es hat sich nicht geändert, seit #define in r301957 hinzugefügt wurde
https://svnweb.freebsd.org/base/head/lib/libusb/libusb.h?revision=301957&view=markup

@DanielO : Danke fürs Überprüfen! Bitte teilen Sie uns mit, wenn sich dies eines Tages ändert.

ok, also müssen wir aus Kompatibilitätsgründen für FreeBSD eigentlich bei libusb 1.0.16 ... 1.0.18 codebase bleiben. In Bezug auf die Implementierung werden wir hier wahrscheinlich nach 0x01000102 in cmake suchen.

Ich werde eine neue Tabelle für unsere Dokumentation erstellen, die alles auflistet, was wir bisher herausgefunden haben.

@slyshykO : Können Sie Ihre PR #895 um den besprochenen Check für Windows erweitern und vielleicht auch die cmake-Routine für FreeBSD aktualisieren?

Ich habe #895 aktualisiert. Bitte werfen Sie einen Blick darauf.