Fehler beim kompilieren der IDE

[Acia6850]

Hallo habe die neuste Lazarus IDE auf Debian 12 Installiert.

IDE läuft man kann kompilieren.

Beim einbinden eines Packgage und der kompilierung der IDE kommt folgende Fehlermeldung :

Hint: (11030) Start of reading config file /etc/fpc.cfg
Hint: (11031) End of reading config file /etc/fpc.cfg
Free Pascal Compiler version 3.2.2 [2021/07/09] for x86_64
Copyright (c) 1993-2021 by Florian Klaempfl and others
(1002) Target OS: Linux for x86-64
(3104) Compiling dataportlasarus.pas
/home/wgs/.lazarus/onlinepackagemanager/packages/DataPort/dataportlasarus.pas(10,3) Hint: (5023) Unit "DataPort" not used in DataPortLasarus
/home/wgs/.lazarus/onlinepackagemanager/packages/DataPort/dataportlasarus.pas(10,13) Hint: (5023) Unit "DataPortUART" not used in DataPortLasarus
(1008) 28 lines compiled, 0.4 sec
(1022) 4 hint(s) issued
make: Entering directory '/usr/share/lazarus/3.6.0'
/usr/bin/make -C ide ide
make[1]: Entering directory '/usr/share/lazarus/3.6.0/ide'
/usr/bin/make --assume-new=lazarus.pp lazarus OPT='-Fu../packager/units/x86_64-linux -Fu../components/codetools/units/x86_64-linux -Fu../components/debuggerintf/lib/x86_64-linux -Fu../components/lazutils/lib/x86_64-linux -Fu../components/freetype/lib/x86_64-linux -Fu../lcl/units/x86_64-linux -Fu../lcl/units/x86_64-linux/gtk2 -Fu../components/buildintf/units/x86_64-linux -Fu../components/ideintf/units/x86_64-linux/gtk2 -Fu../components/synedit/units/x86_64-linux/gtk2 -Fu../components/lazcontrols/lib/x86_64-linux/gtk2 -Fu../components/lazcontrols/design/lib/x86_64-linux/gtk2 -Fu../components/lazdebuggers/lazdebuggerintf/lib/x86_64-linux -Fu../components/lazdebuggers/cmdlinedebuggerbase/lib/x86_64-linux/gtk2 -Fu../components/lazdebuggergdbmi/units/x86_64-linux/gtk2 -Fu../components/lclextensions/lib/x86_64-linux-gtk2 -Fu../components/virtualtreeview/lib/x86_64-linux-gtk2 -Fu../components/fpdebug/lib/x86_64-linux -Fu../components/lazdebuggers/lazdebuggerfp/lib/x86_64-linux/gtk2 -Fu../components/lazdebuggers/lazdebuggerlldb/lib/x86_64-linux/gtk2 -Fu../components/lazdebuggers/lazdebuggerfplldb/lib/x86_64-linux/gtk2 -Fupackages/ideconfig/lib/x86_64-linux/gtk2 -Fupackages/idedebugger/lib/x86_64-linux/gtk2 @/home/wgs/.lazarus/idemake.cfg'
make[2]: Entering directory '/usr/share/lazarus/3.6.0/ide'
/usr/bin/fpc -gl -vbqewnhi -Sci -dlclgtk2 -Fu../designer -Fu../debugger -Fu../debugger/frames -Fu../converter -Fu../packager -Fu../packager/frames -Fu../components/custom -Fuframes -Fu. -Fu/usr/lib/fpc/3.2.2/units/x86_64-linux/rtl -Fiinclude -Fiinclude/linux -Fi../images -FE.. -FU../units/x86_64-linux/gtk2 -Cg -Fl/usr/lib/gcc/x86_64-linux-gnu/12 -Fu../packager/units/x86_64-linux -Fu../components/codetools/units/x86_64-linux -Fu../components/debuggerintf/lib/x86_64-linux -Fu../components/lazutils/lib/x86_64-linux -Fu../components/freetype/lib/x86_64-linux -Fu../lcl/units/x86_64-linux -Fu../lcl/units/x86_64-linux/gtk2 -Fu../components/buildintf/units/x86_64-linux -Fu../components/ideintf/units/x86_64-linux/gtk2 -Fu../components/synedit/units/x86_64-linux/gtk2 -Fu../components/lazcontrols/lib/x86_64-linux/gtk2 -Fu../components/lazcontrols/design/lib/x86_64-linux/gtk2 -Fu../components/lazdebuggers/lazdebuggerintf/lib/x86_64-linux -Fu../components/lazdebuggers/cmdlinedebuggerbase/lib/x86_64-linux/gtk2 -Fu../components/lazdebuggergdbmi/units/x86_64-linux/gtk2 -Fu../components/lclextensions/lib/x86_64-linux-gtk2 -Fu../components/virtualtreeview/lib/x86_64-linux-gtk2 -Fu../components/fpdebug/lib/x86_64-linux -Fu../components/lazdebuggers/lazdebuggerfp/lib/x86_64-linux/gtk2 -Fu../components/lazdebuggers/lazdebuggerlldb/lib/x86_64-linux/gtk2 -Fu../components/lazdebuggers/lazdebuggerfplldb/lib/x86_64-linux/gtk2 -Fupackages/ideconfig/lib/x86_64-linux/gtk2 -Fupackages/idedebugger/lib/x86_64-linux/gtk2 @/home/wgs/.lazarus/idemake.cfg -dx86_64 lazarus.pp
Hint: (11030) Start of reading config file /etc/fpc.cfg
Hint: (11031) End of reading config file /etc/fpc.cfg
Hint: (11030) Start of reading config file /home/wgs/.lazarus/idemake.cfg
Hint: (11031) End of reading config file /home/wgs/.lazarus/idemake.cfg
Free Pascal Compiler version 3.2.2 [2021/07/09] for x86_64
Copyright (c) 1993-2021 by Florian Klaempfl and others
(1002) Target OS: Linux for x86-64
(3104) Compiling lazarus.pp
(9022) Compiling resource /home/wgs/.lazarus/units/x86_64-linux/gtk2/lazarus.or
(9015) Linking /home/wgs/.lazarus/bin/lazarus
/usr/bin/ld: cannot find -lGL: No such file or directory
make[2]: *** [Makefile:4365: lazarus] Error 1
make[1]: *** [Makefile:4804: ide] Error 2
make: *** [Makefile ide] Error 2
/usr/share/lazarus/3.6.0/ide/lazarus.pp(171,1) Error: (9013) Error while linking
/usr/share/lazarus/3.6.0/ide/lazarus.pp(171,1) Fatal: (10026) There were 1 errors compiling module, stopping
Fatal: (1018) Compilation aborted
Error: /usr/bin/ppcx64 returned an error exitcode
make[2]: Leaving directory '/usr/share/lazarus/3.6.0/ide'
make[1]: Leaving directory '/usr/share/lazarus/3.6.0/ide'
make: Leaving directory '/usr/share/lazarus/3.6.0'

