Forum: Projekte & Code Fuseeditor, grafische Benutzeroberfläche für AVRdude


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von R. M. (Gast)


Angehängte Dateien:

Bewertung
2 lesenswert
nicht lesenswert
Hallo zusammen!
Bisher hab ich zum Einstellen der Fuses, gern den AVR-Burn-O-Mat 
genutzt:
http://avr8-burn-o-mat.aaabbb.de/avr8_burn_o_mat_avrdude_gui_en.php
https://www.mikrocontroller.net/articles/Burn-o-mat
Dieses Projekt wird allerdings anscheinend vom Entwickler nicht mehr 
weiter verfolgt, hier im Forum wurde bereits von Teilnehmern die Konfig 
weiter gepflegt, allerdings funktioniert die Abbildung der Funktionen zu 
den Fuses nur mit hart kodierten Modellen, lediglich die BOD-Funktion 
lässt sich über die Konfig modellieren. Daher hab ich das Programm mal 
angefangen nachzubauen.
Hier lässt sich für jeden Controller individuell die Bedeutung der Fuses 
zu den Funktionsgruppen abbilden.
Habe dies in der Konfig bereits für den Mega8 und Mega48 getan. Wenn 
alles so passt, dann kopiere ich dieses Modell in alle Controller, die 
auf diese Modelle verweisen und lege die restlichen Modelle neu an.
Das Programm ist in C/C++ geschrieben, nutzt FLTK und sollte unter 
Windows und Linux funktionieren. Im win32bin-Archiv befinden sich die 
erforderlichen MinGW-Dlls, im Source-Archiv, befinden sich die Scripte, 
mit welchen das Programm compiliert wurde. Selbst benutze ich Linux, hab 
das Programm aber erfolgreich unter WinXP und Win7/64 getestet.
mfG

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Bewertung
0 lesenswert
nicht lesenswert
Oh, das klingt gut!
Beim AVR Dude muss man ja inzwischen auch schon an der Config spielen zB 
für den neusten Mega88.

Aber wieso haste dann nicht den Burn-O-Mat Sourcecode weitergepflegt, 
sondern nachgebaut?

von R. M. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Der ist in Java geschrieben, da müsste ich mich erstmal reinarbeiten, 
außerdem ist er so schon schwerfällig genug...
Ein Hinweis noch: Prio hat für mich bisher der Fuseeditor, die "banalen" 
Funktionen für Flash/EEPROM funktionieren zwar, aber man hat keine 
Fortschrittsanzeige, die Ausgabe vom AVRdude erscheint erst, wenn er 
fertig ist, also nicht ungeduldig werden! Vielleicht kriege ich es hin, 
die Ausgabe von stderr (dorthin schreibt dude nämlich auch die 
Gutmeldungen) in eine Pipe umzuleiten um sie so, unverzüglich zur 
Ausgabe zu bringen.
Das Lesen/Schreiben der Fuses geht ja so schnell, das es dort nicht 
nötig ist.
mfG

