Archiv verlassen und diese Seite im Standarddesign anzeigen : libXext installiert, wird aber nicht gefunden
oyster-manu
14.06.03, 15:17
ich habe mir sim 0.8.2 (sourcecode) runtergeladen. nach
./configure bekomme ich die meldung
"configure: error: W need a working libXext to proceed. Since
configure can't find it itself, we stop here assuming that make wouldn't
find them either."
dabei habe ich mir libXext installiert. ich hab libXext.so als
ausführbar gekennzeichnet und es nach /usr/lib kopiert sowie
ldconfig ausgeführt. dennoch bekomme ich diese meldung.
was soll ich machen? brauche ich eine andere version von der lib
(ich habe im netz noch andere gesehn, wie z.b. libXext.so.6 oder
libXext.so.6.3)?
außerdem bekomme ich seit dem ich libXext installiert habe, folgende fehlermeldung wenn ich per konsole
eine datei mit kwrite öffnen will:
"kwrite: error while loading shared libraries: /usr/lib/libXext.so.6: ELF
file OS ABI invalid"
mfg
manu
Hallo ich habe das selbe Problem und weiß mir auch keinen Rat :(
Die Dateien existieren in /usr/X11R6/lib , ein ls -l gibt folgendes aus:
lrwxrwxrwx 1 root root 14 14. Jun 19:31 libXext.so.6 -> libXext.so.6.4
-rwxr-xr-x 1 root root 53520 27. Feb 17:23 libXext.so.6.4
Was läuft hier falsch ?
Ich verwende RedHat 9 und habe die selbe Sim-Source-Version
Grüße
Phil
dabei habe ich mir libXext installiert. ich hab libXext.so als
ausführbar gekennzeichnet und es nach /usr/lib kopiert sowie
ldconfig ausgeführt. dennoch bekomme ich diese meldung.
was soll ich machen? brauche ich eine andere version von der lib
(ich habe im netz noch andere gesehn, wie z.b. libXext.so.6 oder
libXext.so.6.3)?
außerdem bekomme ich seit dem ich libXext installiert habe, folgende fehlermeldung wenn ich per konsole
eine datei mit kwrite öffnen will:
"kwrite: error while loading shared libraries: /usr/lib/libXext.so.6: ELF
file OS ABI invalid"
Woher hast Du diese libXext.so.6? Dieser Fehler sollte nur auftreten, wenn Du z.B. versuchst eine auf FreeBSD kompilierte ELF Bibliothek auf GNU/Linux oder umgekehrt auszuführen.
oyster-manu
16.06.03, 14:37
hi,
ich habe mir die lib ausm netz gezogen. da gabs auch gleich ne anleitung dabei:
man soll die lib als ausführbar kennzeichnen und nach /usr/lib kopieren, danach als root
"ldconfig" ausführen damit irgend ne liste geupdated wird.
danach lief bei mir aber fast gar nichts mehr: ich hatte linux nur noch in der terminal version, X hat sich irgendwie verabschiedet und musste X aus der konsole starten. hab dann schnell die lib wieder entfernt und "ldconfig" ausgeführt, jetzt ist alles wieder beim alten.
sim hab ich immernoch nicht drauf...
Die Dateien existieren in /usr/X11R6/lib , ein ls -l gibt folgendes aus:
lrwxrwxrwx 1 root root 14 14. Jun 19:31 libXext.so.6 -> libXext.so.6.4
-rwxr-xr-x 1 root root 53520 27. Feb 17:23 libXext.so.6.4
Was läuft hier falsch ?
Bei Dir fehlt scheinbar nur ein Verweis, dieser sollte in etwa so aussehen:
zander@kugai:/usr/X11R6.5/lib# ls libXext.so* -l
lrwxrwxrwx 1 root root 14 May 5 21:45 libXext.so -> libXext.so.6.4
lrwxrwxrwx 1 root root 14 May 5 21:45 libXext.so.6 -> libXext.so.6.4
-rwxr-xr-x 1 root root 68528 May 5 21:45 libXext.so.6.4
dragon's might
16.06.03, 15:07
Ich habe das selbe Problem (red hat 9)!
In welchem Programm gibt's denn die libXext?
oyster-manu
16.06.03, 15:10
tja, bei mir is keine libXext auf dem system zu finden :(.
wo soll man denn den code eingeben?
ich bin auch blöde!!! die lib is wohl auf meinem system drauf.
nur wie geht n das mit dem verweis? geht das nicht mit ldconfig?
tja, bei mir is keine libXext auf dem system zu finden :(.
wo soll man denn den code eingeben?
Mein zweiter Hinweis bezog sich auf reds Beitrag. In Deinem Fall empfehle ich Dir, entweder die XFree86 Installation Deiner Distribution zu überprüfen oder nachzusehen, ob diese libXext.so* eventuell in einem anderen Paket anbietet. Ansonsten wirst Du libXext.so* auch in dem Xbin.tgz Paket (für Deine glibc/XFree86 Version) auf dem XFree86 FTP server finden.
DerKlopfer2000
16.06.03, 15:28
Naja, am einfachsten ist es, die passenden RPMs zu installieren ;)
Die besagte Datei befindet sich für Red Hat 9 im Paket
XFree86-libs-4.3.0-2.i386.rpm
Welche Abhängigkeiten noch erfüllt werden müssen, weiss ich nicht, allerdings müsste dieses Paket bereist installiert sein, da ohne dieses der X-Server nicht läuft.
Falls ./configure danach immernoch meckert, dass es die Datei nicht findet, hilft es eventuell, mit --x-libraries=DIR den Pfad zu den Libs anzugeben, also z.B. ./configure --x-libraries=/usr/X11R6/lib .
Hi also ich hab jetzt die Verknüpfung erstellt.
Allerdings geht es immernoch nicht :(
Hier die Ausgabe in der config.log
configure:18386: result: no
configure:18400: checking for libXext
configure:18438: gcc -o conftest -O2 -L/usr/X11R6/lib conftest.c -lXext -lX11 -lresolv >&5
/usr/bin/ld: cannot find -lX11
collect2: ld returned 1 exit status
configure:18441: $? = 1
configure: failed program was:
#line 18412 "configure"
#include "confdefs.h"
Mir ist aber auch aufgefallen, dass die Dateigröße deiner (zander) libXext.so.6.4 größer ist als meine ?!
Grüsse
Phil
configure:18438: gcc -o conftest -O2 -L/usr/X11R6/lib conftest.c -lXext -lX11 -lresolv >&5
/usr/bin/ld: cannot find -lX11
Deine XFree86 Installation scheint in einem merkwürdigen Zustand zu sein; was findet sich denn in /usr/X11R6/lib in Puntko libX11*?
Mir ist aber auch aufgefallen, dass die Dateigröße deiner (zander) libXext.so.6.4 größer ist als meine ?!
Das ist schon in Ordnung (andere compiler, unterschiedliche CFLAGS, ...).
Nein, merkwürdig ist das nicht, sondern ganz normales Verhalten, wenn das XFree86-devel Paket nicht installiert ist. Dort sind auch die nötigen shared object links drin.
Nein, merkwürdig ist das nicht, sondern ganz normales Verhalten, wenn das XFree86-devel Paket nicht installiert ist. Dort sind auch die nötigen shared object links drin.
Falls Du mit shared objects die shared libraries meinst macht das keinen Sinn, immerhin wären all diejenigen Programme, die betreffenden Bibliotheken gelinkt sind, nicht lauffähig. Ich vermute was Du meinst ist, daß die symbolischen Links auf [name].so (ohne Versionskürzel) mit dem Entwicklerpaket geliefert werden. Das ist durchaus möglich, fällt in meinen Augen aber durchaus unter merkwürdig.
Ich schrieb "shared object links" und meine damit auch wirklich nur die Softlinks mit Namen *.so, welche auf vom Linker gesuchte shared objects zeigen. Diese sind unabhängig von den versionsbehafteten Links von ldconfig. Sie werden nur für Software-Entwicklung benötigt und befinden sich deswegen, ebenso wie *.a Archivdateien, naheliegenderweise in separaten, optionalen Paketen:
$ file /usr/X11R6/lib/libXext.so
/usr/X11R6/lib/libXext.so: symbolic link to libXext.so.6.4
$ rpm --redhatprovides /usr/X11R6/lib/libXext.so
XFree86-devel-4.3.0-2
$ rpm -ql XFree86-devel | grep so$
/usr/X11R6/lib/libGL.so
/usr/X11R6/lib/libGLU.so
/usr/X11R6/lib/libICE.so
/usr/X11R6/lib/libOSMesa.so
/usr/X11R6/lib/libSM.so
/usr/X11R6/lib/libX11.so
/usr/X11R6/lib/libXTrap.so
/usr/X11R6/lib/libXaw.so
/usr/X11R6/lib/libXcursor.so
/usr/X11R6/lib/libXext.so
/usr/X11R6/lib/libXfont.so
/usr/X11R6/lib/libXft.so
/usr/X11R6/lib/libXi.so
/usr/X11R6/lib/libXmu.so
/usr/X11R6/lib/libXmuu.so
/usr/X11R6/lib/libXp.so
/usr/X11R6/lib/libXpm.so
/usr/X11R6/lib/libXrandr.so
/usr/X11R6/lib/libXrender.so
/usr/X11R6/lib/libXt.so
/usr/X11R6/lib/libXtst.so
/usr/X11R6/lib/libXv.so
/usr/X11R6/lib/libdps.so
/usr/X11R6/lib/libdpstk.so
/usr/X11R6/lib/libpsres.so
/usr/lib/libGL.so
/usr/lib/libGLU.so
Ich schrieb "shared object links" und meine damit auch wirklich nur die Softlinks mit Namen *.so, welche auf vom Linker gesuchte shared objects zeigen. Diese sind unabhängig von den versionsbehafteten Links von ldconfig. Sie werden nur für Software-Entwicklung benötigt und befinden sich deswegen, ebenso wie *.a Archivdateien, naheliegenderweise in separaten, optionalen Paketen:
Gut, mit der Argumentation kann ich leben. Ich finde es dennoch auch weiterhin etwas seltsam, daß Distributionen die symbolischen Links in dieser Form separat verpacken: (insbesondere) statische Bibliotheken und header sind eigenständig und nehmen oftmals unnötig Platz weg, auf die symbolischen Links trifft das aber nicht zu.
Jeder Link belegt auch eine inode. ;) :D
Und hat man erstmal ein separates devel-Paket, packt man da alles rein, was für Entwicklung gebraucht wird und sonst überflüssig ist.
In meiner vorherigen Antwort war auch schon ein anderer Grund versteckt, warum "Development" Dateien in einem Paket sein sollten. ;) Mal angenommen, ein Programmierer möchte Zlib in seiner Applikation verwenden und sucht das Paket, in dem die zugehörigen Entwicklungsdateien findet. Basierend auf der Kenntnis, wie die Archive heißen werden, könnte seine Anfrage so aussehen:
$ rpm --redhatprovides /usr/lib/libz.so /usr/lib/libz.a
zlib-devel-1.1.4-8
Das ginge nicht, wenn libz.so im zlib Paket wäre. Oder er kommt von einer Plattform, auf der er die Mathematikbibliothek manuell linken mußte:
$ rpm --redhatprovides /usr/lib/libm.so
glibc-devel-2.3.2-11.9
Zudem compilieren auch viele User Software, die von Programmierung sonst nichts verstehen. Es ist m.E. eine FAQ, daß User an Compilierung scheitern, weil sie zwar shared objects installiert haben, aber weder Header Dateien, noch die für den Linker notwendigen *.so Dateien.
oyster-manu
18.06.03, 21:17
ok, aber löst das jetzt das problem (sim installieren)?
also ich werd aus diesen postings nicht schlau. wenn sich da aber doch lösungsansätze drin verstecken bitte ich um entschuldigung und um erneute erklärung dieser.
mfg
manu
Du hast nicht erklärt, wo Du libXext herhast und warum Du meintest, die irgendwie nachinstallieren zu müssen, obwohl sie zu Deinem XFree86 gehört. Du hättest nur, wie ich in meiner ersten Antwort schrieb, das XFree86-devel Paket nachinstallieren müssen.
Deine letzten Einwände kann ich nicht nachvollziehen. Um festzustellen, welche Pakete installiert werden müssen, um bestimmte Softwarepakete zu übersetzen oder um bestimmte Bibliotheken in eigenen Projekten benutzen zu können gibt es wahrlich bessere Möglichkeiten als die Suche über diese symbolischen Links. Selbst wenn es diese aber nicht gäbe sähe ich keinen Vorteil in der von Dir vorgeschlagenen Vorgehensweise: wenn man den Namen der eigentlichen Bibliothek bereits kennt kann man den Namen des Entwicklerpakets auch anhand des bereits installierten Laufzeitpakets ermitteln. Falls das nicht möglich ist gäbe es weiterhin die Möglichkeit, das Paket anhand der Headerdateien oder ggf. anhand der statischen Bibliotheken zu identifizieren. Benutzerfehler gibt es dabei so oder so, unabhängig davon, in welchem Paket sich nun die symbolischen Links befinden.
dragon's might
18.06.03, 22:24
Ich hab mit yum schon qt-devel installiert, aber bei mir kommt diese fehler meldung:
configure: WARNING: libjpeg not found. disable JPEG support.
checking for Qt... configure: error: Qt (>= Qt 3.0.2) (headers and libraries) not found. Please check your installation!
For more details about this problem, look at the end of config.log.
Wann immer jemand zwei Pakete hat, eines für zur Laufzeit benötigte Dateien, ein weiteres für Software-Entwicklung benötigte Dateien, warum sollte jemand optionale, nur für Software-Entwicklung benötigte Dateien oder Links in das Pakete mit den zur Laufzeit benötigten Dateien tun?
Laufzeitdateien in einem Paket. Entwicklungsdateien im anderen. Warum Laufzeit- und Entwicklungsumgebung vermischen?
Viel Spaß bei der Fehlerdiagnose, wenn die Linkerdateien installiert sind, die Header aber nicht. Siehe Deine Fehldiagnose von 16th June 2003 15:38.
Die *.so Links sind unnütz für jemanden, der keine Software zusammenlinkt. Sie sind umso sinnvoller in einem -devel Paket, da man durch sie bei der Suche nach libfoo.so auch das -devel Paket findet.
Du scheinst nicht sehr aufgeschlossen für naheliegende und konsequente Lösungen.
Ich betrachte diesen Exkurs für beendet. Und zwar aus folgendem Grund. Du begründest nicht, warum Du das Paketschema "merkwürdig" und "seltsam" findest oder was die Links im anderen Paket sollten. Meine Argumentation findet da ein Ende. Ich verstehe auch nicht, worum es Dir geht.
Ich hab mit yum schon qt-devel installiert, aber bei mir kommt diese fehler meldung:
configure: WARNING: libjpeg not found. disable JPEG support.
checking for Qt... configure: error: Qt (>= Qt 3.0.2) (headers and libraries) not found. Please check your installation!
For more details about this problem, look at the end of config.log.
Da wäre jetzt das Ende von config.log interessant. Aber ich vermute, Du hast Dich nach der Installation von qt-devel nicht aus- und wieder eingeloggt. echo $QTDIR muß den Pfad zum Qt root Verzeichnis ausgeben. Tut es aber erst nach neuem Einloggen.
Wann immer jemand zwei Pakete hat, eines für zur Laufzeit benötigte Dateien, ein weiteres für Software-Entwicklung benötigte Dateien, warum sollte jemand optionale, nur für Software-Entwicklung benötigte Dateien oder Links in das Pakete mit den zur Laufzeit benötigten Dateien tun?
Laufzeitdateien in einem Paket. Entwicklungsdateien im anderen. Warum Laufzeit- und Entwicklungsumgebung vermischen?
In der Vergangenheit wurde diese Trennung nicht vorgenommen, was wohl einer der Gründe ist, warum mich diese Vorgehensweise verwundert.
Viel Spaß bei der Fehlerdiagnose, wenn die Linkerdateien installiert sind, die Header aber nicht. Siehe Deine Fehldiagnose von 16th June 2003 15:38.
Der Übersetztungsprozess findet vor dem Linkprozess statt, das Fehlen der Header wird vom compiler entsprechend kommentiert, bzw. der Übersetzungsvorgang abgebrochen. Ich verstehe deshalb nicht, wieso die Abwesenheit der symbolischen Links Vorteile bei der Fehleranalyse erbringen soll (die wenigsten Benutzer können abgesehen davon so oder so etwas mit den Fehlern anfangen).
Die *.so Links sind unnütz für jemanden, der keine Software zusammenlinkt. Sie sind umso sinnvoller in einem -devel Paket, da man durch sie bei der Suche nach libfoo.so auch das -devel Paket findet.
Du scheinst nicht sehr aufgeschlossen für naheliegende und konsequente Lösungen.
Dein Vorschlag ist nicht konsequent. Es z.B. gibt eine ganze Reihe von Bibliotheken, die lediglich in statischer Form vorliegen (z.B. libpci), bei denen also der jeweilige .so Link nicht als Kriterium für die Suche nach dem Entwicklerpaket herangezogen werden kann, was es wiederum als einheitliches Suchkriterum ausscheiden läßt. Ebenso gibt es durchaus diverse Fälle, in denen symbolische Links unmittelbar zur Laufzeit benutzt werden (dlopen() allgemein, z.B. libGL.so, libnss_*, ...).
Ich betrachte diesen Exkurs für beendet. Und zwar aus folgendem Grund. Du begründest nicht, warum Du das Paketschema "merkwürdig" und "seltsam" findest oder was die Links im anderen Paket sollten. Meine Argumentation findet da ein Ende. Ich verstehe auch nicht, worum es Dir geht.
Ich habe durchaus begründet, warum ich es für seltsam halte; es ergeben sich aus meiner Sicht keine nennenswerten Vorteile. Ich finde es allerdings auch merkwürdig, daß viele Mitglieder dieses Forums auf jede Meinungsverschiedenheit mit "Du bist doof, mit Dir will ich nicht mehr reden!" reagieren. Die Welt ist nicht schwarz-weiß, in vielen Fällen (auch hier) gibt es keine "richtige" oder "falsche" Lösung und es sollte jedem erlaubt sein, seine eigene Meinung zu vertreten.
dragon's might
19.06.03, 19:20
Original geschrieben von Belkira
Da wäre jetzt das Ende von config.log interessant. Aber ich vermute, Du hast Dich nach der Installation von qt-devel nicht aus- und wieder eingeloggt. echo $QTDIR muß den Pfad zum Qt root Verzeichnis ausgeben. Tut es aber erst nach neuem Einloggen.
Es geht! Danke! Es lebe der rote hut! :D
In der Vergangenheit wurde diese Trennung nicht vorgenommen, was wohl einer der Gründe ist, warum mich diese Vorgehensweise verwundert.
Dich verwundert, daß jemand irgendwann erkannt hat, daß die .so Links in den Laufzeitpaketen unnütz sind? Muß ich nicht nachvollziehen können, oder?
Verwundert es Dich auch, wenn jemand andere ungenutzte Dateien aus einem Paket rauswerfen würde, um Platz und inodes zu sparen?
Der Übersetztungsprozess findet vor dem Linkprozess statt,
Konfigurations- und Systemanalyseprozesse finden noch früher statt. Nicht jeder Library-Check erfolgt per Compilierung.
Ich verstehe deshalb nicht, wieso die Abwesenheit der symbolischen Links Vorteile bei der Fehleranalyse erbringen soll (die wenigsten Benutzer können abgesehen davon so oder so etwas mit den Fehlern anfangen).
Der Großteil der User schaut in /usr/lib nach und meint, die Library sei vorhanden. Hingegen ist die Kenntnis bezüglich Include Dateien kaum existent. Nun gut, das ist meine persönliche Erfahrung im Umgang mit anderen Usern. Muß nicht Deiner entsprechen.
Dein Vorschlag ist nicht konsequent. Es z.B. gibt eine ganze Reihe von Bibliotheken, die lediglich in statischer Form vorliegen (z.B. libpci), bei denen also der jeweilige .so Link nicht als Kriterium für die Suche nach dem Entwicklerpaket herangezogen werden kann, was es wiederum als einheitliches Suchkriterum ausscheiden läßt.
Beiß Dich nicht an einem Beispiel fest. Ein simple Anfrage nach foo.so bei z.B. rpmfind.net soll ein -devel Paket ergeben. Eine Suchanfrage nach libfoo* sollte auch das -devel Paket als Ergebnis haben. Nur so findet der nach einer Library suchende User alles, was er braucht.
Ebenso gibt es durchaus diverse Fälle, in denen symbolische Links unmittelbar zur Laufzeit benutzt werden (dlopen() allgemein, z.B. libGL.so, libnss_*, ...).
Was aber absolut nichts mit Software-Entwicklung zu tun hat. Natürlich werden solche Module (Plug-ins) nicht in ein -devel Paket gelegt, wenn sie zwingend zur Laufzeit gebraucht werden.
Ein gutes Beispiel, wo ein *.so Link im -devel Paket sogar zu Problemen führt, ist openssl-devel bei Red Hat Linux 9. Konqueror dlopen'ed OpenSSL und scheitert, weil openssl-devel nicht zu den Paketabhängigkeiten gehört und deswegen nicht installiert ist.
Ich habe durchaus begründet, warum ich es für seltsam halte;
Darunter verstünde ich mehr eine Begründung, warum die *.so Links nicht in den -devel Paketen sein sollten.
Es gibt welche, die argumentieren völlig anders und sind der Ansicht, Festplatten seien groß genug, pro Software reiche ein Paket. Auch eine Sichtweise. Ich muß sowas aber nicht gutheißen, nur weil faule Packager in der Vergangenheit gleich lib*.so.* oder gar lib* in ein Paket gepackt haben und nur die Header in ein anderes.
Dich verwundert, daß jemand irgendwann erkannt hat, daß die .so Links in den Laufzeitpaketen unnütz sind? Muß ich nicht nachvollziehen können, oder?
Verwundert es Dich auch, wenn jemand andere ungenutzte Dateien aus einem Paket rauswerfen würde, um Platz und inodes zu sparen?
Ich sehe die symbolischen Links als zu den Bibliotheken gehörig und nicht als irgendwelche Dateien, die irgendwo auf dem System herumliegen, weil sich jemand gedacht hat, daß es schön wäre diese mit dem einen oder anderen Paket willkürlich zu installieren.
Konfigurations- und Systemanalyseprozesse finden noch früher statt. Nicht jeder Library-Check erfolgt per Compilierung.
Dann sollten diese Prüfungen überarbeitet werden; wenn ein Entwickler zwar eine Bibliothek nutzen möchte, sich aber nicht der Verfügbarkeit der Headerdateien vergewissert, so kann man nur davon ausgehen, daß er vor hat, diese in nicht standardkonformer Weise zu nutzen.
Der Großteil der User schaut in /usr/lib nach und meint, die Library sei vorhanden. Hingegen ist die Kenntnis bezüglich Include Dateien kaum existent. Nun gut, das ist meine persönliche Erfahrung im Umgang mit anderen Usern. Muß nicht Deiner entsprechen.
Diese Benutzer werden aber wohl auch kaum auf die Idee kommen, anhand von speziellen symbolischen Links nach Entwicklerpaketen zu suchen.
Beiß Dich nicht an einem Beispiel fest. Ein simple Anfrage nach foo.so bei z.B. rpmfind.net soll ein -devel Paket ergeben. Eine Suchanfrage nach libfoo* sollte auch das -devel Paket als Ergebnis haben. Nur so findet der nach einer Library suchende User alles, was er braucht.
Die Laufzeit und Entwicklerpakete werden dabei im allgemeinen beide von der jeweiligen Suchmaschine ermittelt und/oder verweisen auf das Partnerpaket. Ich halte die symbolischen Links als Suchschlüssel auch weiterhin nicht für einmalig, geschweigedenn für besonders gut geeignet.
Was aber absolut nichts mit Software-Entwicklung zu tun hat. Natürlich werden solche Module (Plug-ins) nicht in ein -devel Paket gelegt, wenn sie zwingend zur Laufzeit gebraucht werden.
Inwiefern hat das nichts mit Softwareentwicklung zu tun? Es wird mit dlopen() durchaus nicht nur auf Module (die im übrigen auch dynamische Bibliotheken sind) für spezielle Softwarepakete zugegriffen, sondern auch auf reguläre dynamische Bibliotheken; bestes Beispiel: OpenGL Implementationen.
Ein gutes Beispiel, wo ein *.so Link im -devel Paket sogar zu Problemen führt, ist openssl-devel bei Red Hat Linux 9. Konqueror dlopen'ed OpenSSL und scheitert, weil openssl-devel nicht zu den Paketabhängigkeiten gehört und deswegen nicht installiert ist.
Dieses Argument unterstützt nicht Deinen Standpunkt.
Darunter verstünde ich mehr eine Begründung, warum die *.so Links nicht in den -devel Paketen sein sollten.
Es gibt welche, die argumentieren völlig anders und sind der Ansicht, Festplatten seien groß genug, pro Software reiche ein Paket. Auch eine Sichtweise. Ich muß sowas aber nicht gutheißen, nur weil faule Packager in der Vergangenheit gleich lib*.so.* oder gar lib* in ein Paket gepackt haben und nur die Header in ein anderes.
Es gibt keinen guten technischen Grund, warum die symbolischen Links von den eigentlichen Bibliotheken getrennt verpackt werden sollten; es gibt technische Gründe, warum sie nicht getrennt verpackt werden sollten, auch wenn sie im Regelfall nicht in's Gewicht fallen. Der von den symbolischen Links belegte Speicherplatz ist angesichts der Größe der Bibliotheken und der Anzahl von Dateien auf einem durchschnittlichen UNIX Dateisystem irrelevant.
Ich sehe die symbolischen Links als zu den Bibliotheken gehörig
Das ist mal eine Begründung. Die von ldconfig erzeugten Links sehe ich als zugehörig. Die anderen (*.so) nicht. Die sind überflüssig oder stören sogar nur, wenn verschiedene Versionen einer Library installiert sind.
Diese Benutzer werden aber wohl auch kaum auf die Idee kommen, anhand von speziellen symbolischen Links nach Entwicklerpaketen zu suchen.
Diese Art von Suche ist Standard bei z.B. rpmfind.net und sogar offiziell vorgesehen.
Es wird mit dlopen() durchaus nicht nur auf Module (die im übrigen auch dynamische Bibliotheken sind) für spezielle Softwarepakete zugegriffen, sondern auch auf reguläre dynamische Bibliotheken; bestes Beispiel: OpenGL Implementationen.
Das ist kein Grund, einen *.so Namen für alle Libraries zu installieren und fest in den Paketen zu verankern. Ohnehin scheinen mir mehr Pakete gegen libGL.so.1 gelinkt zu sein:
$ rpm --redhatrequires /usr/lib/libGL.so /usr/X11R6/lib/libGL.so libGL.so
no package requires /usr/lib/libGL.so
no package requires /usr/X11R6/lib/libGL.so
no package requires libGL.so
$ rpm --redhatrequires libGL.so.1
chromium-0.9.12-21
Gtk-Perl-0.7008-31
kdeartwork-3.1-3
kdegraphics-3.1-5
PyQt-3.5-5
qt-3.1.1-6
qt-designer-3.1.1-6
qt-devel-3.1.1-6
qt-MySQL-3.1.1-6
qt-ODBC-3.1.1-6
qt-PostgreSQL-3.1.1-6
qt-Xt-3.1.1-6
redhat-lsb-1.3-1
tuxracer-0.61-19
xawtv-3.81-6
XFree86-libs-4.3.0-2
XFree86-tools-4.3.0-2
xmms-1.2.7-21.p
xscreensaver-4.07-2
xtraceroute-0.9.0-14
Dieses Argument unterstützt nicht Deinen Standpunkt.
Hab ich das behauptet? :) Werd mal locker. ;) :rolleyes: Ich vertrete ja nicht den Standpunkt, daß die -devel Lösung fehlerunanfällig oder gar idiotensicher sei. Ich halte den Ansatz, Laufzeit- und Entwicklungsdateien zu trennen, für prima.
Das ist mal eine Begründung. Die von ldconfig erzeugten Links sehe ich als zugehörig. Die anderen (*.so) nicht. Die sind überflüssig oder stören sogar nur, wenn verschiedene Versionen einer Library installiert sind.
Gut, akzeptiert.
Diese Art von Suche ist Standard bei z.B. rpmfind.net und sogar offiziell vorgesehen.
Gut, von mir aus. Ob allerdings im Zusammenhang mit RPM geschaffene "Standards" für empfehlenswert zu erachten sind ist wiederum eine andere Frage...
Das ist kein Grund, einen *.so Namen für alle Libraries zu installieren und fest in den Paketen zu verankern. Ohnehin scheinen mir mehr Pakete gegen libGL.so.1 gelinkt zu sein:
Das hängt mit der internen .so Versionskennung zusammen (aus diesem Grund sind X11 Anwendungen auch z.B. gegen libX11.so.6 gelinkt); aktuelle OpenGL Implementationen setzen OpenGL 1.2/1.3 um. Du hattest das zu einem früheren Zeitpunkt auch schon festgehalten. Für Anwendungen, die bewußt nicht direkt gegen bestimmte OpenGL Versionen gelinkt werden und auf anderem Wege überprüfen, ob die gewünschte Funktionalität auch angeboten wird, sind die symbolischen Links aber vorzuziehen; Quake3 (ist vielleicht nicht das beste Beispiel, da sich der gewünschte Name der Bibliothek auch konfigurieren läßt) sollte so z.B. in Zukunft auch mit OpenGL 2.0 Implementationen (libGL.so.2*) funktionieren und daher eher libGL.so als libGL.so.1 zu laden versuchen.
Hab ich das behauptet? :) Werd mal locker. ;) :rolleyes: Ich vertrete ja nicht den Standpunkt, daß die -devel Lösung fehlerunanfällig oder gar idiotensicher sei. Ich halte den Ansatz, Laufzeit- und Entwicklungsdateien zu trennen, für prima.
Zumindest in dem Punkt sind wir uns dann wohl einig ;)
Fusel Wusel
20.06.03, 18:25
[EDIT] Das Problem hat sich erledigt. Hab mich durch verschiedene Paketinstallationen gewurschtelt und hänge jetzt an dem altbekannten QT3-Problem fest :rolleyes:
dragon's might
20.06.03, 23:38
ok neues problem:
checking for libz... -lz
checking for libpng... no
checking for libjpeg6b... no
checking for libjpeg... no
configure: WARNING: libjpeg not found. disable JPEG support.
checking for Qt... libraries /usr/lib/qt-3.1/lib, headers /usr/lib/qt-3.1/include using -mt
checking if Qt compiles without flags... no
checking for moc... /usr/lib/qt-3.1/bin/moc
checking for uic... /usr/lib/qt-3.1/bin/uic
checking if Qt needs ... sed: -e expression #1, char 0: No previous regular expression
yes
checking for Qt... (cached) libraries /usr/lib/qt-3.1/lib, headers /usr/lib/qt-3.1/include using -mt
checking if Qt compiles without flags... (cached) no
checking for moc... /usr/lib/qt-3.1/bin/moc
checking for uic... /usr/lib/qt-3.1/bin/uic
checking if Qt needs ... (cached) yes
checking for KDE... checking for rpath... yes
configure: error:
in the prefix, you've chosen, are no KDE headers installed. This will
fail.
So, check this please and use another prefix!
Was muss ich für kde mit yum nachinstallieren? kdebase-devel habe ich schon!
Und wie bekomme ich libjpg-support? yum install libjpg bringt nichts :(
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.