sonnenblen.de - Das unabhängige Sun User Forum
Software => Programmieren, Kompilieren => Thema gestartet von: oobi007 am 07. März 2007, 10:08:47
-
Hallo,
ich bekomme beim configure immer die folgende Meldung (Ultra60 mit Solaris10, GCC):
configure:37478: ./conftest
ld.so.1: conftest: fatal: libiconv.so.2: open failed: No such file or directory
./configure: line 37479: 43 Killed ./conftest$ac_exeext
configure:37481: $? = 137
configure: program exited with status 137
Woran kann das liegen? Die Datei
ld.so.1 ist in /usr/lib (link) + /usr/lib/sparcv9 (link) + /etc/lib (link) + /lib/sparcv9 + /lib
libiconv.so.2 ist in /usr/local/lib
Ich habe schon die LD_LIBRARY_PATH angepasst, das bringt aber auch nichts.
-
... libiconv.so.2: open failed: No such file or directory
Hallo,
schau mal, ob dieses Library (libiconv) vorhanden ist. Die wird von den neueren GCC benötigt.
Gruß
escimo
-
libiconv 1.11 habe ich installiert.
Daran liegts nicht
-
Auf die Entfernung ist das nicht einfach zu sagen Oliver. Ein Paar mehr Details wären nett:
- Welches Programm beziehungsweise welche Anwendung möchtest du übersetzen?
- Welche Version der GCC-Compiler wird verwendet?
- 32-/64-Bit Anwendung/Programm?
- Inhalt des /lib-Verzeichnisses (/usr/lib) einstellen
- Was gibt... <# echo $PATH> ...zurück.
- Was gibt... <# echo $LD_LIBRARY_PATH> ...zurück.
-
Das Programm ist der Mainframe-Emulator Hercules Version 3.04
GCC Version 3.4.6
Ich denke es ist ein 32 bit-Programm
echo $PATH=/usr/bin:/usr/openwin/bin:/usr/ucb
die LD_LIBRARY_PATH ist leer, die habe ich schon versuchsweise mit /usr/local/lib und /usr/lib gesetzt
$ ls /lib
32 libmvec.so.1 llib-ldevid
64 libnsl.so llib-ldevid.ln
cpp libnsl.so.1 llib-ldevinfo
cpu libnvpair.so llib-ldevinfo.ln
ld.so.1 libnvpair.so.1 llib-ldl
liba5k.so libpam.so llib-ldl.ln
liba5k.so.2 libpam.so.1 llib-ldoor
libadm.so libposix4.so llib-ldoor.ln
libadm.so.1 libposix4.so.1 llib-lefi
libaio.so libproc.so llib-lefi.ln
libaio.so.1 libproc.so.1 llib-lelf
libavl.so.1 libpthread.so llib-lelf.ln
libbsm.so libpthread.so.1 llib-lgen
libbsm.so.1 libresolv.so llib-lgen.ln
libc.so libresolv.so.1 llib-lintl
libc.so.1 libresolv.so.2 llib-lintl.ln
libc_db.so librestart.so.1 llib-lkstat
libc_db.so.1 librpcsvc.so llib-lkstat.ln
libcmd.so librpcsvc.so.1 llib-lm
libcmd.so.1 librt.so llib-lm.ln
libcmdutils.so.1 librt.so.1 llib-lmd5
libcontract.so librtld.so.1 llib-lmd5.ln
libcontract.so.1 librtld_db.so llib-lnsl
libctf.so librtld_db.so.1 llib-lnsl.ln
libctf.so.1 libscf.so llib-lnvpair
libcurses.so libscf.so.1 llib-lnvpair.ln
libcurses.so.1 libsec.so llib-lpam
libdevice.so libsec.so.1 llib-lpam.ln
libdevice.so.1 libsecdb.so llib-lposix4
libdevid.so libsecdb.so.1 llib-lposix4.ln
libdevid.so.1 libsendfile.so llib-lpthread
libdevinfo.so libsendfile.so.1 llib-lpthread.ln
libdevinfo.so.1 libsocket.so llib-lresolv
libdhcpagent.so.1 libsocket.so.1 llib-lresolv.ln
libdhcputil.so.1 libsysevent.so llib-lrt
libdl.so libsysevent.so.1 llib-lrt.ln
libdl.so.1 libtermcap.so llib-lrtld_db
libdladm.so.1 libtermcap.so.1 llib-lrtld_db.ln
libdlpi.so.1 libtermlib.so llib-lscf
libdoor.so libtermlib.so.1 llib-lscf.ln
libdoor.so.1 libthread.so llib-lsec
libefi.so libthread.so.1 llib-lsec.ln
libefi.so.1 libthread_db.so llib-lsecdb
libelf.so libthread_db.so.1 llib-lsecdb.ln
libelf.so.1 libtsnet.so.1 llib-lsendfile
libg_fc.so libtsol.so llib-lsendfile.ln
libg_fc.so.2 libtsol.so.2 llib-lsocket
libgen.so libumem.so llib-lsocket.ln
libgen.so.1 libumem.so.1 llib-lsysevent
libinetcfg.so.1 libuuid.so llib-lsysevent.ln
libinetutil.so.1 libuuid.so.1 llib-ltermcap
libintl.so libuutil.so.1 llib-ltermcap.ln
libintl.so.1 libw.so llib-ltermlib
libkstat.so libw.so.1 llib-ltermlib.ln
libkstat.so.1 libxnet.so llib-lthread
liblaadm.so.1 libxnet.so.1 llib-lthread.ln
libld.so.2 libzfs.so llib-ltsnet
libld.so.3 libzfs.so.1 llib-ltsnet.ln
liblddbg.so.4 libzfs.so.2 llib-ltsol
libm.so llib-ladm llib-ltsol.ln
libm.so.1 llib-ladm.ln llib-lumem
libm.so.2 llib-laio llib-lumem.ln
libmacadm.so.1 llib-laio.ln llib-luuid
libmd5.so llib-lbsm llib-luuid.ln
libmd5.so.1 llib-lbsm.ln llib-lxnet
libmeta.so llib-lc llib-lxnet.ln
libmeta.so.1 llib-lc.ln llib-lzfs
libmp.so llib-lc_db llib-lzfs.ln
libmp.so.1 llib-lc_db.ln mpxio
libmp.so.2 llib-lcmd nss_compat.so.1
libMPAPI.so llib-lcmd.ln nss_dns.so.1
libMPAPI.so.1 llib-lcontract nss_files.so.1
libmpscsi_vhci.so llib-lcontract.ln nss_nis.so.1
libmpscsi_vhci.so.1 llib-lctf nss_nisplus.so.1
libmtsk.so llib-lctf.ln nss_user.so.1
libmtsk.so.1 llib-lcurses secure
libmtsk_db.so llib-lcurses.ln sparcv9
libmtsk_db.so.1 llib-ldevice svc
libmvec.so llib-ldevice.ln
-
die LD_LIBRARY_PATH ist leer, die habe ich schon versuchsweise mit /usr/local/lib und /usr/lib gesetzt
Der findet wie schon befürchtet die Lib nicht. Das wird es sein.
Wenn die libiconv-Bibliothek bei dir unter /usr/local/lib/ installiert ist und die Umgebungsvariable $LD_LIBRARY_PATH leer ist, kann er auch nicht auf die benötigten Funktionen dieser Library zugreifen, da er standard-mäßig nur /lib kennt.
Ich gehe mal davon aus, dass GCC 3.4.6 ebenfalls unter /usr/local/ installiert ist oder ist es /opt/sfw/?
Versuchst du "Hercules" unter einem X-Terminal zu kompilieren?
Mit welcher Shell (Befehlsinterpreter) arbeitest du (sh/bash, csh, ksh)?
Unter der sh/bash kannst du mit...
# export LD_LIBRARY_PATH=/usr/local/lib:/opt/sfw/lib
...die Variable setzen.
Unter der csh geht das mit...
% setenv LD_LIBRARY_PATH $LD_LIBRARY_PATH'':/usr/local/lib''
Danach mit (bash/sh)...
# echo $LD_LIBRARY_PATH
...oder (csh)
% setenv | more
... dir den Inhalt ausgeben lassen. Es sollte ein Wert für die Umgebungsvariable gesetzt sein.
/!\ Die Reihenfolge ist zu beachten, in der Pfade angegeben werden.
Viel Glück
escimo
-
Das mir dem export LD_LIBRARY_PATH hat jetzt funktioniert.
Ich hatte immer nur LD_LIBRARY_PATH=/..... eingegeben, ohne export.
Danke für den Tip.
Ich dachte das export braucht man nur, damit die Variable auch in anderen Shells
gilt?
Naja, auf jeden Fall läuft das configure jetzt, dafür habe ich jetzt jede Menge andere
Fehlermeldungen beim durchlaufen.
-
Ich dachte das export braucht man nur, damit die Variable auch in anderen Shells
gilt?
Stimmt! Dummerweise gilt das auch für Sub-Shells (und sämtliche anderen Unterprozesse).
Ohne Export ist die Variable wirklich nur in genau der einen Shell vorhanden in der Du sie setzt. Wenn Du jetzt ein Skript aufrufst, oder ein Kommando wie z.B. gcc ausführst, bekommt dessen Environment von der laufenden Shell nur diejenigen Variablen gesetzt die auch exportiert worden sind. Alles andere bleibt Privatvergnügen des Shell-Prozesses.
Gruß,
Andrew.