tcltk mit dem gcc

[wiel]

Also inzwischen sind die erweiterten Pfade wieder drin - nur um sie wieder zu deaktivieren.

-bash-2.05b$ echo $PATH
/usr/freeware/bin:/usr/local/bin:/usr/sbin:/usr/bsd:/sbin:/usr/bin:/usr/bin/X11:
-bash-2.05b$ export PATH=/usr/sbin:/usr/bsd:/sbin:/usr/bin:/usr/bin/X11
-bash-2.05b$ gcc -v
gcc ERROR:  gcc is not installed in /usr/lib32/cmplrs/gcc
-bash-2.05b$ /usr/freeware/bin/gcc -v
gcc ERROR:  gcc is not installed in /usr/freeware/bin/../../usr/lib32/cmplrs/gcc

-bash-2.05b$ cd inst/tcl8.4.3/unix/
-bash-2.05b$ rm config.cache
-bash-2.05b$ ./configure
creating cache ./config.cache
checking whether to use symlinks for manpages... no
checking compression for manpages... no
checking for gcc... gcc
checking whether the C compiler (gcc  ) works... no
configure: error: installation or configuration problem: C compiler cannot create executables.

[wiel]

wenn im ersten Posting das /usr/freeware/bin mehrmals aufgetaucht ist, habe ich das wohl falsch rueberkopiert

[Jasper]

Sieht ganz so aus, als würde bei dir noch woanders im Pfad eine Version des gcc rumgeistern, statt gcc ERROR:  gcc is not installed in /usr/lib32/cmplrs/gcc müsste jetzt nämlich eigentlich gcc: not found kommen. Schau mal alle Verzeichnisse in verkürzten PATH durch

[wiel]

Du hattest Recht , in usr/bin war noch ein gcc versteckt. Habe ich geloescht.

Ohne erweiterten Pfad lauft configure jetzt durch allerdings mit dem cc, das make bricht dann mangels Lizenz ab.

Mit Pfaderweiterung habe ich das alte Problem

-bash-2.05b$ echo $PATH
/usr/freeware/bin:/usr/local/bin:/usr/sbin:/usr/bsd:/sbin:/usr/bin:/usr/bin/X11:
-bash-2.05b$ cd inst/tcl8.4.3/unix/
-bash-2.05b$ ./configure
creating cache ./config.cache
checking whether to use symlinks for manpages... no
checking compression for manpages... no
checking for gcc... gcc
checking whether the C compiler (gcc  ) works... no
configure: error: installation or configuration problem: C compiler cannot create executables.

-bash-2.05b$ gcc -v
gcc ERROR:  gcc is not installed in /usr/lib32/cmplrs/gcc
-bash-2.05b$ su
Password:
# cp /usr/freeware/bin/gcc /usr/lib32/cmplrs/gcc
# exit
exit
-bash-2.05b$ gcc -v
Fatal error: Arg list too long
-bash-2.05b$

./configure
mit gleicher Fehlermeldung wie oben, aber trotzdem Danke Danke fuer Deine Muehe

[Jasper]

Naja, ist doch auch schon mal was, ausser in /usr/freeware gibt's jetzt wenigstens keinen gcc mehr. Ich blicke allerdings auch nicht, weshalb Komponenten vom gcc in /usr/lib32 gesucht werden. Jedenfalls, wenn Du den gcc dann noch dahin kopierst, scheint er sich immer wieder selbst aufzurufen, was dann irgendwann zu "arg list too long" fuehrt, das geht also sicher nicht :-( Sieht fuer mich irgendwie so aus, als ob das eine krude Mischung aus MipsPro und gcc waere. Ist vielleicht noch irgendwo cc auf gcc verlinkt (letzte Hoffnung...)?

Uebrigens, selbst wenn ich /usr/freeware/lib/gcc-lib  komplett wegmove und deine Umgebung soweit reproduziere, erhalte ich Deinen Fehler nicht. Ich weiss halt nicht, ob es viel hilft, in die Umgebung das gcc-Paket neu reinzuinstallieren, oder ob's noch schlimmer davon wird :-(