wie kann ich den Fehler beheben.

Grüße Acia6850

[af0815]

Es fehlt dir eine Library, libgl wenn ich die Fehlermeldung richtig lese.

[Mathias]

/usr/bin/ld: cannot find -lGL: No such file or directory

Da ist der Wurm. Du hast Mesa nicht installiert.

Mit dem sollte der Fehler weg sein.

Code: Alles auswählen

sudo apt-get install freeglut3-dev

[Acia6850]

Vielen Dank für die schnelle Antwort.

Danke das Problem ist beseitigt.

Wo kann man das nachlesen, daß man die Mesa Lib nachinstallieren muss.

Ich habe aus der Webseite von Lazarus IDE die drei .deb packete installiert.

Grüße Acia6850

[Mathias]

Wo kann man das nachlesen, daß man die Mesa Lib nachinstallieren muss.

Hier, aber nur wen man weis, das es dort ist.

https://wiki.freepascal.org/fpcupdeluxe/de

Der Fehler "-lGL" ist eine der gemeinste libs, wen man diese sucht.
Meisten kann man, wen der Fehler "-labc", kann man einfach

Code: Alles auswählen

sudo apt install libabc-dev

machen und gut ist es.

Google hätte auch geholfen, wen du "-lGL lib" eingegeben hättest.

[KoBraSoft]

Da bin ich auch schon hängen geblieben:viewtopic.php?f=18&t=15207
Mein Problem damals war:

