GCC 2.95.3 für Solaris 2.5.1

[escimo]

Hallo zusammen,

ich habe auf meiner SPARCstation 20 (1x SM71) Solaris 2.5.1 frisch installiert. Nun möchte ich die GCC 2.95.3 (nur diese Version) für ein Paar Programmierübungen einsetzen.

Die GCC 2.95.3 werde ich mir im Laufe der nächsten Tage von sunfreeware.com auf den Rechner holen. Vorallem mit einem Assembler möchte ich ein wenig rumspielen.

Meine Fragen:
Kann ich den bei Solaris enthaltenen Assembler zusammen mit der GCC (benötige nur C/C++ Compiler) zusammen einsetzen?
Welche Pakete (Minimal-Variante bitte) werden zusätzlich zur GCC 2.95.3 noch benötigt beziehungsweise muss ich mir außerdem noch beschaffen?

Ich würde mich auf ein Paar Postings von Euch sehr freuen.

Viele Grüße
escimo

[escimo]

Hallo wieder,

bis auf den Fakt, dass meine SS20 jetzt (2x SM51) hat, ist noch nix passiert.

Keine Ideen? Nein? Na dann schreibe ich mir eben selbst was...

Hallo escimo.

Kann ich den bei Solaris enthaltenen Assembler zusammen mit der GCC (benötige nur C/C++ Compiler) zusammen einsetzen?

Ungewiss.

Welche Pakete (Minimal-Variante bitte) werden zusätzlich zur GCC 2.95.3 noch benötigt beziehungsweise muss ich mir außerdem noch beschaffen?

Wie wäre es mit folgenden zusätzlichen Paketen:

• binutils
• bzip2
• cvs
• gdb
• gmake
• gzip
• less
• libgcc-3.3.2
• ncurses
• nedit
• patch
• readline
• sqlite
• gtar
• zlib

Grüße

Immer diese Selbstgespräche...tzzz...

Gruß
escimo

[Jonny]

Wenn man nix wissen tut, dann tut man auch nicht rum texten.

Ich hätte dir gerne was geantwortet, aber wegen des vorigen Satzes lasse ich es lieber
Dein Selbstgespräch war doch ganz aufschlussreich.
Das hättest du auch gleich alles installieren können

Gruß
Jonny

[escimo]

Das hättest du auch gleich alles installieren können

Wenn ich mal Zeit habe das mit ein Paar Patches auf ein Rohling zu knallen, werde ich das auch sofort nachholen, Jonny.

Die SS20 hat weder einen Browser, noch ist diese am internen Netzwerk angeschlossen. Erst wenn die Ultra 80 mit QFE-Adapter einsatzbereit ist, kann das System wirklich dauerhaft im Daten-Netzwerk betrieben werden ohne jedesmal das entsprechende Datenkabel umstecken zu müssen.

Grüße
escimo

[escimo]

Kleines Update, neues Problem...

Am Wochenende habe ich mir endlich mal die benötigten Paket von sunfreeware.com besorgt. Zunächst war alles auf dem Notebook (Win2k Pro). Dann habe ich die ganzen gepackten Dateien (auch noch ein Paar Patches) mit PowerArchiver in einer fette TAR "zusammengeschnürrt" und per FTP auf die SS20 "geschoben".

Das die betagte UNIX-Variante von tar mit langen Dateinamen nicht zurecht kommt, war mir bedauerlicherweise kurzzeitig entschwunden. Also habe ich versucht das tar-Paket von sunfreeware.com zunächste mittels ...
# pkgadd -d ./tar-1.16-sol25-sparc-local
... zu installieren.

Nix da! Jetzt hat er was an dem Header des Paketes "auszusetzen". Habt ihr einen Tipp, was ich falsch mache?

Selbst wenn ich alle Dateien einzeln per FTP auf die SS20 transferiere, weis ich nicht, ob die Pakete sich installieren lassen. Ich werde heute noch Probe-Installationen von einigen der besorgten Pakete durchführen.

"Die genaue Fehlermeldung zur Installation von tar mit pkgadd folgt heute noch (ca. 21 Uhr)."

...und hier ist 'se (Problem ist bereits behoben)

Code: [Auswählen]

# pkgadd -d ./tar-1.16-sol25-sparc-local

The following packages are available:
  1  SMCtar     tar
                (sparc) 1.16

Select package(s) you wish to process (or 'all' to process
all packages). (default: all) [?,??,q]: 1

Processing package instance <SMCtar> from </home/schaarst/tar-1.16-sol25-sparc-local>

tar
(sparc) 1.16

This appears to be an attempt to install the same architecture and
version of a package which is already installed.  This installation
will attempt to overwrite this package.

cpio: Bad magic number/header.
1 errors
pkgadd: ERROR: attempt to process datastream failed
    - process </usr/bin/cpio -icdumD -C 512> failed, exit code 1
pkgadd: ERROR: unable to unpack datastream

Installation of <SMCtar> failed (internal error).
No changes were made to the system.
#
Gruß
escimo

[claus]

