Ich musste gerade etwas rumprobieren bis ich endlich geschafft habe ein Korad 3005P unter Linux anzusteuern. Vielleicht interessiert das ja noch jemand anderes. .-) Das Korad KA3005P hat keinen normalen USB-RS232 Adapter eingebaut. Es wird stattdessen ein 8051 kompatibler Microcontroller von Nuvoton verwendet. (Typenbezeichnung ist aber abgeschliffen) Dieser Controller emuliert ein USB-CDC device. Deshalb besteht der Windows treiber nur aus einem inf-File welcher das System auffordert usbser.sys zu verwenden. Auch Linux hat einen solchen treiber, der das Korad aber nicht richtig erkennt. So meldet sich das Korad KA3005P am USB-Bus nach dem einschalten: kernel: usb 1-2.2: new full-speed USB device number 12 using ehci-pci kernel: usb 1-2.2: New USB device found, idVendor=0416, idProduct=5011 kernel: usb 1-2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 kernel: usb 1-2.2: Product: USB Virtual COM kernel: usb 1-2.2: Manufacturer: USB Vir kernel: usb 1-2.2: SerialNumber: NT2009101400 Man kann dem entnehmen wie die VID und PID ist, und das derzeit noch kein Treiber geladen wurde. Wir muessen uns nun eine Datei "/etc/udev/rules.d/91-korad.rules" mit folgenden Inhalt erstellen: ACTION=="add", ATTRS{idVendor}=="0416", ATTRS{idProduct}=="5011", RUN+="/bin/sh -c 'echo 0416 5011 > /sys\ /bus/usb-serial/drivers/generic/new_id'", SYMLINK+="korad" Danach muss der udev angewiesen werden seine Konfiguration neu einzulesen: udevadm control --reload-rules && udevadm trigger Schaltet man jetzt das Korad ein so wird ein neues Device angelegt und ein link /dev/korad darauf angelegt. Es ist nun moeglich z.B mit Minicom dieses Device zu oeffnen: Dort senden: *IDN? Antwort: KORADKA3005PV2.0 Senden: OUT1 Ausgangsspannung wird eingeschaltet. Senden: VOUT1? Antwoert: 12.00 Senden: OUT0 Ausgangsspannung wird abgeschaltet. Ab jetzt ist die erstellung eines eigenen Programm zur Ansteuerung des Netzteils eine leichte uebung welche ich dem geneigten Leser ueberlasse. (wollte ich schon immer mal sagen) Olaf
> Schaltet man jetzt das Korad ein so wird ein neues Device angelegt und > ein link /dev/korad darauf angelegt. Prinzipiell ja, greift aber zu kurz wenn man 2 Korad anschließt.
> Prinzipiell ja, greift aber zu kurz wenn man 2 Korad anschließt.
Darum kann ich mich ja immer noch kuemmern wenn es soweit ist.
Ich denke aber das ich bis auf weiteres mit einem Netzteil auskomme.
War schon genug Aufwand rauszubekommen wie das Teil ueber USB seine
Schnittstelle realisiert. Ich war schon kurz davor einen ESP8266
einzubauen und das Teil ueber UDP anzusteuern. :)
Olaf
Ist zwar erstmal ein ziemlich wilder Hack, aber das groebste geht schon. :-) Qt macht schon Spass.... Olaf
Angehängte Dateien:
-
test3.gif
26 KB
Man kann sogar alle 50ms den aktuellen Ausgangsstrom auslesen. Das ist ja mal ganz nuetzlich... Olaf
Hallo Olaf, hast Du geplant, Dein Programm Interessenten zur Verfügung zu stellen?
Angehängte Dateien:
-
test4.gif
36 KB
> hast Du geplant, Dein Programm Interessenten zur Verfügung zu stellen?
Nein, eigentlich nicht. Das ist bei Linux zu komplex geworden
weil Software nicht mehr auf jedem System einfach so laeuft
da es zuviele unterschiedliche Librayversionen und sonstige
Abhaengikeiten gibt.
Und ich meine Qt kann auch nicht statisch linken ohne das man vorher
einen riesen Aufwand treibt.
Ist aber eigentlich Schade, ich habs gerade noch etwas verbessert. :)
Olaf
> Das ist bei Linux zu komplex geworden weil Software nicht mehr auf > jedem System einfach so laeuft da es zuviele unterschiedliche > Librayversionen und sonstige Abhaengikeiten gibt. Gerade bei Linux ist das einfach: Ordentlich programmieren, Source code verteilen, freuen. Unter Winblöd ist das erfahrungsgemäß wesentlich nerviger.
Olaf schrieb: >> hast Du geplant, Dein Programm Interessenten zur Verfügung zu > stellen? > > Nein, eigentlich nicht. Das eigene Programm zeigen aber nicht zur verfügung stellen... Du sagst damit quasi "Schaut mal, was ihr nicht haben könnt!". Sowas macht man eigentlich nicht.
> "Schaut mal, was ihr nicht haben könnt!". Das ist aber Interpretationssache. :) Ich dachte eher ihr freut euch zu sehen das es relativ einfach ist das Teil ueber usb anzusteuern. Das geht sogar erstaunlich schnell. Das Programm vermittelt am PC das Gefuehl direkt am Netzteil zu sitzen. > Sowas macht man eigentlich nicht. Wenn du dich besser fuehlst haenge ich es dir mal an. Wuerde mich aber wundern wenn es ausserhalb meines Systems laeuft. Vermutlich kommen da sofort ein halbes Dutzend beschwerden weil bei dir irgendwelche Libaries nicht vorhanden oder auf einem anderen Versionsstand sind. Olaf p.s: Es ist zwingend notwendig das /dev/korad wie in meinem ersten Posting beschrieben, existiert!
Hallo Olaf, erst mal herzlichen Dank für die Datei. Natürlich ist Dein Weg - und die Screenshots als Appetitanreger - recht motivierend, aber nicht jeder muss unbedingt das Rad neu erfinden. Mir persönlich gefällt Dein sich steig entwickelndes Programm sehr gut, und es könnte für Linux- und Korad-Nutzer ein wertvolles Werkzeug sein. Du wirst wohl recht haben, das es recht viele Schwierigkeiten mit dem ZIP-File geben könnte, nachdem es sich um ein Binary handelt. Für die individuelle Anpassung wären die Sourcen leichter anzupassen. Es ist aber Deine Entscheidung, ob Du diese freigeben willst.
:
Bearbeitet durch User
> Wuerde mich aber wundern wenn es ausserhalb meines Systems laeuft.
Hättest Du meinen Kommentar oben richtig gelesen hättest Du den
Quellcode eingepackt und nicht irgendein plattformabhängiges Binary.
Ersterer funktioniert(tm) wahrscheinlich(tm) problemarm(tm), letzteres
will kein normaldenkender Mensch freiwillig ausführen.
olaf schrieb: > Wenn du dich besser fuehlst haenge ich es dir mal an. Wuerde mich aber > wundern wenn es ausserhalb meines Systems laeuft. Ist schon in Ordnung, das war eher als "für nächstes mal" gedacht. Ein Binary ist für einige sicher auch OK. Ich verwende aber nur noch Anwendungen, wo ich den Quellcode dazu habe. Mal sehen, gegen was es gelinkt ist:
1 | /opt/korad$ file korad |
2 | korad: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=c1ecc370e7661866aca27c30c50f09abb5d63c7a, stripped |
3 | /opt/korad$ ldd korad |
4 | linux-vdso.so.1 => (0x00007ffff255d000) |
5 | libqwt.so.6 => not found |
6 | libQt5Widgets.so.5 => not found |
7 | libQt5Gui.so.5 => not found |
8 | libQt5SerialPort.so.5 => not found |
9 | libQt5Core.so.5 => not found |
10 | libGL.so.1 => not found |
11 | libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fae74950000) |
12 | libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fae745c0000) |
13 | libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fae742a0000) |
14 | libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fae74080000) |
15 | libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fae73cb0000) |
16 | /lib64/ld-linux-x86-64.so.2 (0x00007fae74e00000) |
Die libc sachen sind auf dem Ubuntu schon drauf. Auf dem System hier hab ich leider gerad keine grafische Oberfläche, deshalb hab ich qt noch nicht installiert. 6 Libraries sind aber keine grosse Sache. Mal sehen:
1 | /opt/korad$ apt-file search libqwt.so.6 |
2 | libqwt6abi1: /usr/lib/libqwt.so.6.1.2.abi1 |
3 | libqwt6abi1: /usr/lib/libqwt.so.6abi1 |
4 | /opt/korad$ apt-file search libQt5Widgets.so.5 |
5 | libqt5widgets5: /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 |
6 | libqt5widgets5: /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.5 |
7 | libqt5widgets5: /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.5.1 |
8 | /opt/korad$ apt-file search libQt5Gui.so.5 |
9 | libqt5gui5: /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5 |
10 | libqt5gui5: /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.5 |
11 | libqt5gui5: /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.5.1 |
12 | libqt5gui5-gles: /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5 |
13 | libqt5gui5-gles: /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.5 |
14 | libqt5gui5-gles: /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.5.1 |
Die Libraries sind also gröstenteils da, nur vereinzelt (bei libqwt6abi1), könnte mann das mit nem symlink lösen, also soweit kein problem. Es wäre natürlich schöner, wenn das statisch gelinkt wäre, und nur die qt libraries dynamisch, man könnte dann statische qt libraries mitliefern und beim Kompilieren den RUNPATH/RPATH entschprechend setzen, damit es überall läuft. Linux experten wie ich können das aber nachträglich noch hinbiegen, ist nur etwas aufwendiger. Ein paar unterverzeichnisse anlegen:
1 | /opt/korad$ mkdir bin |
2 | /opt/korad$ mkdir lib |
3 | /opt/korad$ mv korad bin/ |
RUNPATH patchen, damit es im lib verzeichnis über dem binari nach den libs sucht, und libs kopieren:
1 | /opt/korad$ chrpath -l bin/korad |
2 | bin/korad: no rpath or runpath tag found. |
3 | /opt/korad$ patchelf --set-rpath '$ORIGIN/../lib' bin/korad |
4 | /opt/korad$ chrpath -l bin/korad |
5 | bin/korad: RUNPATH=$ORIGIN/../lib |
6 | /opt/korad$ cp /lib/x86_64-linux-gnu/libpthread.so.0 /usr/lib/x86_64-linux-gnu/libstdc++.so.6 /lib/x86_64-linux-gnu/libm.so.6 /lib/x86_64-linux-gnu/libgcc_s.so.1 /lib/x86_64-linux-gnu/libc.so.6 /lib64/ld-linux-x86-64.so.2 lib/ |
Optional den Interpreter ändern, damit auch dort die in lib/ verwendet wird. Leider geht "$ORIGIN" hier vermutlich nicht, da das von der libc interpretiert wird, warend .interp schon vorhär vom kernel interpretiert wird. Ich kann es auf "../lib/ld.so" ändern, aber das geht nur, wen man es von bin/ aus startet:
1 | /opt/korad$ patchelf --set-interpreter '../lib/ld-linux-x86-64.so.2' bin/korad |
Jetzt platziere ich statdessen ein Wrapperscript, das das Programm dan startet. Ich könnte einfach vorher cd nutzen, aber das ist nicht ideal, weil das Programm dann nicht in anderen CWDs gestartet werden kann. Ich kann den Interpreter/dynamic linker/loader/.interp/ld.so aber auch explizit aufrufen und das Programm laden lassen, was beide Probleme löst:
1 | /opt/korad$ cd bin/ |
2 | /opt/korad/bin$ mv korad korad_real |
3 | /opt/korad/bin$ cat > korad <<EOF |
4 | #!/bin/sh |
5 | |
6 | dir="\$(dirname "\$0")" |
7 | |
8 | "\$dir/../lib/ld-linux-x86-64.so.2" "\$dir/korad_real" "\$@" |
9 | EOF |
Nochmal die Dependencies ausgeben (hier sieht man auch schön, warum ldd bei unbekannten Binaries unsicher ist):
1 | /opt/korad$ LD_TRACE_LOADED_OBJECTS= ./lib/ld-linux-x86-64.so.2 ./bin/korad_real |
2 | linux-vdso.so.1 => (0x00007fffccef1000) |
3 | libqwt.so.6 => not found |
4 | libQt5Widgets.so.5 => not found |
5 | libQt5Gui.so.5 => not found |
6 | libQt5SerialPort.so.5 => not found |
7 | libQt5Core.so.5 => not found |
8 | libGL.so.1 => not found |
9 | libpthread.so.0 => /opt/korad/./bin/../lib/libpthread.so.0 (0x00007fea73820000) |
10 | libstdc++.so.6 => /opt/korad/./bin/../lib/libstdc++.so.6 (0x00007fea73490000) |
11 | libm.so.6 => /opt/korad/./bin/../lib/libm.so.6 (0x00007fea73170000) |
12 | libgcc_s.so.1 => /opt/korad/./bin/../lib/libgcc_s.so.1 (0x00007fea72f50000) |
13 | libc.so.6 => /opt/korad/./bin/../lib/libc.so.6 (0x00007fea72b80000) |
14 | ../lib/ld-linux-x86-64.so.2 => ./lib/ld-linux-x86-64.so.2 (0x00007fea73e00000) |
Fehlen nurnoch die statischen QT libraries. Das muss ich aber auf's Wochenende verschieben. Da wo ich gerade bin funkt mir eine Firewall beim git clone dazwischen, und heute Abend kommt noch mein librem5-devkit an, da hab ich keine Zeit. Theoretisch könnte man statt statisch zu linken oder die Libs einzeln herauszusuchen auch Container verwenden, deshalb sind Docker, Snap und co. bei Firmen so beliebt. Wenn dieses Kapitalismus- & Geheimhaltungsmentalität nicht überall wäre, wäre die Wellt ein besserer Ort.
DPA schrieb: > Ist schon in Ordnung, das war eher als "für nächstes mal" gedacht. Ein > Binary ist für einige sicher auch OK. Ich verwende aber nur noch > Anwendungen, wo ich den Quellcode dazu habe. > > Mal sehen, gegen was es gelinkt ist: > .. Danke, sehr lehrreich! (soooo tief stecke ich in Linux scheinbar doch nicht drin...) Bitte weiter so.
Beitrag #5673340 wurde von einem Moderator gelöscht.
Hast du dir schon mal sigrok in Verbindung mit smuview angeschaut? https://sigrok.org/ https://github.com/knarfS/smuview Damit kannst du den KA3005 auch steuern und musst das Rad nicht neu erfinden. Bonus: Es unterstützt nicht nur den KA3005, sondern diverse Geräte.
> Es wäre natürlich schöner, wenn das statisch gelinkt wäre, und nur die > qt libraries dynamisch, man könnte dann statische qt libraries Das denke ich auch gelegentlich. Aber soweit ich weiss, mal irgendwo gelesen hab, ist es nicht damit getan mal nur irgendwo einen Compilerschalter zu setzen. Man muss dazu wohl angeblich Qt selber compilieren um die Libaries zu erzeugen. Und das ist mir dann ein bisschen zuviel Aufwand. Olaf
Und warum veröffentlichst du nicht einfach den Sourcecode? Das wäre für alle Parteien das einfachste.
> Und warum veröffentlichst du nicht einfach den Sourcecode?
Weil ich das einfach nicht moechte.
Aber eigentlich wollte ich noch auf eine interessante negative
Eigenschaft
von dem USB-Anschluss am Netzteil hinweisen.
Wenn ich mein Programm laufen habe dann findet ein dauerhafter
Datenaustausch mit dem Netzteil statt. Solange das der Fall ist, ist die
Eingabe direkt am Geraet gesperrt. Das ist eigentlich auch okay so und
kennt man ja von diversen anderen Messgeraeten an HPIB auch.
Aber wenn man das Netzteil einfach nur einschaltet ohne das ich es
fernsteuern moechte dann verbindet es sich ueber USB mit dem Computer,
der Computer richtet wie im ersten Posting angeben einen Zugriff ein und
dabei scheinen auch schon Daten mit dem Netzteil ausgetauscht zu werden.
Das fuehrt dann dazu das das Netzteil fuer 10-20s nach dem einschalten
nicht bedienbar ist. Erst nach Ablauf der Zeit troetet es einmal kurz
und ist dann normal von Hand bedienbar. Das ist natuerlich etwas
unschoen wenn man das USB-Kabel dauerhaft drin lassen will.
Olaf
Olaf schrieb: > und dabei scheinen auch schon Daten mit dem Netzteil ausgetauscht zu > werden. Das dürfte die unsägliche Plug&Play-Unterstützung für serielle Mäuse sein, die Windows aus unerfindlichen Gründen immer noch mitbringt.
Rufus Τ. F. schrieb: > Olaf schrieb: >> und dabei scheinen auch schon Daten mit dem Netzteil ausgetauscht zu >> werden. > > Das dürfte die unsägliche Plug&Play-Unterstützung für serielle Mäuse > sein, die Windows aus unerfindlichen Gründen immer noch mitbringt. Er nutzt aber Linux. Und selbst unter Windows könnte man das deaktivieren.
Christian R. schrieb: > Er nutzt aber Linux. Hmm. Das hab' ich dann wohl übersehen. Aber warum sollte Linux "einen Zugriff" einrichten?
Rufus Τ. F. schrieb: > Christian R. schrieb: >> Er nutzt aber Linux. > > Hmm. Das hab' ich dann wohl übersehen. Aber warum sollte Linux "einen > Zugriff" einrichten? Wäre mir auch neu, dass udev irgendwas tut. Meiner Erfahrung nach öffnet das nicht mal die Schnittstelle. Es muss also sein Programm sein, was mindestens die Schnittstelle öffnet.
> Er nutzt aber Linux. Und selbst unter Windows könnte man das > deaktivieren. yo, das tut er. :) Linux muss an der Stelle aber nicht besser sein. Es kann z.B sein das da irgendein getty drauf laeuft und dem "user" die uebliche Begruessungsmelung schickt sobald ein neuer Port auftaucht. Muss ich bei Gelegenheit mal nachgehen wenn es mich genug genervt hat. Olaf
olaf schrieb: > Linux muss an der Stelle aber nicht besser sein. > Es kann z.B sein das da irgendein getty drauf laeuft und dem "user" die > uebliche Begruessungsmelung schickt sobald ein neuer Port auftaucht. Zumindest auf sysvinit systemen muss man das explizit für jedes tty in der /etc/inittab eintragen. Standardmässig sind dort normalerweise nur /dev/tty[1-6] eingetragen, und die kommen eigentlich immer von fbcon.
Hallo Olaf, wenn du dein Programm als binär Version verteilen willst, dann kannst du das am besten als AppImage machen. Speziell für Qt gibt es dafür linuxdeployqt (https://github.com/probonopd/linuxdeployqt), welches das Erstellen eines AppImages wirklich sehr einfach macht! Das AppImage erstellst du am besten unter einer alten Linux Distribution (z.B. Ubuntu 14.04 LTS), damit es auf so vielen Systemen wie möglich läuft. Ich bin der Autor vom oben erwähnten SmuView (https://sigrok.org/wiki/SmuView), von dem es jetzt auch Binaries für Windows und Linux gibt: https://github.com/knarfS/smuview/releases Für die AppImages habe ich ebenfalls linuxdeployqt verwendet. Der nächste Meilenstein für SmuView wird eine Automatisierung der verbundenen Geräte sein. Damit kannst du dann komplexe Messungen mit mehrere Geräten vornehmen und z.B. DC-to-DC Converter charakterisieren. Ich hoffe das hilft dir beim Qt/C++ entwickeln weiter. Viele Grüße Frank
Ich hoffe Du benutzt die kommerziele Version Qt, ansonsten muss doch der Code offen liegen oder verstehe ich Lizenzbestimmungen falsch?
Dirk schrieb: > Ich hoffe Du benutzt die kommerziele Version Qt, ansonsten muss doch der > Code offen liegen oder verstehe ich Lizenzbestimmungen falsch? Bei der LGPL darfst du dynamisch gegen die Library linken, ohne den Code offenlegen zu müssen. Anders würde es aussehen, wenn es statisch gegen QT gelinkt wäre, was hier aber nicht der fall ist. Bezüglich welche version, da kein qt code mithochgeladen wurde, keine. Wäre qt unter der gpl statt der lgpl, würde es anders aussehen.
Da SmuView unter der GPLv3 lizenziert ist, sind die statisch gelinkten Windows Executables kein Problem. Wie es aber aussieht, wenn Olaf seine Closed Source Software als AppImage verteilt (im AppImage befinden sich alle notwendigen Qt Libraries), kann ich nicht sagen.
:
Bearbeitet durch User
> Wie es aber aussieht, wenn Olaf seine Closed Source Software als > AppImage verteilt https://www.qt.io/licensing/ BTW: Ganz schoen dreist teuer so eine kommerzielle Lizenz. Faengt ab 459$ pro Monat an. Einmalig scheint mir das ja durchaus okay zu sein, aber jeden Monat? Olaf
Olaf schrieb: >> Wie es aber aussieht, wenn Olaf seine Closed Source Software als >> AppImage verteilt > > https://www.qt.io/licensing/ Der Link hilft bei der Fragestellung überhaupt nicht weiter. Wenn dann hättest du die für den Fall gültige Lizenz verlinken müssen: https://www.gnu.org/licenses/lgpl-3.0.de.html Ich traue mich aber trotzdem nicht eine Aussage bzgl. Closed Source und AppImage zu treffen. > BTW: Ganz schoen dreist teuer so eine kommerzielle Lizenz. Faengt ab > 459$ pro Monat an. Einmalig scheint mir das ja durchaus okay zu sein, > aber jeden Monat? Nein, für den gebotenen Umfang und im Vergleich zu anderen Frameworks ist der Preis im Rahmen.
:
Bearbeitet durch User
Olaf schrieb: >> Wie es aber aussieht, wenn Olaf seine Closed Source Software als >> AppImage verteilt > > https://www.qt.io/licensing/ > > BTW: Ganz schoen dreist teuer so eine kommerzielle Lizenz. Faengt ab > 459$ pro Monat an. Einmalig scheint mir das ja durchaus okay zu sein, > aber jeden Monat? > > Olaf Es gibt aber quasi keine Umstände, unter denen du die kommerzielle Lizenz brauchst, zumindest wenn du nur die LGPL-Module verwenden willst. Auch wenn die Webseite versucht, es anders darzustellen, brauchst du die eigentlich nur, wenn du modifizierte Versionen des Frameworks als Closed Source verteilen willst. Selbst statisch linken geht LGPL-kompatibel, wenn man unbedingt will ... man muss dann eben die Linker-Befehlszeile und die Object Files mitverteilen. AppImage sollte kein Problem sein, wer paranoid ist kann ja ein Shellskript beilegen, was das Image extrahiert, die .so-Dateien austauscht, und neu packt. Das ist auf jeden Fall LGPL-kompatibel.
Sven B. schrieb: > AppImage sollte kein Problem sein, wer paranoid ist kann ja ein > Shellskript beilegen, was das Image extrahiert, die .so-Dateien > austauscht, und neu packt. Das ist auf jeden Fall LGPL-kompatibel. Daran habe ich nicht gedacht, aber das erfüllt auf jeden Fall die Forderungen der LGPL.
olaf schrieb: > Man muss dazu wohl angeblich Qt selber > compilieren um die Libaries zu erzeugen. Und das ist mir dann ein > bisschen zuviel Aufwand. Wenn es das nur ist ... Welche Qt Version darf es denn sein? Du Verwendest Ubuntu, oder? Wenn das schöne Programm am Ende für uns alle nutzbar wird, dann will ich das Bereitstellen einer statischen Lib für Win und Linux gerne machen. VG Jörg
> Es gibt aber quasi keine Umstände, unter denen du die kommerzielle > Lizenz brauchst, zumindest wenn du nur die LGPL-Module verwenden willst. Ich brauche die sicherlich nicht. Aber wenn man so eine kleine 5-10personen Entwicklerbude ist dann kann man sich sicher auch mal einmal fuer ein paar Tausend Euro so eine Lizenz kaufen, aber jeden Monat 500Kroeten rueberschieben ist schon eine Menge. > Welche Qt Version darf es denn sein? Du Verwendest Ubuntu, oder? Centos 7.4 64Bit. Olaf
Olaf schrieb: >> Es gibt aber quasi keine Umstände, unter denen du die kommerzielle >> Lizenz brauchst, zumindest wenn du nur die LGPL-Module verwenden willst. > > Ich brauche die sicherlich nicht. Aber wenn man so eine kleine > 5-10personen Entwicklerbude ist dann kann man sich sicher auch mal > einmal fuer ein paar Tausend Euro so eine Lizenz kaufen, aber jeden > Monat 500Kroeten rueberschieben ist schon eine Menge. Auch die Entwicklerbude braucht die Lizenz nicht. Für was denn?
Noch mal zurück zu der seriellen Schnittstelle, die beim Einstecken des USB Kabels (unbeabsichtigt) etwas auszugeben scheint. Unter openSUSE ist daran meist der ModemManager schuld: https://www.freedesktop.org/wiki/Software/ModemManager/
DPA schrieb: > Fehlen nurnoch die statischen QT libraries. Dynamisch QT Libraries zu erstellen, die gegen alle anderen Libraries statisch gelinken sind, ist doch aufwendiger, als ich zunächst dachte. Die -static-runtime option funktioniert nur unter Windows, und das zeug brauch Stunden für jeden Build. Ich experimentiere gerade mit wrapper scripts für gcc und den -Bstatic + -Bdynamic Optionen, um die Menge externer Libraries zu reduzieren.
Was ist'n jetzt mit dem Source? Dein ausführbares Kompilat interessiert keinen Mensch. Wir sind Techies und Frickler und keine doofen "Windows Power User".
Nur für den Fall, dass es nicht für alle offensichtlich war: Ich bin nicht der TO und habe somit die sourcen nicht.
Weiß ich. Ich dachte eigentlich, der Thread-Eröffner reagiert und präsentiert, ähem... dem geneigten Leser den Code, den er ihm, wenn ich das richtig verstanden habe... mit Loriot-artigem Duktus - ja sowieso schon immer mal überlassen wollte...
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.