Dass mit lGL libGL.so gemeint ist darauf wäre ich im Leben nicht gekommen. Vor allem weil ich das kleine l (wie laufen) für ein großes I (wie Igel) gehalten habe.

[Mathias]

Wen man sich ein wenig mit C auskennt, dan sieht man woher der Fehler kommt.

Hier ein Beispiel:

Code: Alles auswählen

$ gcc test.c -ltest
/usr/bin/ld: -ltest kann nicht gefunden werden: Datei oder Verzeichnis nicht gefunden
collect2: error: ld returned 1 exit status

[Warf]

Naja ich sags mal so, unter Linux ist das C ELF System und die C ABI die offizielle Systemschnittstelle. Wer unter Linux entwickeln will, muss zu nem gewissen grad C und C buildsysteme verstehen.

Man kann von C halten was man will, aber es ist nunmal die Grundlage für jedwede Anwendungsschnittstelle auf POSIX systemen, daher sollte man sich ein bisschen reinlesen. Bezüglich linker kann man am besten mit der Manpage anfangen: https://www.man7.org/linux/man-pages/man1/ld.1.html

[Mathias]

Man kann von C halten was man will, aber es ist nunmal die Grundlage für jedwede Anwendungsschnittstelle auf POSIX systemen, daher sollte man sich ein bisschen reinlesen. Bezüglich linker kann man am besten mit der Manpage anfangen:

Je mehr man sich mit C befasst, je mehr schaut man durch. Die Sprache an sich ist gar nicht mal so schlecht, mit C++ sieht es ganz anders aus.
Was aber bei C sehr mühsam ist, das man eine *.h und eine *.c pflegen muss. Da ist das Unit System von Pascal überlegen.
Wobei man mit

Code: Alles auswählen

#include <test.c>

ein bisschen mogeln kann, aber bei grösseren Sachen scheitert dies.
Auch kenne ich keine so komfortabel Editor wie die Lazarus-IDE. Das merk man besonders wen man mit [Ctrl + space] arbeitet.

[Warf]

Je mehr man sich mit C befasst, je mehr schaut man durch. Die Sprache an sich ist gar nicht mal so schlecht, mit C++ sieht es ganz anders aus.

Ich finde C++ hat sehr viele sehr gute Ideen, aber je mehr ich C++ genutzt habe desto mehr habe ich gemerkt das die Sprache mir als Entwickler nicht gut tut. C++ versucht einfach alles zu machen und zu können, sodass die Sprache unfassbar kompliziert wird was zum einen dazu führt das es extrem viele Konzepte gibt die es alle zu lernen und verstehen gilt. Ich hab den Sprung von C++11 auf C++14 und von C++14 auf C++17 mitgemacht und weil ich damals täglich C++ programmiert habe konnte ich es mir leisten mir all die neuerungen anzueignen. Als ich dann ab 2019 C++ nur noch ab und an benutzt hab und mit C++20 so viele neuerungen kamen, hatte ich einfach nicht mehr die Zeit up to date zu bleiben mit all den neuen features. C++ lernen ist ein Vollzeitjob für sich.
Aber umso schlimmer steht man plötzlich auch vor der Frage: "Ich weiß was ich tun muss um das Problem zu lösen, aber was ist jetzt der beste weg das umzusetzen", weil es so viele Möglichkeiten gibt etwas in C++ zu machen und alle haben ihre eigenheiten das man am ende gar nicht mehr dazu kommt das eigentliche Problem zu lösen.

Es ist oftmals besser wenn es einen Weg gibt und man sich darauf konzentrieren kann etwas gut zu machen, als 10 wege die sich alle irgendwie überschneiden, aber jede entscheidung auswirkungen darauf hat wie man von dort weiter machen kann.

Was aber bei C sehr mühsam ist, das man eine *.h und eine *.c pflegen muss. Da ist das Unit System von Pascal überlegen.

