Jens Koesling schrieb:

...

...

ich versuche gerade den Mplayer zu installieren. Leider kann er die Datei libxvidcore.blah.blah nicht finden.

...

In dem Du RPMs von Packman benutzt:

Hmm, daher hab ich das RPM, welches ich versuche zu installieren...

Moin! Ich dachte du hast kompiliert? Oder meinst du Das Quellen-Paket?

Okay dass es nicht mit RPM so geht, versteh ich...

wenn du rpms installierst, geht es auch mit rpm.

Ist die Datei (libxvidcore.....) nachdem sie in /usr/local/lib installiert ist überall im System nutzbar??? Muss ich um die Datei nutzen zu können noch eine Pfad Variable setzen?

/usr/local/lib ist bei Suse nicht in Gebrauch, /usr/lib sollte all die libxvidcor... Dateiern enthalten, was auch der Fall ist, wenn du das Paket http://ftp.gwdg.de/linux/suse/apt/SuSE/9.0-i386/RPMS.packman/xvid-0.9.9_1.0.... ^^^^^^ (Nicht SRPMS) installierst. Sven

Am Dienstag, 17. Februar 2004 22:10 schrieb Jens Koesling:

Hmm, kann ich denn das Verzeichnis und damit die Datei nicht trotzdem nutzbar machen, oder muss ich für selber compilierte Programme das ./configure anpassen??

Ich bin zwar kein Spezialist, aber ich versuche es mal so zu erklären wie ich es verstanden habe, um die Spezis davon zu entlasten. Die Programme können grundsätzlich auf alle Dateien zugreifen, die in den dafür definierten Pfaden liegen. Trotzdem gibt es Probleme, wenn du ein RPM installieren willst, das auf eine Bibliothek zugreifen will (muss) die zwar vorhanden ist, aber nicht aus einem RPM stammt. Da diese Bibliothek dadurch nicht in der RPM-Datenbank eingetragen wurde, meckert das zu installierende RPM das die Datei nicht vorhanden wäre, obwohl sie es ist. Fazit, das Programm würde sicher funktionieren, da es die Bibliothek bei richtiger Installation im richtigen Pfad nutzen könnte, aber es würde immer eine nicht erfüllte Abhängigkeit existieren. Deshalb nutze ich wie schon weiter oben erwähnt nach Anpassung des ./configure auch checkinstall, weil es für Anfänger die einfachste art ist (glaube ich) ein RPM zu erstellen und einzuspielen. hth Frank

Hallo, Am Tue, 17 Feb 2004, Dieter Kluenter schrieb:

Natürlich können, und sollten auch, alle selbst erstellten Biliotheken und Headerdateien, die nicht vom System installiert wurden, in /usr/local installiert werden. Der GNU Linker '/usr/bin/ld', also das Tool, das die Bibliotheken einbindet, wird über /etc/ld.config konfiguriert.

NEIN. Ueber /etc/ld.so.conf wird der dynamische lader /lib/ld-linux.so (alias /lib/ld.so), der _zur Laufzeit_ die libs laedt, konfiguriert.

Mit '/sbin/ldconfig' werden alle in ld.config aufgeführten Pfade abgeklappert und alle vorhandenen Dateien in einer Hashdatei '/etc/ld.so.cache' aufgelistet.

Das stimmt -- aber fuer ld-linux!

Bei einer Kompilation wird dann alle im Cache vorhanden shared Libraries bereitgestellt.

