Portierung SunOS nach Linux
Christian Felsch
Hallo,
in der Firma, in der ich arbeite, wird eine bestimmte Anwendung eingesetzt,
die auf uralten Suns (SunOS 1.?) läuft. Diese Anwendung basiert auf der
Crossplattform-Bibliothek XVT, die wiederum auf Motif aufsetzt.
Die Suns sind sehr lahm und können die produzierten Datenmenge nicht mehr
vernünftig verwalten, da die SunOS-Version max. 1GB große Partitionen kann.
Wir diskutieren deshalb gerade die Möglichkeit, ob man die Suns durch
LinuxPC ersetzen kann.
Von der Anwendung stehen die Quelltexte zur Verfügung stehen, man könnte
also versuchen, sie unter Linux zu übersetzen - wenn da nicht diese
Bibliothek XVT wäre! Wie es aussieht, gibt es die nicht für Linux :-((
Mich würde jetzt interessieren, ob es irgendwie möglich ist, eine statische
Lib vom SunOS unter Linux zu verwenden.
Was gibt es sonst für Möglichkeiten, die Anwendung auf die Linux-Platform
zu bringen? Sie hat eine nicht allzu komplexe GUI und steuert über Standard
UNIX Netwerkfunktionen eine Echtzeit-Testumgebung für ein Embedded System.
Die Anwendung für für uns angefertigt und die herstellende Firma hat
scheinbar kein Interesse an einer Portierung auf Linux - das leiten wir aus
dem absolut überhöhten Angebots-Preis für einen Linux-Port ab.
Vielleicht hat hier ja jemand einen Rat.
Christian
Gerhard Häring
>
> Hallo,
>
> in der Firma, in der ich arbeite, wird eine bestimmte Anwendung
> eingesetzt, die auf uralten Suns (SunOS 1.?) läuft. Diese Anwendung
> basiert auf der Crossplattform-Bibliothek XVT, die wiederum auf
> Motif aufsetzt. Die Suns sind sehr lahm und können die produzierten
> Datenmenge nicht mehr vernünftig verwalten, da die SunOS-Version
> max. 1GB große Partitionen kann. Wir diskutieren deshalb gerade die
> Möglichkeit, ob man die Suns durch LinuxPC ersetzen kann.
> Von der Anwendung stehen die Quelltexte zur Verfügung stehen, man
> könnte also versuchen, sie unter Linux zu übersetzen - wenn da nicht
> diese Bibliothek XVT wäre! Wie es aussieht, gibt es die nicht für
> Linux :-(( Mich würde jetzt interessieren, ob es irgendwie möglich
> ist, eine statische Lib vom SunOS unter Linux zu verwenden.
Unter Linux x86 mit Sicherheit nicht.
> Was gibt es sonst für Möglichkeiten, die Anwendung auf die Linux-Platform
> zu bringen? Sie hat eine nicht allzu komplexe GUI und steuert über Standard
> UNIX Netwerkfunktionen eine Echtzeit-Testumgebung für ein Embedded System.
> Die Anwendung für für uns angefertigt und die herstellende Firma hat
> scheinbar kein Interesse an einer Portierung auf Linux - das leiten wir aus
> dem absolut überhöhten Angebots-Preis für einen Linux-Port ab.
Ich denke, den Nicht-GUI Code wird man relativ leicht portieren
können. Den GUI-Code dann evtl. neu schreiben und eine Bibliothek
nehmen, wo man möglichst wenig tun muss, z. B. wxWindows, Qt oder GTK.
Btw. dieses XVt-Dingens scheint's laut Hersteller-Homepage für einige
Plattformen zu geben, sogar win32?!, aber nicht für Linux. Vielleicht
kommt für euch ja auch ein neuere SPARC-Kiste oder win32 in Frage.
Gerhard
--
Linux lilith.hqd-internal 2.4.18-pre7 #1 SMP Tue Feb 5 21:29:20 CET 2002 i686
gargamel.hqd-internal FreeBSD 4.5-STABLE #0: Fri Feb 15 02:34:17 CET 2002
Außentemperatur in München: 6.9 °C Wind: 1.3 m/s
Ernst Pfannenschmidt
news:ango4a...@PeZeh.home.de...
Vielleicht gibt es XVT ja für Solaris x86, dann könnte Ihr PC Hardware
benutzen.
Wenn Ihr Ärger mit der Portierung vermeiden wollt, dann kauft euch doch
einfach eine neue SUN (oder vielleicht einen Clone), das dürfte ohnehin
billiger sein, als die Portierung der Software.
Ernst
Markus Strangl
> in der Firma, in der ich arbeite, wird eine bestimmte Anwendung
> eingesetzt, die auf uralten Suns (SunOS 1.?) läuft. Diese Anwendung
> basiert auf der Crossplattform-Bibliothek XVT, die wiederum auf Motif
> aufsetzt. Die Suns sind sehr lahm und können die produzierten
> Datenmenge nicht mehr vernünftig verwalten, da die SunOS-Version max.
> 1GB große Partitionen kann. Wir diskutieren deshalb gerade die
> Möglichkeit, ob man die Suns durch LinuxPC ersetzen kann.
hmm... SunOS 1.x laesst mich auf _sehr_ alte Hardware tippen... sun3 oder 4
waere da nicht eine etwas aktuellere Sun (Sparcstation 5,10,20, Ultra)
eine erwaegenswerte Alternative? Bis zum aktuellen Solaris (8) sind
noch SunOS4 compatibility libraries dabei, d.h. die alte Software sollte
ohne Veraenderung auf einer neueren Plattform laufen oder zumindest
compilierbar sein.
Neuere Suns haben auch mit dem 1GB-Partitionen kein Problem mehr.
Ist wohl der aufwandsaermste Weg.. und SS5 etc sind gebraucht recht
guenstig zu bekommen (ebay et al.)
HTH
Markus
--
Wenn ist das Nunstuck git und Slotermeyer?
Ja! Beierhund das Oder die Flipperwaldt gersput!
Tibor Pausz
> Die Anwendung für für uns angefertigt und die herstellende Firma hat
> scheinbar kein Interesse an einer Portierung auf Linux - das leiten wir aus
> dem absolut überhöhten Angebots-Preis für einen Linux-Port ab.
Wenn es die CrossPlattform Library nicht für Linux gibt muß aufwendig
portiert werden -> es wird teuer.
Am sinnvollsten ist es eine neue SUN Blade 100 anzuschaffen, auch nicht
teuerer als PC Hardware und deutlich schneller als die alte SUN, die ihr
habt. Seht zu, daß Eure Software darauf läuft, fragt den Hersteller an
wie es mit einerVersion für Solaris 8 aussieht und dann ist das Thema
vom Tisch.
Jede Portierung wird teuerer.
Felix von Leitner
> Wenn es die CrossPlattform Library nicht für Linux gibt muß aufwendig
> portiert werden -> es wird teuer.
> Am sinnvollsten ist es eine neue SUN Blade 100 anzuschaffen, auch nicht
> teuerer als PC Hardware und deutlich schneller als die alte SUN, die ihr
> habt. Seht zu, daß Eure Software darauf läuft, fragt den Hersteller an
> wie es mit einerVersion für Solaris 8 aussieht und dann ist das Thema
> vom Tisch.
Klar doch, empfehlt ihm, daß er seine m68k-Binaries auf einem Solaris 8
laufen läßt. Das wird ihm sicher enorm weiterhelfen. Weil es das so
toll für m68k gibt!
Hier posten wirklich nur noch Deppen :-(
Gerhard Häring
> Thus spake Tibor Pausz (pa...@stud.uni-frankfurt.de):
>> Wenn es die CrossPlattform Library nicht für Linux gibt muß aufwendig
>> portiert werden -> es wird teuer.
>
>> Am sinnvollsten ist es eine neue SUN Blade 100 anzuschaffen, auch nicht
>> teuerer als PC Hardware und deutlich schneller als die alte SUN, die ihr
>> habt. Seht zu, daß Eure Software darauf läuft, fragt den Hersteller an
>> wie es mit einerVersion für Solaris 8 aussieht und dann ist das Thema
>> vom Tisch.
>
> Klar doch, empfehlt ihm, daß er seine m68k-Binaries
""" Von der Anwendung stehen die Quelltexte zur Verfügung """
> auf einem Solaris 8 laufen läßt. Das wird ihm sicher enorm
> weiterhelfen. Weil es das so toll für m68k gibt!
>
> Hier posten wirklich nur noch Deppen :-(
Du sagst es.
Gerhard
--
Linux lilith.hqd-internal 2.4.18-pre7 #1 SMP Tue Feb 5 21:29:20 CET 2002 i686
gargamel.hqd-internal FreeBSD 4.5-STABLE #0: Fri Feb 15 02:34:17 CET 2002
Außentemperatur in München: 4.6 °C Wind: 9.9 m/s
Felix von Leitner
> > Klar doch, empfehlt ihm, daß er seine m68k-Binaries
> ^^^^^^^^
> """ Von der Anwendung stehen die Quelltexte zur Verfügung """
Ja und? Willst du ihm raten, daß er, um SunOS 4 Rückwärts-Binaries zu
erzeugen, die dann mit den Rückwärts-Libraries laufen, eine
Uralt-Version des SunOS 4 Compilers vom Schwarzmarkt besorgt und dann
neu kompiliert?
Offenbar kennst du SunOS noch schlechter als bisher erkennbar. :(
Felix
Gerhard Häring
>> > Klar doch, empfehlt ihm, daß er seine m68k-Binaries
>> ^^^^^^^^
>
>> """ Von der Anwendung stehen die Quelltexte zur Verfügung """
>
> Ja und? Willst du ihm raten, daß er, um SunOS 4 Rückwärts-Binaries
> zu erzeugen, die dann mit den Rückwärts-Libraries laufen, eine
> Uralt-Version des SunOS 4 Compilers vom Schwarzmarkt besorgt und
> dann neu kompiliert?
Nein, denn sie wollen ja von der alten Hardware und vom verwendeten
Uralt-SunOS weg.
Offenbar kennst du seine Anforderungen besser als ich ;-) AFAIR hatte
er davon gesprochen, dass sie überlegen, die Software auf Linux zu
portieren, dass es aber eine verwendete Bibliothek nicht für Linux
gibt. Diese Bibliothek gibt es aber scheinbar für neuere
Solaris-Versionen, etliche andere Unixe und sogar win32.
Daher hatte ich gemeint, dass es wahrscheinlich einfacher wäre, das
Teil auf eine neuere Solaris^wSunOS-Version zu portieren als auf
Linux.
Gerhard
--
Linux lilith.hqd-internal 2.4.18-pre7 #1 SMP Tue Feb 5 21:29:20 CET 2002 i686
gargamel.hqd-internal FreeBSD 4.5-STABLE #0: Fri Feb 15 02:34:17 CET 2002 i386
Außentemperatur in München: 5.0 °C Wind: 10.2 m/s
Tibor Pausz
> Klar doch, empfehlt ihm, daß er seine m68k-Binaries auf einem Solaris 8
> laufen läßt. Das wird ihm sicher enorm weiterhelfen. Weil es das so
> toll für m68k gibt!
Klar doch, SunOS 1.x hat ja so tollen X11 Support gehabt! Damals gab es
kein X11 für SunOS. Es kann kein SunOS 1.x sein. Sollte wohl für einen
Oberlehrer bekannt sein.
Und Solaris 1.x lief sehr wohl auf SPARC. Wobei die Frage im Raum steht
was fü ein Computer es überhaupt ist. Auch eine SS1 ist alt.
> Hier posten wirklich nur noch Deppen :-(
Wunderbar wenn Du den Weg der Selbsterkenntnis einschlägst.
Markus Strangl
>> Am sinnvollsten ist es eine neue SUN Blade 100 anzuschaffen, auch nicht
>> teuerer als PC Hardware und deutlich schneller als die alte SUN, die ihr
>> habt. Seht zu, daß Eure Software darauf läuft, fragt den Hersteller an
>> wie es mit einerVersion für Solaris 8 aussieht und dann ist das Thema
>> vom Tisch.
>
> Klar doch, empfehlt ihm, daß er seine m68k-Binaries auf einem Solaris 8
> laufen läßt. Das wird ihm sicher enorm weiterhelfen. Weil es das so
> toll für m68k gibt!
Welchen Teil von "Von der Anwendung stehen die Quelltexte zur Verfügung"
hast du nicht verstanden?
Wo hast du in dem Original-Posting entdeckst du einen Hinweis auf m68k?
Was sagt dir das Stichwort "SunOS4 binary compatibility"?
Prinzipiell bekommt man auch auf einem Solaris8 noch Libraries und
Programme von vor zehn Jahren ohne groesseren Aufwand zum Laufen.
Garantiert aber leichter als von SunOS4 auf Linux.
> Hier posten wirklich nur noch Deppen :-(
... und etliche davon scheinen sich schwer zu tun, hilfreiche Postings zu
verfassen, ohne erst mal zweckfrei herumzuflamen.
Braucht man fuer so ein Ego eigentlich einen Gefahrgutschein?
GrueSZe
Felix von Leitner
> gibt. Diese Bibliothek gibt es aber scheinbar für neuere
> Solaris-Versionen, etliche andere Unixe und sogar win32.
Woher willst du das denn wissen?
Felix von Leitner
> >laufen läßt. Das wird ihm sicher enorm weiterhelfen. Weil es das so
> >toll für m68k gibt!
> Klar doch, SunOS 1.x hat ja so tollen X11 Support gehabt!
Wo schreibe ich da was von SunOS 1? Das schrieb er, nicht ich.
> Damals gab es kein X11 für SunOS.
Wer sagt dir denn, daß das nicht ein wahnsinniger Mitarbeiter von denen
portiert hat? Die Sourcen sind ja offen.
> Es kann kein SunOS 1.x sein.
Who cares?
> Und Solaris 1.x lief sehr wohl auf SPARC.
Du willst dir mal von jemandem den Unterschied zwischen SunOS 1 und
Solaris 1 erklären lassen, bevor du dich wieder irgendwo lächerlich
machst.
Felix von Leitner
> > Klar doch, empfehlt ihm, daß er seine m68k-Binaries auf einem Solaris 8
> > laufen läßt. Das wird ihm sicher enorm weiterhelfen. Weil es das so
> > toll für m68k gibt!
> Welchen Teil von "Von der Anwendung stehen die Quelltexte zur Verfügung"
> hast du nicht verstanden?
Laß mich dir einen Rat geben: wenn du keine Ahnung hast, einfach mal die
Fresse halten. In diesem Fall liegen genau keine Daten vor, die dir
sagen, daß es nicht m68k ist. Wir wissen nicht die OS-Version. Alle
Ratschläge sind also Spekulation und damit nicht nur hinfällig, sondern
wahrscheinlich kontraproduktiv.
> Prinzipiell bekommt man auch auf einem Solaris8 noch Libraries und
> Programme von vor zehn Jahren ohne groesseren Aufwand zum Laufen.
> Garantiert aber leichter als von SunOS4 auf Linux.
Unfug.
Tibor Pausz
> Du willst dir mal von jemandem den Unterschied zwischen SunOS 1 und
> Solaris 1 erklären lassen, bevor du dich wieder irgendwo lächerlich
> machst.
Es hat niemand im ursprüngliche Posting von m68k SunOS geschrieben,
woher kommt die absolute Wahrheit des FvL? Die Wahrscheinlichkeit, daß
es eine SunOS 1.x Maschine, der Autor ist sich der Sache noch nicht
einmal sicher, dürfte eher gering sein. Die X11 vs. SunView Problematik
spricht für Solaris 1.x und nicht für SunOS 1.x, schlußendlich ist es
egal, da es dazu genauerer Informationen bedarf.
Nichts desto trotz ist ein weitaus einfacher eine alte X11 + FrameWork
Anwendung von SunOS alt auf SunOS neu zu portieren, als gleich ein neues
GUI zu verwenden. So wie der Sachverhalt geschildert wurde bietet der
Hersteller dafür sogar Support an nur der Linux Port ist zu teuer.
Alles in allem gibt es keinen Grund diesen Tonfall anzuschlagen. Er ist
beleidigen und in keiner Weise angemessen. Aber typisch FvL, keine
Beitrag zu Diskussion dafür ausfallend werdend.
Sven Mascheck
>> """ Von der Anwendung stehen die Quelltexte zur Verfügung """
> Ja und? Willst du ihm raten, daß er, um SunOS 4 Rückwärts-Binaries zu
> erzeugen, die dann mit den Rückwärts-Libraries laufen, eine
> Uralt-Version des SunOS 4 Compilers vom Schwarzmarkt besorgt und dann
> neu kompiliert?
> Offenbar kennst du SunOS noch schlechter als bisher erkennbar. :(
Allein der Klarheit wegen hättest Du hier unbedingt Deine Erfahrungen mit
"ucbcc", einem Softlink auf den Workshop-Compiler, in Zusammenhang mit
/usr/ucblib/ erwähnen sollen. Damit kommt man auf SunOS5.x bzgl. SunOS4
schon sehr weit (ich habe damit den 4.3BSD-ex mit minimalen Anpassungen
direkt auf SunOS 5 übersetzt.)
Sven
Sven Mascheck
> "ucbcc", einem Softlink auf den Workshop-Compiler
PS: Das stimmt so einfach nicht, das ging IIRC z.B. mit passenden Flags
zumindest auf SunOS 5.5 (vermutlich auch später). Es gibt aber noch
SUNWscpu mit acc(1) (sparc only), auf welchen dieser Softlink zeigt.
Frank-Christian Kruegel
wrote:
>Thus spake Tibor Pausz (pa...@stud.uni-frankfurt.de):
Wo stand m68k? xvt gabs für sun3 und sun3x meines Wissens nicht. Also muß es ein
SunOS 4.1.irgendwas auf sun4 oder sun4c sein, und das ist bis zum heutigen Tage
binärkompatibel, was sauber programmierte Applikationen angeht. Der Tip mit der
Blade war daher gar nicht so verkehrt.
Der ursprüngliche Fragesteller könnte übrigens mal den Output eines uname -a
hier posten, dann könnte man ihm vielleicht wirklich helfen.
Mit freundlichen Grüßen
Dipl.-Ing. Frank-Christian Krügel
IstDa Kommunikationssysteme
Felix von Leitner
> woher kommt die absolute Wahrheit des FvL? Die Wahrscheinlichkeit, daß
> es eine SunOS 1.x Maschine, der Autor ist sich der Sache noch nicht
> einmal sicher, dürfte eher gering sein. Die X11 vs. SunView Problematik
> spricht für Solaris 1.x und nicht für SunOS 1.x, schlußendlich ist es
> egal, da es dazu genauerer Informationen bedarf.
Für Rutengänger und Kristallkugelgucker gibt es sicher auch irgendwo
eine Newsgroup. Woanders. Sollen wir dir ein Taxi rufen oder findest
du alleine raus?
DAS IST GENAU DER PUNKT, MANN! Der Typ hat keine Daten gepostet, mit
denen man eine sinnvolle Antwort geben konnte. Also haben die Leute
hier wild rumphantasiert und irgendwelchen Kram angenommen. Das hilft
niemandem. Nicht dem Fragesteller und auch sonst niemandem hier. Es
müllt bloß die Archive voll.
Gunnar Ritter
> "ucbcc", einem Softlink auf den Workshop-Compiler, in Zusammenhang mit
> /usr/ucblib/ erwähnen sollen. Damit kommt man auf SunOS5.x bzgl. SunOS4
> schon sehr weit (ich habe damit den 4.3BSD-ex mit minimalen Anpassungen
> direkt auf SunOS 5 übersetzt.)
Das ist unter Linux nicht komplizierter. Nur ist es mit den paar
Änderungen eben nicht getan, wenn man so alte Software wirklich
benutzen und nicht nur mal compilieren und ausprobieren will.
/usr/ucb* auf SVr4 hat auch nicht generell die bessere BSD-Legacy-
Emulation als Linux. Zum Beispiel wird flock() auf SVr4 mittels
fcntl() emuliert, was zur Folge hat, daß Locks bei jedem close()
verlorengehen. Sowas bemerkt man natürlich erst zur Laufzeit und
nach einiger Suche. Da das AFAIR längst nicht die einzige Falle
war, würde ich um /usr/ucb lieber einen ganz großen Bogen machen.
Und damit ist Portierung auf Solaris eben keinen Deut einfacher als
auf Linux, weil es bei sauberem Vorgehen auf genau dieselben POSIX-
Features abzielt. Eher schwieriger, weil man die BSD-Funktionen der
glibc bzw. des Linux-Kernels einigermaßen benutzen kann.
Im Zusammenhang mit dieser XVT-Bibliothek mag das anders aussehen,
aber wer proprietäre Klitschensoftware verwendet, ist halt selbst
schuld, wenn das eines Tages zurückschlägt.
Gunnar
Gunnar Ritter
> Da das AFAIR längst nicht die einzige Falle war, würde ich um
> /usr/ucb [auf SVr4] lieber einen ganz großen Bogen machen.
Ach, richtig. Das große Killerfeature von /usr/ucb/cc war, daß er
stets eine Reihe von Symbolen aus der libucb dazulinkt, die es auch
in der libc gibt. Das führt dazu, daß man Legacy-Code und modernen
Code nicht in einem Binary mischen kann. Wenn man /usr/ucb/cc für
sein altes Programm einsetzt und später z.B. Code hinzufügt, der in
guter POSIX.1-Manier readdir() aus <dirent.h> verwenden soll, führt
das beim Linken dazu, daß man readdir(3ucb) erhält. Das liest aber
aus einer struct direct mit anderer Zusammensetzung, obwohl der Typ
für DIR gleich ist. Das Resultat ist dann natürlich Müll. Siehe auch
<http://www.science.uva.nl/pub/solaris/solaris2.html#q6.19>.
Man kann das umgehen, indem man sich die benötigten Objects einzeln
aus /usr/ucblib/libucb.a herauspfriemelt, aber ehe man mit so einem
Unsinn Zeit verschwendet, kann man auch gleich richtig portieren.
Damit ist die Mär von der besonders einfachen Portierung auf Solaris
aber gestorben.
Gunnar
Christian Felsch
> -a hier posten, dann könnte man ihm vielleicht wirklich helfen.
endlich der uname -a:
SunOS tssun4 4.1.4 2 sun4c
Die Hardware ist ca. 9-10 Jahre alt.
Ein Blick in die Quellen der Applikation ergab, daß GUI und non-GUI Teile
ziemlich gut durchmischt sind. Es sieht ziemlich aufwendig aus, das zu
trennen und nur die GUI neu zu programmieren.
Ich habe inzwischen auch herausbekommen, daß es XVT wohl doch für Linux
gibt (als komerzielles Produkt für RH7.2 - aber immerhin). Ich werde also
da erst noch mal weiter forschen und sehen, ob wir um eine aufwendige
Komplett-Portierung herumkommen.
Christian
Frank-Christian Kruegel
wrote:
>> Der ursprüngliche Fragesteller könnte übrigens mal den Output eines uname
>> -a hier posten, dann könnte man ihm vielleicht wirklich helfen.
>Sorry für die ungenauen bzw. falschen Angaben über die Sun. Hier nun
>endlich der uname -a:
> SunOS tssun4 4.1.4 2 sun4c
>Die Hardware ist ca. 9-10 Jahre alt.
Ach, das geht ja direkt noch. Auf einer Sparcstation 5 oder einer Sparcstation
20 läuft SunOS 4.1.4 direkt. Diese Kisten sind relativ gut und preisgünstig zu
bekommen und im Falle einer SS20 mit SM71 CPU oder auch einer SS5 mit 170 Mhz
Turbosparc um Größenordnungen schneller als das, was Ihr da jetzt fahrt. Bei
zwei oder drei Arbeitsplätzen ist das wohl die billigste Lösung.
Ansonsten installiert den Krempel mal unter Solaris 8 und schaut, ob es läuft.
Sofern die SunOS4 Binary Compatibility Packages installiert sind, habt Ihr gute
Chancen.