Da leidet C tatsächlich an seinem eigenen erfolg. Das C buildsystem aus verschiedenen objekten die durch einen Linker zusammengelinkt werden (das ELF system), ist wie gesagt die Platform für Programmierung auf Unix geworden. Und deshalb kann C das nicht ändern, denn das C buildsystem ist nicht nur das C buildsystem, es ist das System wie Statische bibliotheken gelinkt werden, wie Komponenten aus verschiedenen Objekten miteinander kommunizieren etc.
Das ist generell die Größte Blockade für das C Ökosystem, jede entscheidung betrifft nicht nur C Programme, sondern alle POSIX basierten Betriebsysteme: Linux, MacOS, BSD, iOS, Android, etc.

Wobei man mit

Code: Alles auswählen

#include <test.c>

ein bisschen mogeln kann, aber bei grösseren Sachen scheitert dies.
Auch kenne ich keine so komfortabel Editor wie die Lazarus-IDE. Das merk man besonders wen man mit [Ctrl + space] arbeitet.

Das hat C++ tatsächlich gelöst. In C++ ist der "inline" Modifier für Funktionen überarbeitet worden. Das Problem damit ist das mit include die Datei eingeladen wird und somit die selben funktionen in jeder datei die das include durchführt vorkommen. Das bedeutet entweder massive code dublikation oder namenskonflikte beim Linken.
C++ hat das geändert indem Funktionen die als inline markiert sind, werden angenommen das funktionen mit selber signatur (selber name + parameter) den selben code haben, und somit können die dublikationen rausgeworfen werden.
Die entscheidung ein bestehendes C keyword zu benutzen und dessen Funktionsweise zu ändern ist natürlich, in klassischer C++ Manier, maximal verwirrend, aber damit sind in C++ Header only Bibliotheken tatsächlich nicht nur Möglich sondern sehr weit verbreitet (tatsächlich sind große Teile der STL, also der Standardbibliothek, header only).
Einzige Problem dabei ist nur das es die Compilezeit extrem verlangsamt, weil jedes mal der Header von Grund auf neu kompiliert wird.

[Mathias]

Da leidet C tatsächlich an seinem eigenen erfolg. Das C buildsystem aus verschiedenen objekten die durch einen Linker zusammengelinkt werden (das ELF system), ist wie gesagt die Platform für Programmierung auf Unix geworden. Und deshalb kann C das nicht ändern, denn das C buildsystem ist nicht nur das C buildsystem, es ist das System wie Statische bibliotheken gelinkt werden, wie Komponenten aus verschiedenen Objekten miteinander kommunizieren etc.
Das ist generell die Größte Blockade für das C Ökosystem, jede entscheidung betrifft nicht nur C Programme, sondern alle POSIX basierten Betriebsysteme: Linux, MacOS, BSD, iOS, Android, etc.

Ein Vorteil hat es doch. Man braucht nicht zwingend die *.c, Es reicht die *.h und die fertig kompilierte lib.
Und zum Glück kann man mit FPC sehr gut zu den C-libs binden. Ansonsten wäre nichts aus Lazarus und GTK geworden.

[KoBraSoft]

Wer unter Linux entwickeln will, muss zu nem gewissen grad C und C buildsysteme verstehen.

Hier würde ich gerne gaaanz vorsichtig widersprechen. Ich entwickle seit längerem Linux Anwendungen und kann kaum C. (Ich schreibe zwar Programme für Arduinos, ESP32, usw mit der Arduino Software. Aber ob das wirklich C ist )

Mag sein, dass meine Programme nicht so "highly sophisticated" sind, aber sie laufen und das schon seit Jahren.

Gerade Lazarus erlaubt es Einsteigern lauffähige Programme zu erstellen.

Natürlich schadet es nicht C zu verstehen, es schadet auch nicht die Funktionsweise moderner Computerprozessoren zu verstehen.

Übrigens habe ich hier https://github.com/LongDirtyAnimAlf/fpc ... allscripts sehr nützliche scripts gefunden.
Die installieren nicht wie der Name vermuten läst Lazarus oder fpcupdeluxe, sondern bereiten die Systeme darauf vor.
Sehr praktisch.

[Warf]

Übrigens habe ich hier https://github.com/LongDirtyAnimAlf/fpc ... allscripts sehr nützliche scripts gefunden.
Die installieren nicht wie der Name vermuten läst Lazarus oder fpcupdeluxe, sondern bereiten die Systeme darauf vor.
Sehr praktisch.

Die Scripts habe ich auch schon gesehen da sie auf der Wiki seite verlinkt sind, sind aber ein bisschen fragwürdig. Als beispiel mal das debian script:

Code: Alles auswählen

sudo apt-get install -y xterm 
sudo apt-get install -y git 
sudo apt-get install -y subversion 
sudo apt-get install -y unzip 
sudo apt-get install -y wget 
sudo apt-get install -y make 
sudo apt-get install -y gcc 
sudo apt-get install -y build-essential
sudo apt-get install -y binutils
sudo apt-get install -y gdb
sudo apt-get install -y libc6-dev
sudo apt-get install -y libc-bin
sudo apt-get install -y texinfo

sudo apt-get install -y libglib2.0-dev
sudo apt-get install -y libgtk2.0-0-dev
sudo apt-get install -y libgtk2.0-dev
sudo apt-get install -y gtk2-engines-pixbuf
sudo apt-get install -y libcairo2-dev
sudo apt-get install -y libXxf86vm-dev
sudo apt-get install -y libxtst-dev
sudo apt-get install -y libx11-dev
sudo apt-get install -y libglvnd-dev

sudo apt-get install -y appmenu-gtk2-module
sudo apt-get install -y libcanberra-gtk-module
  
sudo apt-get install -y libxft2
sudo apt-get install -y libfontconfig1

sudo apt-get install -y libsdl2-dev
sudo apt-get install -y libsdl2-image-dev
sudo apt-get install -y libsdl2-mixer-dev
sudo apt-get install -y libsdl2-net-dev
sudo apt-get install -y libsdl2-ttf-dev

sudo apt-get install -y qt5-qmake
sudo apt-get install -y qtbase5-dev
sudo apt-get install -y qtbase5-dev-tools
sudo apt-get install -y qtdeclarative5-dev
sudo apt-get install -y libqt5x11extras5-dev

sudo apt-get install -y qt6-base-dev
sudo apt-get install -y qt6-base-dev-tools

• Git, subversion, wget und unzip: Anforderungen von fpcup
• Make, gcc, binutils, libc(dev): Dependencies von build-essential, und z.T. dependencies von einander
• GTK Bibliotheken (zweiter Absatz): Alles dependencies von libgtk2.0-dev
• xterm, texinfo, die gtk modules und sdl: Was die hier sollen weiß ich nicht. Vermutlich dependencies von einzelnen packages aber Grundlegend nicht benötigt außer man will SDL anwendungen oder so bauen
• GDB ist nur notwendig wenn man FPDebug nicht benutzt

Dafür fehlt qt5pas und qt6pas, aber ich gehe aber mal von aus das fpcup die selbst baut (garantiert kompatibilität).

Für ne stink normale Lazarus Installation reicht also

Code: Alles auswählen

sudo apt-get install -y \
  build-essential binutils \
  libgtk2.0-dev \
  qt5-qmake qtbase5-dev qtbase5-dev-tools \
  qt6-base-dev  qt6-base-dev-tools

Wenn man qt5pas bzw. qt6pas nicht selbst bauen will kann man statt qt5-qmake und den dev-tools auch einfach qt5pas bzw qt6pas installieren. Wobei es schon vorkam das Lazarus die geupdated hat sodass die system repos nicht mit der Lazarus version kompatibel waren

Leider gibt es soweit ich weiß keine offizielle Liste mit dependencies. Insbesondere nicht für Packages (dokumentation von manchen Packages ist eher mau).

Wobei ich tatsächlich meist wenn ich Lazarus auf einem frischen System installiere mir die Dependencies des Systempackages schnappe (apt-cache dependencies lazarus). Auch wenn die Lazarus Version des System package managers out of date ist (bei Debian Systemen), ändert sich an den Dependencies sehr selten was

[Soner]

...
Wo kann man das nachlesen, daß man die Mesa Lib nachinstallieren muss.
...

Ich habe solche Sachen immer mit Synaptic-Packagemanager herausfinden können. Wenn du einen Fehler wie "/usr/bin/ld: cannot find -lGL: No such file or directory" hast, dann nimm den Teil mit "-lGL" heraus und ersetzt "-l" mit "lib", dann suche im Synaptic nach "libgl", anschließend muss man das Paket mit "libgl...-dev" installieren. So kannst du auch andere fehlende Bibliotheken finden.