von R. M. (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hab jetzt die gängigsten Typen vervollständigt. Hoffentlich nicht 
allzuviele Fehler drin,
mfG

von R. M. (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So, die Ausgaben vom AVRDUDE werden jetzt life im Ausgabefenster 
angezeigt.
In der aktuellen XML (in beiden Archiven enthalten) sind die aktuellen 
Käfer jetzt komplett. Sollte Korrektur/Erweiterungsbedarf bestehen, dann 
bitte melden!
mfG

von R. M. (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Einen Fehler hab ich noch gefunden: bei EEPROM-Operationen wurde 
fälschlicherweise der unter Flash eingetragene Dateiname genutzt. Ist 
jetzt korrigiert. Desweiteren hab ich den voreingestellten Wert für die 
Dropdown-Felder mit dem Dateiformat von auto auf intel-hex geändert, da 
ich hier Probleme mit dem avrdude bei Auslesen und auto-format habe.
mfG

von Juan (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,
an die Linux Experte, wie starte ich das Program?

von R. M. (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Juan,

erstmal muss das Programm compiliert werden, dazu benötigt wird der gcc 
(auf den meisten Linuxen schon vorhanden), und die FLTK-Bibliothek.
Auf Debian/Ablegern, installiert man die mit

sudo apt-get install libfltk1.3-dev
sudo apt-get install libx11-dev

in anderen Distributionen wird die Vorgehensweise ähnlich sein.

jetzt im src-ordner das "c"-script ausführen
./c
dann steht das Kompilat im gleichen Ordner und kann mit

./fuseedit
gestartet werden. Wie man zum bequemen Start dann eine 
Desktopverknüpfung oder einen Startmenüeintrag anlegt, hängt von der 
Distribution ab.

Im Archiv befindet sich bereits eine kompilierte Programmdatei von 
Ubuntu 16.04. Wer selbiges nutzt und sich das selbstkompilieren sparen 
möchte,
kann die Libs aus dem Anhang auspacken und nach 
/usr/lib/x86_64-linux-gnu verschieben (root-rechte erforderlich), ich 
empfehle aber die erstere Vorgehensweise

https://de.wikipedia.org/wiki/Fast_Light_Toolkit

mfG

Edit: da war was beim Kopieren verloren gegangen

von R. M. (Gast)


Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
Hab mal versucht, die noch fehlenden/unklaren Informationen 
zusammenzutragen/klären.
mfG

von Markus (Gast)


Bewertung
-4 lesenswert
nicht lesenswert
>an die Linux Experte, wie starte ich das Program?
>>erstmal muss das Programm compiliert werden, dazu benötigt wird der gcc

Siehst Du, genau da liegt der Vorteil von Java: drauf klicken, läuft.

von Juan (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo R.M.
bin erst wieder dran. Vielen Dank für das pdf Dokument, sieht gut aus.
Ich habe Arch Linux, habe fltk und libx11 installiert aber beim 
kompilieren kommt:
_
fuseedit.cpp:2:19: schwerwiegender Fehler: Fl/Fl.H: Datei oder 
Verzeichnis nicht gefunden
 #include <Fl/Fl.H>

Also irgendwie passt mit "Fast Light Toolkit" bei mir leider nicht.

Das kompilierte Datei von dir startet ohne Probleme aber wenn ich die 
fuse lesen will (STK500 Seriell) kommt folgende Fehlermeldung:
_
avrdude: ser_open(): can't open device "/dev/tty0": Permission denied

--- tty0 habe ich in config.txt eingestellt.

AVRDUDE funktioniert problemlos über Terminal.

von titty (Gast)


Bewertung
0 lesenswert
nicht lesenswert
tty0 ist sicherlich nicht deine serielle Schnittstelle.
Die dürfte eher ttyS0 oder ttyUSB0 heißen.

von Juan (Gast)


Bewertung
0 lesenswert
nicht lesenswert
titty schrieb:
> tty0 ist sicherlich nicht deine serielle Schnittstelle.
> Die dürfte eher ttyS0 oder ttyUSB0 heißen.

Verdammt!!!
Da hast vollkommen Recht, bei config.txt anpassen habe ich natürlich die 
"S" gelöscht

Wenn es richtig macht dann funktioniert auch!

von R. M. (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Danke titty für den Einwurf!
Bin selbst in die Falle getappt, da ich hier keine "echten" seriellen 
Schnittstellen habe, tty0 gibt es zwar, gehört aber wohl zu den 
virtuellen Konsolen.
Habe die Vorbefüllung der Dropdowns jetzt so korrigiert, das sie mit 
ttyS0 beginnen.
mfG

von Juan (Gast)


Bewertung
0 lesenswert
nicht lesenswert
R. M. schrieb:
> Habe die Vorbefüllung der Dropdowns jetzt so korrigiert, das sie mit
> ttyS0 beginnen.

Jap!
Passt vielen Dank!

von Thomas N. (tonevi)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo R.M.

Tolles Projekt! Ich habe Dein Programm zunächst unter Windows 
erfolgreich getestet und dann auch wie beschrieben auf Linux Mint 18 
kompiliert und erprobt - ohne Probleme. Wenn ich das Gleiche allerdings 
mit Linux Mint 17.1 (LTS bis 2019) mache, bekomme ich beim Kompilieren 
diverse Fehlermeldungen (s. Screenshot). Woran könnte das liegen? Die 
aktuellen Pakete sind installiert.

MfG

von R. M. (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Thomas,

es gibt anscheinend doch zwischen den im Umlauf befindlichen 1.3er 
Versionen noch Unterschiede, einige unterstützen das Deaktivieren von 
Elementen, einige nicht. Auf meinem "Windows (MinGW)-FLTK" habe ich das 
gleiche Problem gehabt und dahingehend umschifft, das ich um die 
relevanten Stellen

#ifndef WIN32
// hier der Code
#endif

gebaut habe. Es geht hier eigentlich nur um die "Kindersicherung", das 
Deaktivieren der Fusebits, die mit "mode=Expert" markiert sind. Ich 
überlege, dies komplett aus dem Code zu entfernen, weils ohnehin nichts 
bringt.
Als schnelle Lösung, hab ich in der "fuseedit.cpp", nach der Zeile 37 
(wo die Windows/Linux-spezifischen includes eingebunden wurden, eine 
Zeile mit
#define WIN32 1
eingefügt, damit sind die fraglichen Stellen ausgeschlossen.
Mal nachdenken, wie ich damit langfristig umgehe...
mfG

von Alexander S. (alesi)


Bewertung
0 lesenswert
nicht lesenswert
Thomas N. schrieb:
> Wenn ich das Gleiche allerdings
> mit Linux Mint 17.1 (LTS bis 2019) mache, bekomme ich beim Kompilieren
> diverse Fehlermeldungen

Hallo,

die gleiche Fehlermeldung erhalte ich mit Debian jessie (nicht weiter
verwunderlich, da Mint ein Debian Derivat ist):

$> uname -a
Linux deb10 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-2+deb8u3 
(2016-07-02) x86_64 GNU/Linux

$> aptitude show libfltk1.3-dev
Package: libfltk1.3-dev
State: installed
Automatically installed: no
Version: 1.3.2-6+b1
Priority: optional
Section: libdevel
Maintainer: Aaron M. Ucko <ucko@debian.org>
Architecture: amd64
Uncompressed Size: 3,849 k

$> ./c
dialogs.fld:2: unknown version '1.0303'
g++ -I/usr/include/cairo -I/usr/include/glib-2.0 
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 
-I/usr/include/freetype2 -I/usr/include/libpng12 
-I/usr/include/freetype2 -I/usr/include/cairo -I/usr/include/glib-2.0 
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 
-I/usr/include/freetype2 -I/usr/include/libpng12 -g -O2 
-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_THREAD_SAFE -D_REENTRANT -o 
'fuseedit' 'fuseedit.cpp' -lfltk -lX11
fuseedit.cpp: In function ‘void cb_expert(Fl_Widget*, void*)’:
fuseedit.cpp:100:53: error: ‘class Fl_Check_Button’ has no member named 
‘set_active’
    if(check->value()) fuses[byte].fuseBit[bit].btn->set_active();
                                                     ^
fuseedit.cpp:101:73: error: ‘class Fl_Check_Button’ has no member named 
‘clear_active’
    else if(fuses[byte].fuseBit[bit].mode) 
fuses[byte].fuseBit[bit].btn->clear_active();
                                                                         ^
fuseedit.cpp: In function ‘void cb_fuseEdit(Fl_Widget*, void*)’:
fuseedit.cpp:207:58: error: ‘class Fl_Check_Button’ has no member named 
‘clear_active’
    if(fuses[c].fuseBit[b].mode) 
fuses[c].fuseBit[b].btn->clear_active();
                                                          ^

von titty (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Kann es vielleicht sein, dass eure FLTK-Versionen einfach zu alt sind 
und diese Funktion daher noch nicht enthalten ist? Gerade bei Debian 
sind die Pakete ja oft schon gut abgehangen...

von R. M. (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Das vermute ich auch, aber wegen der Sache würde ich jetzt keine 
Handstände machen und an der Paketverwaltung vorbei neue Versionen 
installieren das ist es nicht wert.

Habe das Deaktivieren von Checkboxen jetzt ganz rausgenommen und 
stattdessen die Beschreibung der markierten Bits mit einer Warnmeldung 
garniert.
Die potentiell gefährliche RSTDISBL-Fuse, hab ich jetzt mit in die 
GUI-Gruppen aufgenommen, mit der Markierung der riskanten Einstellung.
Das sollte das Risiko etwas verringern.
mfG

von Alexander S. (alesi)


Bewertung
0 lesenswert
nicht lesenswert
titty schrieb:
> Gerade bei Debian
> sind die Pakete ja oft schon gut abgehangen...

Das hat seinen Grund. Deshalb heisst jessie auch "stable",
es gibt auch "testing" und "unstable", wobei letzteres nicht heisst,
dass das System instabil läuft, sondern nur, dass sich die
Programme und Bibliotheken noch recht häufig ändern.

Mit dem fuseedit.cpp vom 02.08.2016 20:00 läuft es jetzt bei mir.
Das "Fuses-Fenster" bekomme ich nur mit <Shift-Alt-C> wieder zu.
Fehlt da ein <close> und/oder <ok> Knopf?

von Heiko L. (drcaveman)


Bewertung
0 lesenswert
nicht lesenswert
Kannst du das nicht in github einpflegen?

von R. M. (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Alexander S. schrieb:
> Fehlt da ein <close> und/oder <ok> Knopf?

Hab ihn mal schnell nachgerüstet. Hab bisher immer das X aus dem 
Fenstermenü genutzt, kann mich aber erinnern, das ich auch schon mit 
Debian-Versionen zu tun hatte, die das nicht hatten.

Heiko L. schrieb:
> Kannst du das nicht in github einpflegen?

Lese ich mich mal rein.

von Alexander S. (alesi)


Bewertung
0 lesenswert
nicht lesenswert
R. M. schrieb:
> Hab bisher immer das X aus dem
> Fenstermenü genutzt, kann mich aber erinnern, das ich auch schon mit
> Debian-Versionen zu tun hatte, die das nicht hatten.

Danke. Das ist schon ok so und hat weniger mit Debian als mit meinem
minimalistischen window-manager zu tun.
Im Vergleich zu KDE, Gnome oder auch Xfce sind ion, larswm, und wmii
schon minimalistisch. Ich benutze momentan dwm.

Zitat: In contrast to ion, larswm, and wmii, dwm is much smaller, faster 
and simpler.

http://dwm.suckless.org/

Sorry, leicht off-topic. Zurück zu fuseedit :-)

von R. M. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Alexander S. schrieb:
> Sorry, leicht off-topic.

Nee, nicht offtopic. Gefällt mir ganz gut, nicht mit Kanonen auf Spatzen 
zu schießen. Daher hab ich ja auch FLTK genommen und nicht, wie sonst 
die Mehrheit QT.
mfG und gute Nacht!

von Thomas N. (tonevi)


Bewertung
0 lesenswert
nicht lesenswert
Hallo R.M.

habe soeben Deine Version von 21 Uhr auf Mint 17.1 kompiliert & getestet 
- Problem gelöst, besten Dank.

MfG
Thomas

von Thomas N. (tonevi)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo allerseits,

da mich das Arbeiten mit fltk/fluid interessierte, habe ich mal versucht 
ein ganz einfaches Linux Interface für den TL866 µC Programmer zu 
erstellen. Das geht auch soweit ganz gut - also das Auslesen und Flashen 
der Speicherbereiche funktioniert. An einer Stelle bin ich aber bisher 
nicht weiter gekommen: Und zwar sendet das zugrunde liegende 
Konsolenprogramm Escape-Sequenzen, die zur Darstellung im Terminal 
gedacht sind und dort auch funktionieren. Wenn ich wie im Programm von 
R.M. die Konsolenausgabe in das FLTK Multiline Fenster umleite, werden 
diese Steuerzeichen natürlich nicht interpretiert sondern einfach 
ausgegeben (siehe Screenshots). Meine Frage an die C++ Experten: Wie 
kann ich den Datenstrom vor der Weiterleitung an das Multiline Fenster 
filtern?

MfG
Thomas

von R. M. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Thomas,
in diesem Falle, müsste man sich hier um die Interpretation der 
Steuerzeichen selbst kümmern. Die Anzahl ist ja überschaubar, bzw. man 
muss ja nur die interpretieren, welche von dem Programm auch wirklich 
genutzt werden. Hatte auch schon mal daran gedacht, mich an einem 
Terminalprogramm zu probieren, da besteht das Problem ja auch in der 
gleichen Form.
Für das FLTK böte es sich hier an, eine neue Klasse aus Fl_Text_Display 
abzuleiten, welche die putchar()-Funktionalität bereitstellt.
mfG

Edit: es sieht so aus, als ob es überhaupt nur 2 Steuerzeichen gibt:
^M ist eigentlich der Wagenrücklauf unter Windows -> postioniere Cursor 
auf den Anfang der aktuellen Zeile, könntest du durch '\n' ersetzen, das 
gibt dann zwar eine neue Zeile, ist aber besser lesbar,
^[[ mit einigen, eventuell unsichtbaren Zeichen, dient oft der 
Positionierung auf eine bestimmte Cursorposition.

von Thomas N. (tonevi)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich hatte zuvor die Terminal-Ausgabe in eine Datei umgeleitet: Jede 
Zeile die dort den prozentualen Fortschritt der Funktion ausgibt, 
beginnt mit 0A 1B 5B bzw. <LF><Esc>[.

Selbst der einfache Austausch eines dieser Zeichen gegen ein '\n' ist 
mir nicht gelungen. Die folgenden Versuche sind zwar syntaktisch 
richtig, führen aber zu dem gleichen Kauderwelsch bei der Ausgabe:
if (st1[0] == '\027') st1[0] = '\n';
output->insert(st1,1);

oder
if (strcmp(st1, "\10\27[") !=0) output->insert(st1,1);

Vielleicht könntest Du mal ein paar Code-Zeilen posten, wie es Deiner 
Meinung nach gehen müsste.

Danke
Thomas

von Rufus Τ. F. (rufus) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
ESC [K löscht den Rest der Zeile

Thomas N. schrieb:
> if (st1[0] == '\027'

Das funktioniert deswegen nicht, weil das eine Oktalzahl ist. Und 
deren Wert ist nicht 27dez, sondern 23dez.

C kennt keine dezimalen Char-Konstanten.

Auch \10 ist eine Oktalzahl, das ist 8dez.


Du musst entweder \33 und \12 oder die Hexdarstellung \x1b bzw. \x0a 
verwenden, damit Dein Vergleich funktioniert.

: Bearbeitet durch Moderator
von Thomas N. (tonevi)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Da hast Du natürlich recht - manchmal hat man halt ein Brett vorm Kopf.

Das abgeänderte Programm sieht jetzt schon ganz gut aus, wenngleich ich 
nicht weiss, woher die ^M Zeichen kommen. Der Datenstrom enthält nämlich 
keinerlei Carriage Returns.

- Thomas

von Rufus Τ. F. (rufus) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
^M ist 0x0D, nicht 0x0A.

0x0A ist linefeed, nicht carriage return

von Thomas N. (tonevi)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Jetzt benötige ich nochmal den Rat der Linux Experten: Zwischenzeitlich 
habe ich das aktuelle Linux Mint 20 installiert und das entsprechende 
fltk / fluid aus der Paketverwaltung. Das Compiler Skript läuft ohne 
Fehler durch; es erzeugt allerdings jetzt eine Datei vom Typ "Gemeinsame 
Bibliothek", die sich per ./name aus dem Terminal auch starten lässt, 
aber kein direkt startbares Programm mehr. Vermutlich fehlt da noch ein 
weiterer Linker-Lauf bzw. Bibliotheks-Module?

- Thomas

von Jack V. (jackv)


Bewertung
0 lesenswert
nicht lesenswert
Thomas N. schrieb:
> die sich per ./name aus dem Terminal auch starten lässt,
> aber kein direkt startbares Programm mehr.

Wenn es mit ./name startbar ist, ist es ein fertiggebautes Programm, 
und ich würde gucken, warum dein Dateimanager es falsch anzeigt.

von Thomas N. (tonevi)


Bewertung
0 lesenswert
nicht lesenswert
Das Problem scheint wohl tiefer zu liegen. Beim Googeln bin ich auf 
folgenden Beitrag gestoßen:

https://forum.ubuntuusers.de/topic/caja-will-keine-programme-ausfuehren/

Ganz unten heißt es dazu:

"GCC creates a shared object instead of an executable binary

Bei g++ heisst es dazu:

-pie Produce a position independent executable on targets which support 
it. For predictable results, you must also specify the same set of 
options that were used to generate code (-fpie, -fPIE, or model 
suboptions) when you specify this option."

Wenn ich diesen Schalter von Hand ergänze bekomme ich aber immer noch 
kein Binary.

von Jack V. (jackv)


Bewertung
0 lesenswert
nicht lesenswert
Thomas N. schrieb:
> Wenn ich diesen Schalter von Hand ergänze bekomme ich aber immer noch
> kein Binary.

passt halt nicht zu:

Thomas N. schrieb:
> es erzeugt allerdings jetzt eine Datei vom Typ "Gemeinsame
> Bibliothek", die sich per ./name aus dem Terminal auch starten lässt

→ meine Interpretation ist weiterhin: Anzeigeproblem deines nicht näher 
genannten Filemanagers. Um Klarheit zu schaffen: was sagt ›file‹ zur 
betreffenden Datei?

von Ingo W. (uebrig)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Thomas N. schrieb:
> Das Compiler Skript läuft ohne
> Fehler durch; es erzeugt allerdings jetzt eine Datei vom Typ "Gemeinsame
> Bibliothek", die sich per ./name aus dem Terminal auch starten lässt,
> aber kein direkt startbares Programm mehr.

Das ist dann aber schon ein funktionsfähiges Programm.

Jack V. schrieb:
> → meine Interpretation ist weiterhin: Anzeigeproblem deines nicht näher
> genannten Filemanagers. Um Klarheit zu schaffen: was sagt ›file‹ zur
> betreffenden Datei?

Der Dateityp dürfte ELF sein, was sowohl Bibliotheken, als auch 
Programme beinhaltet.
https://de.wikipedia.org/wiki/Executable_and_Linking_Format

Wenn Thomas das Programm einfach über die Kommandozeile starten möchte, 
scheitert er wahrscheinlich daran, dass es nicht im Suchpfad steht. Das 
könnte man über ein shellscript in $HOME/bin oder über einen Starter in 
$HOME/.local/share/applications/ erledigen. Dann kann das Programm auch 
über die grafische Oberfläche gestartet werden.
Hab mal meinen Starter angehängt, hier müssten noch die Pfade ins 
Programmverzeichnis und ggf zum Icon (bei mir von einem anderen 
Programm) angepasst werden.

https://wiki.ubuntuusers.de/.desktop-Dateien/

von Thomas N. (tonevi)


Bewertung
0 lesenswert
nicht lesenswert
Filemanager ist Caja 1.24.0

Ergebnis von >file<

thomas@thomas-ESPRIMO-Mobile-V6535:~/Fluid_work$ file fuseedit
fuseedit: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), 
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, 
BuildID[sha1]=5903c02d0488763cad1d0f1214f8e5e6c7739e29, for GNU/Linux 
3.2.0, stripped
thomas@thomas-ESPRIMO-Mobile-V6535:~/Fluid_work$


Mittlerweile bin ich aber schon einen kleinen Schritt weiter: Wenn ich 
die von der Compiler-Shell generierte Zeile zur Codeerzeugung kopiere 
und ganz am Anfang hinter g++ den Schalter -no-pie ergänze und das 
Kommando neu absetzte, erhalte ich das gewünschte Binärfile. Ergebnis 
von >file< dann:


thomas@thomas-ESPRIMO-Mobile-V6535:~/Fluid_work$ file fuseedit
fuseedit: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), 
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, 
BuildID[sha1]=846360367b273ae06fd3441c18ecc7d06156d6be, for GNU/Linux 
3.2.0, with debug_info, not stripped
thomas@thomas-ESPRIMO-Mobile-V6535:~/Fluid_work$

Also müsste man wohl eine entsprechende Änderung in der fltk-config 
vornehmen, nur wie ?

von Thomas N. (tonevi)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Mit angepasster fltk-config wie im Screenshot dargestellt funktioniert 
es nun wie gewohnt.

- Thomas

von Jack V. (jackv)


Bewertung
0 lesenswert
nicht lesenswert
Ingo W. schrieb:
> Der Dateityp dürfte ELF sein, was sowohl Bibliotheken, als auch
> Programme beinhaltet.

Es gibt aber halt ’nen Unterschied zwischen „shared object“ und 
„executable“, deswegen fragte ich die Ausgabe an. Meinem Verständnis 
nach sollte sich ein shared object nicht direkt ausführen lassen, 
deswegen meine Verwirrung, die eigentlich immer noch besteht: eigentlich 
sollte der Versuch des Ausführens einer Lib direkt in einem Segfault 
enden.

Ingo W. schrieb:
> Wenn Thomas das Programm einfach über die Kommandozeile starten möchte,
> scheitert er wahrscheinlich daran, dass es nicht im Suchpfad steht.

… war hier irrelevant, weil er’s mit relativer Pfadangabe aufgerufen 
hat: ./name

Wie auch immer – gut, dass es gefixt ist. Wenn’s zu dem Programm 
irgendwo ’n Git-Repo gäbe, könnte man’s dort einbringen – ob R.M. hier 
noch mitliest?

Beitrag #6353607 wurde von einem Moderator gelöscht.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.