Archiv verlassen und diese Seite im Standarddesign anzeigen : mal wieder configure-error ... cannot create executables
hi.
folgende fehlermeldung beim ausführen von ./configure:
checking for a BSD compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for mawk... no
checking for gawk... gawk
checking whether make sets ${MAKE}... yes
checking for g++... g++
checking for C++ compiler default output... configure: error: C++ compiler cannot create executables
auch merkwürdig:
laut kpackage hab ich gcc 2.95, "gcc -v" gibt aber version 3.2 zurück.
thx schonmal für eure hilfe.
sf.
hab grad mawk installiert, jetzt sieht's halt so aus:
checking for a BSD compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for mawk... mawk
checking whether make sets ${MAKE}... yes
checking for g++... g++
checking for C++ compiler default output... configure: error: C++ compiler cannot create executables
:(
Hi,
wenn du die Suchfunktion genutzt hättest, hättest du auch dies gefunden:
http://www.linuxforen.de/forums/showthread.php?s=&threadid=59697
1. ich habe die such-funktion benutzt
2. ich habe diesen eintrag gefunden
3. ich habe die binutils installiert
leider hat's trotzdem nicht funktioniert, daher dieser thread.
danke trotzdem.
Hi,
dann überprüfe mal, ob das Paket "gpp" installiert ist (falls du noch SuSE 8.0 hast). Den Thread dazu suche ich jetzt nicht heraus ;)
installiert sind:
gpp
gppinfo
gppshare
libgpp
alle version 2.95.3-216
fehlt da was?
/e:
das ganze problem fing an, als ich versucht hab, glibc-2.3 zu kompilieren. nach einigem ärger hab ich jetzt wieder glibc-2.2.5.
ich hab auch schon g++ und gcc (und alles, was damit zu tun hatte) komplett entfernt und neu installiert (über rpm). alles ohne erfolg.
/e2:
auch das glibc-devel-paket ist installiert.
Du solltest config.log auf eine konkrete Fehlermeldung hin überprüfen um herauszufinden, was genau schiefgeht.
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.
It was created by configure, which was
generated by GNU Autoconf 2.52. Invocation command line was
$ ./configure
## ---------- ##
## Platform. ##
## ---------- ##
hostname = XXX
uname -m = i686
uname -r = 2.4.18-4GB
uname -s = Linux
uname -v = #1 Wed Mar 27 13:57:05 UTC 2002
/usr/bin/uname -p = unknown
/bin/uname -X = unknown
/bin/arch = i686
/usr/bin/arch -k = unknown
/usr/convex/getsysinfo = unknown
hostinfo = unknown
/bin/machine = unknown
/usr/bin/oslevel = unknown
/bin/universe = unknown
PATH = /sbin:/usr/sbin:/usr/local/sbin:/root/bin:/usr/local/bin:/usr/bin:/usr/X11R6/bin:/bin:/usr/games:/opt/gnome/bin:/opt/kde3/bin:/opt/kde2/bin:/opt/cross/bin:/usr/lib/java/bin:/opt/gnome/bin
## ------------ ##
## Core tests. ##
## ------------ ##
configure:953: PATH=".;."; conftest.sh
./configure: conftest.sh: command not found
configure:956: $? = 127
configure:1002: checking for a BSD compatible install
configure:1051: result: /usr/bin/install -c
configure:1062: checking whether build environment is sane
configure:1105: result: yes
configure:1138: checking for mawk
configure:1153: found /usr/bin/mawk
configure:1161: result: mawk
configure:1171: checking whether make sets ${MAKE}
configure:1191: result: yes
configure:1335: checking for g++
configure:1350: found /usr/local/bin/g++
configure:1358: result: g++
configure:1373: checking for C++ compiler version
configure:1376: g++ --version </dev/null >&5
g++ (GCC) 3.2
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
configure:1379: $? = 0
configure:1381: g++ -v </dev/null >&5
Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.2/specs
Configured with: ./configure
Thread model: posix
gcc version 3.2
configure:1384: $? = 0
configure:1386: g++ -V </dev/null >&5
g++: argument to `-V' missing
configure:1389: $? = 1
configure:1409: checking for C++ compiler default output
configure:1412: g++ conftest.cc >&5
/usr/local/lib/libc.so.6(.data+0xa2c): multiple definition of `__ctype_toupper@GLIBC_2.0'
/usr/local/lib/libc.so.6(*IND*+0x0): multiple definition of `__ctype32_toupper@GLIBC_2.2'
/usr/local/lib/libc.so.6(.data+0xa34): first defined here
/usr/local/lib/libc.so.6(.data+0xa30): multiple definition of `__ctype32_tolower@GLIBC_2.2'
/usr/local/lib/libc.so.6(.data+0xa20): multiple definition of `__ctype_b@GLIBC_2.0'
/usr/local/lib/libc.so.6(*IND*+0x0): multiple definition of `__ctype_tolower@GLIBC_2.0'
/usr/local/lib/libc.so.6(.data+0xa28): first defined here
/usr/local/lib/libc.so.6(.data+0xa24): multiple definition of `__ctype32_b@GLIBC_2.0'
collect2: ld returned 1 exit status
configure:1415: $? = 1
configure: failed program was:
#line 1393 "configure"
#include "confdefs.h"
int
main ()
{
;
return 0;
}
configure:1438: error: C++ compiler cannot create executables
## ----------------- ##
## Cache variables. ##
## ----------------- ##
ac_cv_env_CC_set=
ac_cv_env_CC_value=
ac_cv_env_CFLAGS_set=
ac_cv_env_CFLAGS_value=
ac_cv_env_CPPFLAGS_set=
ac_cv_env_CPPFLAGS_value=
ac_cv_env_CXXCPP_set=
ac_cv_env_CXXCPP_value=
ac_cv_env_CXXFLAGS_set=
ac_cv_env_CXXFLAGS_value=
ac_cv_env_CXX_set=
ac_cv_env_CXX_value=
ac_cv_env_LDFLAGS_set=
ac_cv_env_LDFLAGS_value=
ac_cv_env_build_alias_set=
ac_cv_env_build_alias_value=
ac_cv_env_host_alias_set=
ac_cv_env_host_alias_value=
ac_cv_env_target_alias_set=
ac_cv_env_target_alias_value=
ac_cv_path_install=$'/usr/bin/install -c'
ac_cv_prog_AWK=mawk
ac_cv_prog_ac_ct_CXX=g++
ac_cv_prog_make_make_set=yes
## ------------ ##
## confdefs.h. ##
## ------------ ##
#define PACKAGE "3ddesktop"
#define VERSION "0.2.3"
configure: exit 77
so schaut's aus.
ich hab die stelle, die ich für den fehler halte, hervorgehoben.
ist das also ein glibc-problem?
ich hab die stelle, die ich für den fehler halte, hervorgehoben.
ist das also ein glibc-problem?
Sieht ganz danach aus. Ich nehme an, daß Du glibc selber kompiliert hast?
es war so; ich hatte glibc-2.3 kompiliert und trotz meiner meinung nach kleinerer fehlermeldungen ein "make install" gewagt...
resultat: crash.
also hab ich deinstalliert und glibc2.2.5 aus rpm eingespielt (ein kampf) - 2.3 scheint aber nicht restlos beseitigt zu sein.
ich kann mich leider nicht mehr so genau erinnern, wie und in welcher reihenfolge ich das gemacht habe.
die frage ist bloß, wie ich das wieder sauber krieg.
ich hab schon versucht, glibc-2.3 aus src.rpm zu kompilieren - mit denkbar wenig erfolg.
grad funktioniert das system zwar, ohne funktionierenden compiler ist das aber kein dauerzustand ... ich steh kurz vor 'ner neuinstallation.
oder hat jemand 'ne bessere idee?
*verzweifelabernichtaufgeb*
sf.
Im Fehlerfall wurde eine libc in /usr/local/lib aufgegriffen, üblicherweise wird diese aber in /lib installiert; ist möglicherweise die ursprüngliche libc noch vorhanden?
hmmm ... auf meiner distri-cd hab ich noch glibc-2.2.5-26 als rpm, das dürfte die ursprüngliche sein...
also, per yast die aktuelle deinstallieren und die ursprüngliche einspielen? oder geht das auch eleganter?
hab sowieso schon mit dem gedanken eines "downgrades" gespielt, weil ich glibc auch für die ursache weiterer, kleinerer probleme halte.
auf jedenfall schon mal danke für deine hilfe, zander.
ich muß da jetz erstmal 'ne nacht drüber schlafen :).
gn8.
sf.
hmmm ... auf meiner distri-cd hab ich noch glibc-2.2.5-26 als rpm, das dürfte die ursprüngliche sein...
also, per yast die aktuelle deinstallieren und die ursprüngliche einspielen? oder geht das auch eleganter?
hab sowieso schon mit dem gedanken eines "downgrades" gespielt, weil ich glibc auch für die ursache weiterer, kleinerer probleme halte.
Die glibc in /usr/local/lib stammt nicht von SuSE, oder doch? Normalerweise läßt sich glibc nicht einfach deinstallieren, immerhin ist es eine zentrale Komponente des Systems, ohne die nichts (oder zumindest nicht mehr sehr viel) funktioniert.
da bin ich mir grad nicht sicher. sie stammt wahrscheinlich von rpmfind oder rpmseek, also könnte durchaus sein.
über yast(2) dürfte sich glibc durchaus entfernen lassen, reboot dürfte nach dem entfernen ja nicht notwendig sein, sonst wird's problematisch.
yast teilt mir grade mit, daß rpm nach dem deinstallieren von glibc nicht mehr funktionieren wird - soviel zu dem thema ...
muß wohl auf die rpm-version von glibc-2.3 warten, um den fehler zu beheben.
/e:
versuche grade, die glibc-version in /usr/local/src upzudaten, damit wenigstens _eine_ komplett funktionierende glibc auf dem sys installiert ist; brauch ich dazu die option --root <dir> oder --buildroot <dir>?
thx soweit @ alle
da bin ich mir grad nicht sicher. sie stammt wahrscheinlich von rpmfind oder rpmseek, also könnte durchaus sein.
über yast(2) dürfte sich glibc durchaus entfernen lassen, reboot dürfte nach dem entfernen ja nicht notwendig sein, sonst wird's problematisch.
Falls Du die glibc zunächst ersatzlos entfernst hast Du auch ohne Neustart ein Problem, da sämtliche bis auf sehr wenige Anwendungen gegen libc gelinkt sind. Ich kann mir nicht vorstellen, daß yast(2) das zuläßt...
wie gesagt, würde rpm danach nicht mehr funktionieren, das ja auch von yast benutzt wird, um pakete zu installieren.
ich hab zunächst mal das glibc-devel-paket entfernt, um die ältere version von glibc mit "rpm -U --oldpackage" zu installieren.
hat soweit auch alles funktioniert, aber das endergebnis ist das gleiche - selber configure-error "multiple definition of ..."
jetzt bin ich langsam mit meinem latein am ende.
eine neuere version von glibc müßte das problem doch beseitigen, oder? hoffe, glibc-2.3 kommt bald als rpm für suse ...
Solange eine glibc in /usr/local/lib installiert ist und durch entsprechende ld Konfiguration vor derjenigen in /lib geladen wird bleibt das Problem natürlich bestehen. Deshalb hatte ich gefragt, woher diese Version stammt und ob die ursprüngliche noch existiert; nur dann lässt sich die zusätzlich installierte glibc Installation in /usr/local gefahrlos entfernen.
du meinst, ich könnte das beheben, indem ich die links in /lib korrigiere? hmmm... sind das nicht ein bißchen viele? oder versteh ich da grade was falsch.
nur zum verständnis: die glibc in /usr/local ist sowas wie eine sicherheitskopie bzw. redundanz, oder? wenn ich jetz rpm -e ausführe wird aber die in /lib entfernt, richtig? wie werd ich also die in /usr/local/lib los?
du meinst, ich könnte das beheben, indem ich die links in /lib korrigiere? hmmm... sind das nicht ein bißchen viele? oder versteh ich da grade was falsch.
Nein, ich hatte vorgeschlagen, wieder die glibc Deiner Distribution zu benutzen.
nur zum verständnis: die glibc in /usr/local ist sowas wie eine sicherheitskopie bzw. redundanz, oder? wenn ich jetz rpm -e ausführe wird aber die in /lib entfernt, richtig? wie werd ich also die in /usr/local/lib los?
Das war genau meine Frage, ich habe keine Ahnung wo die glibc in /usr/local/lib herkommt, ich kann nur vermuten, daß Du sie von Quellen kompiliert und dort installiert hast ;) Insofern die "normale" libc in /lib noch existiert kannst Du die glibc Installation in /usr/local/lib getrost löschen.
ach so ... deswegen ... alles klar.
das werd ich probieren, danke!
hat geklappt!!!
zuerst hat configure ja noch gemeckert, daß es /usr/lib/libc.so.6 nicht findet, aber nachdem ich zwei symbolische links (ld-linux.so und libc.so.6) auf die libc.so.6 hab zeigen lassen, kan der compiler wieder executables erzeugen - zumindest bei meiner test-source.
ich hoffe, daß das auch so bleibt.
danke, daß du mir geholfen hast, zander! warst ja echt hartnäckig :).
ein schönes wochenende noch.
/e:
mal 'ne frage am rande: aus/in welchem verzeichnis kompiliert man denn bitte bibliotheken? ich hab das bis jetz in /usr/local/src gemacht, aber dann wird ja in /usr/local/lib installiert; das find ich etwas umständlich wegen der verlinkung quer durch's system, oder ist das so beabsichtigt?
danke nochmal :D.
danke, daß du mir geholfen hast, zander! warst ja echt hartnäckig :).
ein schönes wochenende noch.
Bitteschön, und wünsche ich Dir auch.
mal 'ne frage am rande: aus/in welchem verzeichnis kompiliert man denn bitte bibliotheken? ich hab das bis jetz in /usr/local/src gemacht, aber dann wird ja in /usr/local/lib installiert; das find ich etwas umständlich wegen der verlinkung quer durch's system, oder ist das so beabsichtigt?
In welchem Verzeichnis Du sie übersetzt ist letztenendes nicht wichtig, entscheidend ist, wohin sie installiert werden. glibc nutzt die GNU autotools, die standardmässig /usr/local als relativen Zielpfad benutzen. Normalerweise läßt sich das mit --prefix=/wo/auch/immer ändern. Ich empfehle Dir allerdings, zentrale Komponenten wie glibc nur dann manuell auszutauschen, wenn das aus irgendeinem Grund notwendig oder besonders sinnvoll ist; ansonsten riskierst Du Probleme wie das gerade überstandene und verlierst bei der Problembehebung möglicherweise unnötig viel Zeit ;)
PS: wie sieht Deine Konfiguration jetzt aus? Du solltest etwas in dieser Richtung haben:
-rwxr-xr-x 1 root root 1145456 Sep 18 04:50 /lib/libc-2.2.5.so
lrwxr-xr-x 1 root root 13 Jan 4 14:26 /lib/libc.so.6 -> libc-2.2.5.so
-rwxr-xr-x 1 root root 82503 Sep 18 04:50 /lib/ld-2.2.5.so
lrwxr-xr-x 1 root root 11 Jan 4 14:26 /lib/ld-linux.so.2 -> ld-2.2.5.so
jupp, genauso ... und eben die extra-links in /usr/local/lib, die auf /lib/libc-2.2.5 verweisen - haupsache es läuft wieder.
danke nochmal.
vBulletin® v3.8.6, Copyright ©2000-2012, Jelsoft Enterprises Ltd.