Nein. Einfaches Beispiel: ==== dh@slarty[5]: ~ (0)$ cd /tmp/test dh@slarty[5]: /tmp/test (0)$ PS1="\$?$ " 0$ grep X11 /etc/ld.so.conf | head -1 /usr/X11R6/lib 0$ echo 'int main(void){return 0;}' > test_ld.c 0$ gcc -lX11 -o test_ld test_ld.c /usr/bin/ld: cannot find -lX11 collect2: ld returned 1 exit status 1$ ls -l test_ld ls: test_ld: No such file or directory 1$ gcc -L/usr/X11R6/lib -lX11 -o test_ld test_ld.c 0$ ls -l test_ld -rwxr-xr-x 1 dh dh 11675 Feb 18 04:37 test_ld 0$ ldd ./test_ld libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40028000) libc.so.6 => /lib/libc.so.6 (0x400d0000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) 0$ ./test_ld 42$ ==== Der _gcc_ (genauer dessen ld-wrapper collect2) bzw. der linker (/usr/bin/ld) haben einen Suchpfad, der default-maessig /lib, /usr/lib, /usr/local/lib und /usr/$arch/lib/ enthaelt. ==== 42$ rm test_ld 0$ gcc -c -o test_ld.o test_ld.c 0$ ld --verbose -lX11 -o test_ld test_ld.o /usr/lib/crt1.o attempt to open /usr/lib/libX11.so failed attempt to open /usr/lib/libX11.a failed attempt to open /lib/libX11.so failed attempt to open /lib/libX11.a failed attempt to open /usr/lib/libX11.so failed attempt to open /usr/lib/libX11.a failed attempt to open /usr/local/lib/libX11.so failed attempt to open /usr/local/lib/libX11.a failed attempt to open /usr/i686-pc-linux/lib/libX11.so failed attempt to open /usr/i686-pc-linux/lib/libX11.a failed ld: cannot find -lX11 1$ ld --verbose -L/usr/X11R6/lib -lX11 -o test_ld test_ld.o /usr/lib/crt1.o attempt to open /usr/X11R6/lib/libX11.so succeeded -lX11 (/usr/X11R6/lib/libX11.so) attempt to open test_ld.o succeeded test_ld.o attempt to open /usr/lib/crt1.o succeeded /usr/lib/crt1.o libc.so.6 needed by /usr/X11R6/lib/libX11.so found libc.so.6 at /lib/libc.so.6 ld-linux.so.2 needed by /lib/libc.so.6 found ld-linux.so.2 at /lib/ld-linux.so.2 0$ ==== Wie man hier sieht, muss man (per -L) das Verzeichnis explizit angeben wenn die lib nicht in einem der 3 Standardverzeichnisse liegt. Und man sieht schoen, wie ld nach der lib sucht. Achso, bevor sich jemand wundert: das zuletzt erzeugte ist _NICHT_ ausfuehrbar, da fehlen noch ein paar Sachen, die lustige Effekte zeigen: ==== 0$ ls -l ./test_ld -rwxr-xr-x 1 dh dh 9741 Feb 18 04:45 ./test_ld 0$ file ./test_ld ./test_ld: ELF 32-bit LSB executable, Intel 80386, version 1, dynamically linked (uses shared libs), not stripped 0$ ldd ./test_ld /usr/bin/ldd: ./test_ld: No such file or directory 1$ ./test_ld bash: ./test_ld: No such file or directory 127$ rm ./test_ld 0$ gcc -v -L/usr/X11R6/lib -lX11 -o test_ld test_ld.o Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/pgcc-2.95.3/specs gcc version pgcc-2.95.3 19991024 (AMD-20000925-1) /usr/local/lib/gcc-lib/i686-pc-linux-gnu/pgcc-2.95.3/collect2 -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o test_ld /usr/lib/crt1.o /usr/lib/crti.o /usr/local/lib/gcc-lib/i686-pc-linux-gnu/pgcc-2.95.3/crtbegin.o -L/usr/X11R6/lib -L/usr/local/lib/gcc-lib/i686-pc-linux-gnu/pgcc-2.95.3 -L/usr/local/lib -lX11 test_ld.o -lgcc -lc -lgcc /usr/local/lib/gcc-lib/i686-pc-linux-gnu/pgcc-2.95.3/crtend.o /usr/lib/crtn.o 0$ ldd ./test_ld libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40028000) libc.so.6 => /lib/libc.so.6 (0x400d0000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) 0$ ./test_ld 42$ ==== *grins* Achso, dass im Quelltext nicht auf die libX11 zugegriffen wird ist hier irrelevant. Ein 'unresolved symbol' kommt erst spaeter: ==== 42$ cp ~/src/misc/xnumlock.c ./test_ld.c 0$ gcc -lX11 -o test_ld test_ld.c /usr/bin/ld: cannot find -lX11 collect2: ld returned 1 exit status 1$ gcc -L/usr/X11R6/lib -o test_ld test_ld.c /tmp/ccITWt5s.o: In function `main': /tmp/ccITWt5s.o(.text+0xc): undefined reference to `XOpenDisplay' [..] collect2: ld returned 1 exit status 1$ gcc -L/usr/X11R6/lib -lX11 -o test_ld test_ld.c /tmp/ccWFCOSM.o: In function `main': /tmp/ccWFCOSM.o(.text+0x48): undefined reference to `XTestFakeKeyEvent' [..] collect2: ld returned 1 exit status 1$ gcc -L/usr/X11R6/lib -lX11 -lXtst -o test_ld test_ld.c 0$ ldd ./test_ld libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40028000) libXtst.so.6 => /usr/X11R6/lib/libXtst.so.6 (0x400d0000) libc.so.6 => /lib/libc.so.6 (0x400d6000) libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x401b8000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000 0$ ==== So, und der Vollstaendigkeit halber auch noch, was ld-linux, der dynamische Linker, dann unter anderem so macht: ==== 0$ LD_LIBRARY_PATH="" LANG="C" strace -eopen ./test_ld open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 open("/usr/X11R6/lib/libX11.so.6", O_RDONLY) = 3 open("/usr/X11R6/lib/libXtst.so.6", O_RDONLY) = 3 open("/lib/libc.so.6", O_RDONLY) = 3 open("/usr/X11R6/lib/libXext.so.6", O_RDONLY) = 3 open("/home/dh/.Xauthority", O_RDONLY) = 4 open("/usr/X11R6/lib/X11/locale/locale.alias", O_RDONLY) = 4 open("/usr/X11R6/lib/X11/locale/locale.dir", O_RDONLY) = 4 open("/usr/X11R6/lib/X11/locale/C/XLC_LOCALE", O_RDONLY) = 4 ==== Alle Klarheiten beseitigt? F'up2: suse-programming -dnh -- 278: Shareware-Link Folge des Patents der British Telekom auf Hyperlinks: US-A-4,873,662 (Raphael H. Becker)

Am Dienstag, 17. Februar 2004 22:10 schrieb Jens Koesling:

Hmm, kann ich denn das Verzeichnis und damit die Datei nicht trotzdem nutzbar machen, oder muss ich für selber compilierte Programme das ./configure anpassen??

Nö, es ist völlig wurscht, wo die Datei liegt, RPM weiß nichts davon, deshalb soll man auch auf einem RPM-Basierten System niemals Software mit 'make install' einspielen. Bibliotheken, die von anderen Programmen benötigt werden schon zweimal nicht. Du darfst dabei auch den Sicherheitsaspekt nicht aus den Augen verlieren. Wenn Du per RPM libxy einspielst, dann landet die unter /usr/lib/libxy.so.version, wenn Du dann einfach mit './configure', 'make' und 'make install' eine neuere Version installierst, dann landet die unter /usr/local/lib/libxy.so.version. Da /usr/local/lib bevorzugt verwendet wird, kommt die Version aus /usr/lib/ nicht mehr zum Zuge, für RPM ist die aber immer noch die aktuelle. Findet sich dann ne Sicherheitslücke, stellt SuSE ein Update zur Verfügung, dass man sich per YOU installiert, bringt aber nichts, weil eine selbstcompilierte Variante bevorzugt wird. Das System bleibt somit (trotz Sicherheitsupdate) angreifbar. Von Problemen nach einem Update, da liegt dann vielleicht eine inkompatible Version in /usr/local/lib, die dank glibc, gcc oder sonstiger Änderungen nur noch abstürzt und mit ihr alle Programme, die die lib nutzen. Bau ein RPM und die Probleme stellen sich nicht. -- Machs gut | http://www.iivs.de/schwinde/buerger/tremmel/ | http://packman.links2linux.de/ Manfred | http://www.knightsoft-net.de

Thomas Hertweck schrieb:

Sven Burmeister wrote:

...

[...]

/usr/local/lib ist bei Suse nicht in Gebrauch, /usr/lib sollte all die libxvidcor... Dateiern enthalten, was auch der Fall ist, wenn du das Paket [...Downloadadresse...] installierst.

Wie kommst Du denn auf die Idee? Natuerlich ist /usr/local/lib bei SuSE "in Gebrauch", was immer Du damit meinst.

Hast du schonmal reingeschaut? Ist leer. In Gebrauch heißt bei mir also folglich, das Suse nichts in /usr/local/lib installiert. Man vielleicht, aber nicht Suse. Sven

Hallo, Am Wed, 18 Feb 2004, Philipp Thomas schrieb:

Sven Burmeister [18 Feb 2004 01:16:41 +0100]:

...

Hast du schonmal reingeschaut? Ist leer. In Gebrauch heißt bei mir also folglich, das Suse nichts in /usr/local/lib installiert.

Alles andere wäre auch falsch :) /usr/local ist, wie der Name schon sagt, für lokal installierte Sachen. Was hier installiert wird, lässt die Distribution unangetastet.

ACK. Und das ist auch gut so. # du -hs --exclude=/usr/local/games /usr/local/ 2.6G /usr/local *grins* Ja, hab ne Menge nachinstalliert ;)

BTW, das Einzige, was man *nicht* unter /usr/local installieren sollte, ist ein alternativer gcc. Den sollte man tunlichst nach /opt oder so installieren, sonst bringt man den von der Distribution installierten gcc gehörig durcheinander.

Hm. Kannst du dazu (auf suse-programming) elaborieren? Ich hab hier: $ ls -l `which gcc` -rwxr-xr-x 2 root root 100661 Dec 8 2000 /usr/local/bin/gcc $ gcc -v Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/pgcc-2.95.3/specs gcc version pgcc-2.95.3 19991024 (AMD-20000925-1) Und hatte -- abgesehen von den zu erwartenden Problemen, dass manche configure-scripte die gcc-Version nicht richtig parsen wollten -- keinen Aerger. Und die damit kompilierte Software (u.a. Kernel 2.2.1x, 2.4.0-test{1,4}, 2.4.16 und 2.4.24) laeuft sauber. Und das obwohl ich in /usr noch nen aelteren gcc habe. Das ist wohl eine RH-gcc-2.95.2, aber das ist ein anderes Thema, da ich damals IIRC ein wuestes Gewurschtel mit egcs/gcc veranstaltet habe. Die saubere Installation von o.g. war dann echt ein Fortschritt *lol* Aber -- grad getestet -- der /usr/bin/gcc tut's wohl noch (ja, hab auch was kompiliert) ;) $ /usr/bin/gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.95.2/specs gcc version 2.95.2 19991024 (release) Liegt's daran, dass der pgcc-2.95.3 in /usr/local praktisch ein Pentium-patch+Athlon-patch zum gcc-2.95.2 ist? Naja, ich verwende seit ~3 Jahren eh nur noch den gcc in /usr/local. Ich sollte wohl mal den gcc in /usr deinstallieren... -dnh PS: NICHT NACHMACHEN! Philipp weiss wovon er redet! -- 151: SUN recommended patches Mit den Patches ist es wie mit dem Bier nach einer durchzechten Nacht. Einer wird wohl schlecht gewesen sein. (Störungsmeldung der Uni Jena)

Hallo, Am Wed, 18 Feb 2004, Philipp Thomas schrieb:

* David Haller (david@dhaller.de) [20040218 05:52]:

...

Hm. Kannst du dazu (auf suse-programming) elaborieren? Ich hab hier:

Mach mal ein 'gcc -print-search-dirs', dann wird es dir evtl. klarer :)

Sorry, ich kann da keine Konflikte finden. Aber ich glaub ich weiss warum, denn die gcc's verwenden eine unterschiedliche Architektur. /usr/bin/gcc ist i386 kompiliert, /usr/local/bin/gcc ist ein gcc-2.95.2 + pgcc-2.95.3 patch + athlon patch fuer i686 kompiliert... /usr/bin/gcc sucht u.a. in /usr/lib/gcc/i386-redhat-linux/ und /usr/local/bin/gcc sucht u.a. in /usr/lib/gcc/i686-pc-linux-gnu/. Meintest du das? Allerdings findet sich Dateien nur jeweils in einem nochmal versionierten Unterverzeichnis (2.95.2 bzw. pgcc-2.95.3) bzw. /usr/[/local]/lib/gcc gibt's bei mir gar net. Also auch bei gleicher Architektur duerfte es keinen Konflikt geben. Waere das bei einem mit --prefix=/opt/gcc-version-foo statt --prefix=/usr/local denn anders? Wuerde der nicht ebenso in /usr/lib suchen? Der /usr/bin/gcc sucht jedenfalls nicht in /usr/local und der /usr/local/bin/gcc hat keine Files in /usr/lib/... -dnh -- "Gna, schon wieder Seti [...] Dabei ist es schon schwierig genug, auf *diesem* Planeten intelligentes Leben zu finden." -- Charly Kuehnast

* Thomas Hertweck (Thomas.Hertweck@gpi.uni-karlsruhe.de) [20040218 10:14]:

Hier gibt es schlicht ein /usr/local/gcc3.3 auf meiner SuSE 8.0,

Das ist dann auch in Ordnung. Ich meinte den Default bei GCC und der ist --prefix=/usr/local. Damit landen die Sachen aber eben in /usr/local/{bin,lib,include} und damit kommt er sich mit einem mit --prefix=/usr kompilierten gcc u.U. ins Gehege. Philipp -- SUSE LINUX AG, Maxfeldstr. 5, D-90409 Nuremberg, Germany