Das ftp von windows nach Solaris hat mir schon so manches Paket ruiniert. Wenn sonst keiner einen Hinweis hat, versuchs mal mit winscp (und eben scp).

Claus

[Jonny]

Winscp ist gut, aber grotten langsam.
Hast du FTP auf den Binary Mode geschaltet? (winscp macht das auch manchmal falsch)

Gruß
Jonny

[escimo]

Hi zusammen,

also das lag wirklich an dem FTP-Tool von Win2k. Allerdings...

@Jonny: Ja, der "binary mode" hätte auch funktioniert. Ich habe es nochmal getestet. Den Modus sollte ich mir mal bei Binärdateien angewöhnen

Habe das aber vorher mit dem FileZilla, dessen Installer noch auf meiner Festplatte zu finden war, nochmals transferiert. Da hat es auch geklappt und ich konnte inzwischen schon gtar, zlib, patch, gzip installieren.

Danke für die Hilfestellung zu diesem Problem.

Gruß
escimo

[escimo]

Das Teilproblem mit dem Volume Manager habe ich nach <<hier>> in eine neues Thema ausgelagert.

Ich installiere derweilen Patches und danach noch weitere Freeware-Pakete ...

Gruß
escimo

[claus]

Winscp ist gut, aber grotten langsam.
Hast du FTP auf den Binary Mode geschaltet? (winscp macht das auch manchmal falsch)

Gruß
Jonny

Danke für den Tip. ICh hatte halt einmal Probleme mit standard-Windows ftp, danach hab ich einfach immer winscp genommen, die Zeit wars mir wert, dafür hat es immer funktioniert. Werde mir das jetzt per Email schicken, damit es in meinem "MERKE" Ordner landet.

Claus

[escimo]

Da die eingebildete "Volume-Manager"-Problematik zu keinem Zeitpunkt wirklich existent gewesen zu sein scheint, kann ich mit der ursprünglichen Software-Konfiguration fortfahren.

Zum weiteren Verlauf: Jetzt kommen erst mal die Patches dran! Das kann dauern 

Gruß
escimo

[escimo]

So. Nachdem der Patch-Cluster nach einigen Stunden mal fertig war - ab ca. 0100 bis ca. 0500, wo ich dann von dem Summen der 2.1 GB Seagate-Festplatte wieder aufgewacht bin - kann ich morgen daran gehen einige zusätzliche SFW-Pakete zu installieren.

Dabei werde ich den GCC 2.7.2 installieren, um mir den Rest inklusive GCC 2.95.3 aus den Sources "eigenhändig" zu übersetzen und unter /opt/sfw installieren zu lassen.

Sollte alles glatt gehen, kann ich mich endlich daran versuchen, "Assembler-Schnick-Schnack" mit der Tastatur "einzuhacken".

Weitere Zwischenstände mit Ergebnissen folgen.

Gute Nacht zusammen.
escimo

[escimo]

Es ist verwurstelt:

Warum werden die Umgebungsvariablen speziell die Pfad-Einträge unter /etc/profile für den Benutzer root nur im Konsolen-Login gültig, nicht aber im CDE?

Als Hinweis: Benutzer root nutzt die Bourne shell (sh) und es existiert keine lokale .profile-Datei. D.h., ich will das System zwingen die /etc/profile zu nutzen.
In der Konsole/Terminal unter CDE möchte ich aber auch nicht jedesmal alles von Hand setzen beziehungsweise durch ein Script setzen lassen.

Will jetzt nicht mehr nachschaun...bin müde und gehe in die Heia.

Gute Nacht.

[escimo]

Zwei temporäre Lösungen habe ich jetzt parat für das PATH-Problem:
1. symbolischer Link für die Datei .profile auf /etc/profile
2. Einlesen der /etc/profile mit der Bourne Shell mit vorangestellten Punkt (.) :
    # . /etc/profile
Die C-Shell nutzt source anstelle des Punktes (.).
Leider weis ich immer noch nicht, wo und wann genau die /etc/profile bei CDE eingebunden wird. Auch die Anpassung der .dtprofile mit dem Setzen der Umgebungsvariablen DTSOURCEPROFILE=true bringt da nicht viel, da es bei meinem root keine lokale Datei .profile gibt. Allerdings kann ich durch setzen des symbolischen Links das ganze manuell umgehen. Ich untersuche das bei Gelegenheit weiter aber jetzt gibt es dringendere Anliegen.

Beim Kompilieren von GCC 2.95.3 mit GCC 2.95.3 (ja selbe Version ), ist der Build fehlgeschlagen, da es mit dem native make - wie in der Doku angegeben - leider zu Problemen gekommen ist. Werde also erst mal die GNU-Variante von make und einige andere GNU-Tools nachinstallieren. :-/

Gruß
escimo

[escimo]

Habe zwecks der Umgebungsvariablen PATH unter CDE nochmals geschaut:

Das Programm "Console" (?) nutzt die in der /etc/profile gesetzten Pfad-Angaben auch ohne lokal gesetzte .profile Datei.

Das Programm "Terminal" (dtterm) greift auf die /etc/profile nicht zurück. Warum nicht, und wie doch, dass muss ich erst noch rausfinden.