[wiel]

-bash-2.05b$ cd /bin
-bash-2.05b$ ls -l | grep cc
-rwxr-xr-x    1 root     sys         81476 Apr  14 16:52 acctcvt
-rwxr-xr-x    3 root     sys         98676 Mai  15 14:00 cc
lrwxr-xr-x    1 root     sys            17 Apr  14 16:24 cc.orginal -> ../lib/driverwrap
-rwxr-xr-x    3 root     sys         98676 Mai  15 14:00 gcc.bak
-rwxr-xr-x    1 root     sys         82528 Apr  14 16:51 yacc
-bash-2.05b$ ls -l | grep gcc
-rwxr-xr-x    3 root     sys         98676 Mai  15 14:00 gcc.bak
bash-2.05b$ ls -l /usr/bin/ | grep cc
-rwxr-xr-x    1 root     sys         81476 Apr  14 16:52 acctcvt
-rwxr-xr-x    3 root     sys         98676 Mai  15 14:00 cc
lrwxr-xr-x    1 root     sys            17 Apr  14 16:24 cc.orginal -> ../lib/driverwrap
-rwxr-xr-x    3 root     sys         98676 Mai  15 14:00 gcc.bak
-rwxr-xr-x    1 root     sys         82528 Apr  14 16:51 yacc
-bash-2.05b$ ls -l /usr/freeware/bin/ | grep cc
lrwxr-xr-x    1 root     sys            14 Apr  23 07:25 disable -> ../sbin/accept
lrwxr-xr-x    1 root     sys             3 Apr  22 13:29 egcs -> gcc
-rwxr-xr-x    1 root     sys         22304 Apr  23 07:57 ellcc
lrwxr-xr-x    1 root     sys            14 Apr  23 07:25 enable -> ../sbin/accept
-rwxr-xr-x    3 root     sys         98676 Mai  15 14:00 gcc
-rwxr-xr-x    1 root     sys         15613 Apr  22 13:29 gccbug
lrwxr-xr-x    1 root     sys             3 Apr  22 13:29 mips-sgi-irix6.5-gcc -> gcc
lrwxr-xr-x    1 root     sys             8 Mai  16 08:46 objc -> .objc.cc
-rwxr-xr-x    1 root     sys         14220 Juni 23 12:08 rleccube


Das scheint ja soweit sauber zu sein.  Meiner Meinung nach kommen andere Verzeichnisse nicht mehr in Frage.

Ich probiere es dann mal mit einem Neueinspielen der Pakete

[Jasper]

Also was ich ja komisch finde: in /usr/bin hat der cc genau dieselbe Groesse und das Datum wie der gcc, und der cc.orig zeigt auf ../driverwrap, wie sich's eigentlich fuer den MipsPro gehoeren wuerde. Ebenso in /bin. Sieht fuer mich so aus, als haette man versucht, auf die Weise den  MipsPro durch den gcc zu ersetzen. Vermutlich schlaegt dann jetzt naemlich auch irgendwie der Lizenzmanager zu??? Deshalb die komische Fehlermeldung -  das ist jetzt Spekulation, aber das mit dem cc in /usr/bin gehoert bestimmt nicht so (wirst Du dann auch mit Neuinstallation nicht los) Du koenntest die fraglichen Dateien jetzt auch wegmoven, aber moeglicherweise sind noch mehr solche Sachen vorhanden...

[wiel]

Um das Thema abzuschlieszen, ich habe den gcc mit dem Softwaremanager entfernt, dann per Hand allles was die gleiche Groesze wie der gcc hatte  und irgendwie cc im Namen trug auf dem Rechner geloescht und nach einem Reboot letztendlich neu installiert.

Und Wunderwelt der Technik - es funktioniert. Danke nochmal!!!