Hallo Forum! Ich habe hier ein EDA-Tool. Genauen Namen möchte ich nicht nennen. Herstellerfirma fängt mit M an und wurde von Lufthaken-Firma übernommen. Unter rpm-basierten Distros wie RedHat, CentOS, Fedora läuft das Tool. Leider mag ich diese Distros nicht so sehr, da oft ältliche Pakete. Ein aktuelles Ubuntu ist mehr nach meinem Geschmack, da funktionieren die Office-Anwendungen auch besser. Leider läuft das Tool dort aber nicht - wird nicht supported, wird beim Start gesagt. Im Grunde nimmt das Tool nicht am Paketmanagement teil. Der Installer entpackt einfach riesige Datenmengen in das /opt-Verzeichnis, inklusive eigener Libraries in rauhen Mengen. Ich habe mal von den Dateien /etc/lsb-release und /etc/os-release gehört. Aber da einfach rumzupfuschen würde ja die anderen Ubuntu-Anwendungen möglicherweise stören. Wie merkt das Tool eigentlich, dass es "nicht supported" wird. Kann man den Check irgenwie tracen und dann umbiegen? Sind da Umgebungsvariablen im Spiel? Erschwerend kommt noch dazu, dass es eigentlich gar kein Tool ist, sondern ein Plugin für eine größere Software eines anderen Herstellers ... Beim Start kommuniziert es aber erstmal über stdout. Beim Debuggen fertiger Anwendungen unter Linux habe ich bislange keine Ahnung. Hat hier jemand mal den Fingerzeig auf den richtigen Startpunkt? Danke im Voraus!
:
Bearbeitet durch User
Christian S. schrieb: > Wie merkt das Tool eigentlich, dass es "nicht supported" wird. Da gibt's keinen genormten Ansatz. Vielleicht prüfen sie nicht mal die Distribution, sondern z.B. nur die Versionen bestimmter Libraries. Christian S. schrieb: > Kann man > den Check irgenwie tracen und dann umbiegen? Versuch's mal mit strace. Vielleicht siehst Du kurz vor der Ausgabe der Fehlermeldung etwas, das weiterhilft. Wenn die Software dynamisch gelinkt ist, könnte man ihr Wrapper-Funktionen unterjubeln. Wenn nicht, läuft es auf eine Änderung des Binaries (sofern kein Kopierschutz involviert ist, der das schwierig macht) hinaus.
Christian S. schrieb: > Wie merkt das Tool eigentlich, dass es "nicht supported" wird. Schwer zu sagen, wenn das genaue Tool nicht genannt wird, damit man da nachschauen könnte. Wenn ich sowas rausbringen wollte, und sicherstellen wollte, dass es in der vorliegenden Umgebung läuft, dann würde ich die Versionen der gelinkten Libs als Kriterium nehmen. Die Libs sind’s ja schließlich auch, die bei ungetesteten Versionen für Probleme sorgen können. Pack dein Ding mit der von ihm gewünschten Umgebung in einen Container oder in eine VM, und gut.
Christian S. schrieb: > Ein aktuelles Ubuntu ist mehr nach meinem Geschmack, da funktionieren > die Office-Anwendungen auch besser. Leider läuft das Tool dort aber > nicht - wird nicht supported, wird beim Start gesagt. Möglicherweise packst Du das Teil einfach in eine VM oder einen Docker-Container? Auch die kann man mit X-Software benutzen, einige Anregungen kannst Du unter [1] bei der wunderbaren Jessie Frazelle finden. [1] https://github.com/jessfraz/dockerfiles
Danke allen erstmal, da hört sich vieles nach guten Experimentiermöglichkeiten an. Kopierschutz gibt es so direkt keinen, man könnte theoretisch an den Binaries rumbasteln. Das Programm kontaktiert aber einen Lizenzserver. Zum Thema "Distro an den Library-Versionen erkennen". Das Tool bringt enorm viel an eigenen Libraries mit, da wird es wahrscheinlich gar nicht nach den Distro-Libs gucken ....
Du kannst auch ein AppArmor Script erstellen. Und dann systematisch die Dateien erlauben, die es zum laufen nötig hat. Da sieht man auf welche er zugreifen möchte einfach mit dmesg und ab irgend einem Punkt wird deine "Nicht supported" Meldung kommen. Stell dich aber mal auf 1-2Std Arbeit ein, bis du soweit bist. Dann hast du wahrscheinlich als letzten Zugriff die passende. Das ganze basiert natürlich auf der Annahme, dass ein Dateizugriff entscheidend ist.
Christian S. schrieb: > Hat hier jemand mal den Fingerzeig auf den richtigen Startpunkt? Wenn das *entor von *iemens ist: Löschen, jede Erinnerung daran ausbrennen und etwas bedienbares verwenden.
Christian S. schrieb: > Ich habe hier ein EDA-Tool. Genauen Namen möchte ich nicht nennen. > Herstellerfirma fängt mit M an und wurde von Lufthaken-Firma übernommen. Mentor graphics jetzt bei siemens. Wahrscheinlich geht es um den HDL-simulator modelsim. Oder eines der PCB-Layout-tools....
Christian S. schrieb: > Ich habe hier ein EDA-Tool. Genauen Namen möchte ich nicht nennen. > Herstellerfirma fängt mit M an und wurde von Lufthaken-Firma übernommen. Ja, das hilft natürlich wenn keiner weiß von welchem Tool du redest. Wovor hast du Angst? Denkst du, dass Roland Busch hier persönlich mitliest und dich anzeigen könnte? In einem ähnlichen Fall konnte ich z.B. Cadence Incisive (schon ein paar Jahre her, mit Xcelium hab ich's noch nicht probiert) problemlos unter Linux Mint laufen lassen. > Erschwerend kommt noch dazu, dass es eigentlich gar kein Tool ist, > sondern ein Plugin für eine größere Software eines anderen Herstellers <seufz!> > Beim Debuggen fertiger Anwendungen unter Linux habe ich bislange keine > Ahnung. Hat hier jemand mal den Fingerzeig auf den richtigen Startpunkt? Häufig werden solche Tools über ein Wrapper Script gestartet, dem manchmal nur ein entsprechender Zweig in einem case-statement fehlt. Wenn du dann bis zum Binary durchkommst, und es immer noch nicht startet, kannst du mit ‘ldd’ schauen, ob alle Libraries gefunden werden und diese ggf. per Hand nachinstallieren oder Links auf vorhandene setzen und hoffen, dass es trotzdem funktioniert. Möglicherweise hilft dir auch ‘strace’ weiter, wenn das Binary irgendwann aussteigt. Oder einfach eine VM mit einem der unterstützten OS anlegen.
Pack es doch einfach in einen Snap mit core18 bzw. wenn möglich core20. Sehe das Problem nicht? Tipp wenn du den Snap anlegst: Fange direkt mit strict confinement an.
Marcus H. schrieb: >> Erschwerend kommt noch dazu, dass es eigentlich gar kein Tool ist, >> sondern ein Plugin für eine größere Software eines anderen Herstellers > > <seufz!> Wahrscheinlich meint der TOttel Quartus oder Lattice diamond also eine FPGA-toolchain. Darin ist Modelsim kein "Plugin" sondern ein Paralleltool das man auch ausserhalb der "größeren" Software benutzen kann.
Ueblicherweise wird nur uname aufgerufen, und der Ausgabestring geprueft. uname umbenennen, und ein ausfuerhbares Shellscript an die selbe legen. Wenn da ein "echo" etwas passendes ausgibt, reicht das dann auch.
Christian S. schrieb: > Unter rpm-basierten Distros wie RedHat, CentOS, Fedora läuft das Tool. > Leider mag ich diese Distros nicht so sehr, da oft ältliche Pakete. > > Ein aktuelles Ubuntu ist mehr nach meinem Geschmack, da funktionieren > die Office-Anwendungen auch besser. Leider läuft das Tool dort aber > nicht - wird nicht supported, wird beim Start gesagt. Du schreibst nicht, ob das Tool als rpm-Paket vorliegt. Ich weiß nicht, ob es in Deinem Fall hilft, aber unter Debian (und auch ubuntu) gibt es zum installieren von rpm basierten Paketen das Programm alien. http://www.debianadmin.com/install-rpm-files-in-debian-and-ubuntu.html
Alexander S. schrieb: > Du schreibst nicht, ob das Tool als rpm-Paket vorliegt. Doch, er schreibt, dass es das nicht tut: Christian S. schrieb: > Im Grunde nimmt das Tool nicht am Paketmanagement teil. Der Installer > entpackt einfach riesige Datenmengen in das /opt-Verzeichnis, inklusive > eigener Libraries in rauhen Mengen. Und das hier: Alexander S. schrieb: > Ich weiß nicht, > ob es in Deinem Fall hilft, aber unter Debian (und auch ubuntu) gibt es > zum installieren von rpm basierten Paketen das Programm alien. ...bringt eher wenig, wenn die Software bereits installiert ist, aber beim Start eine Fehlermeldung ausgibt.
Aaalso dass ich nicht alles so direkt beim Namen nenne liegt nicht daran, dass ich Angst habe, verhaftet zu werden, sondern dass es auch (ex)Kollegen gab und gibt die schon an solchen oder ähnlichen Sachen herumgebastelt haben und die hier mitlesen. Falls ich die Lösung finden sollte, schreibe ich sie hier natürlich rein, damit auch andere was davon haben. Der Grund, dass die Hersteller sich auf bestimmte Distros beschränken ist ja auch nur, dass der - teils kostenpflichtige - Support nicht jedem Betriebssystem-Problemchen nachgehen möchte... Es geht um eine größere Landschaft von Cadence-Werkzeugen. Nur ein einziges Plugin ist von Mentor (hat irgendwie historische Gründe). Die Cadence-Werkzeuge benutzen genau den von Markus H. beschriebenen Mechanismus mit dem Wrapper-Skript. Einmal eine Zeile in der Nähe des case-Schlüsselwortes eines bash-scripts geändert, schon ist die Distributionsabfrage ausgehebelt. Die neueren Versionen der Cadence-Werkzeuge benutzen sogar gar keine Wrapper-Skripte mehr. Da muss man nur die entsprechende Libraries nachinstallieren und es läuft. Problem: man muss die Library-Namen irgendwie kreativ erraten, was aber möglich ist. Paar Umgebungsvariablen muss man auch passend setzen. Das Mentor-Tool hat aber einen mir komplett unbekannten Mechanismus zur Distro-Abfrage. Mit Containern habe ich mich nie groß befasst. Ich habe aber mal eine Mechanik-CAD benutzt, die als Container lief. Ich war überrascht wie gut das ging. Ich bin eigentlich mehr für Hardware zuständig. Ich denke, dass der Charakter des Mentor-Tools als Plugin irgendwie gegen den Container-Einsatz spricht. Da wird es ja von der Software, der es dienen soll, wegisoliert. Ich denke, ich werde mit low-level-Werkzeugen wie strace anfangen. Der AppArmor-Ansatz klingt aber auch nicht schlecht, falls sich der Distro-Hinweis irgendwie in einer Datei versteckt.
:
Bearbeitet durch User
Christian S. schrieb: > Danke allen erstmal, da hört sich vieles nach guten > Experimentiermöglichkeiten an. > > Kopierschutz gibt es so direkt keinen, man könnte theoretisch an den > Binaries rumbasteln. Das Programm kontaktiert aber einen Lizenzserver. > > Zum Thema "Distro an den Library-Versionen erkennen". Das Tool bringt > enorm viel an eigenen Libraries mit, da wird es wahrscheinlich gar nicht > nach den Distro-Libs gucken .... Hier wurde schon strace(1) genannt, das Dir die Systemaufrufe des laufenden Programms anzeigt. Ebenfalls manchmal nützlich ist das Programm ltrace(1), das dasselbe mit Library-Aufrufen tun kann. Ansonsten kannst Du das Binary auch mal mit ldd(1) oder den laufenden Prozeß mit pldd(1) untersuchen, was das Programm laden will bzw. lädt.
Christian S. schrieb: > Die Cadence-Werkzeuge benutzen genau den von Markus H. beschriebenen > Mechanismus mit dem Wrapper-Skript. Einmal eine Zeile in der Nähe des > case-Schlüsselwortes eines bash-scripts geändert, schon ist die > Distributionsabfrage ausgehebelt. Diese Leute sind so unfaßbar dämlich, echt jetzt. Entweder ich setze das durch, dann aber bitte hart und nicht in einem änderbaren Skript, oder ich gebe einfach eine Warnung aus und / oder fordere, daß die Software mit dem Parameter "--unsupported=i_know" gestartet wird. > Die neueren Versionen der Cadence-Werkzeuge benutzen sogar gar keine > Wrapper-Skripte mehr. Da muss man nur die entsprechende Libraries > nachinstallieren und es läuft. Problem: man muss die Library-Namen > irgendwie kreativ erraten, was aber möglich ist. Unser Freund heißt ldd(1) oder pldd(1). > Das Mentor-Tool hat aber einen mir komplett unbekannten Mechanismus zur > Distro-Abfrage. > > Mit Containern habe ich mich nie groß befasst. Ich habe aber mal eine > Mechanik-CAD benutzt, die als Container lief. Ich war überrascht wie gut > das ging. Ich bin eigentlich mehr für Hardware zuständig. Alles gut, Container sind kein Hexenwerk, aber eher was für Admins. Aber für solche Fälle eben auch gut brauchbar. > Ich denke, dass der Charakter des Mentor-Tools als Plugin irgendwie > gegen den Container-Einsatz spricht. Da wird es ja von der Software, der > es dienen soll, wegisoliert. Naja, die "Vater"-Software wird ja irgendwie mit dem Plugin kommunizieren. Frei nach dem UNIX-Motto "alles ist eine Datei" kann man die Dateien, die diese Kommunikation ermöglichen, natürlich in den Container mounten. Genau so funktioniert das ja auch mit dem Socket des X-Servers. > Ich denke, ich werde mit low-level-Werkzeugen wie strace anfangen. Der > AppArmor-Ansatz klingt aber auch nicht schlecht, falls sich der > Distro-Hinweis irgendwie in einer Datei versteckt. Ich glaube, die Traces sind schon genug Aufwand. AppArmor ist da eine sehr gute Lösung, aber vermutlich auch arbeitsintensiver -- ich möchte keine Audit-Logs ohne umfangreiche Vorverarbeitung mehr lesen. ;-)
Es steht ja noch die Vermutung von ... (Gast) im Raum, dass nur uname aufgerufen wird. Falls das stimmen sollte, ist vermutlich nur wenig Aufwand nötig. Ich lege irgendwo im Dateisystem ein fake uname ab, was sich fest verdrahtet immer mit "Red Hat irgendwas" meldet. Dann setze ich die PATH-Variable für das Mentor Tool so, dass es auf das fake uname eher trifft aus auf das echte uname. Geht das so? Ich kann es aber erst morgen früh testen. Bitte seid gnädig, ich bin nur Linux-Anwender, kein Linux-Admin. ldd(1) und pldd(1) kenne ich nur wenig, weil mir dynamisches Linken eh ein Buch mit sieben Siegeln ist.
Christian S. schrieb: > Ich denke, dass der Charakter des Mentor-Tools als Plugin irgendwie > gegen den Container-Einsatz spricht. Calibre / Virtuoso Die können auch unabhängig voneinander laufen. Müssen meines Wissens nach nur Zugriff auf die gleiche oa database haben. Ist halt etwas umständlich. Christian S. schrieb: > Der Grund, dass die Hersteller sich auf bestimmte Distros beschränken > ist ja auch nur, dass der - teils kostenpflichtige - Support nicht jedem > Betriebssystem-Problemchen nachgehen möchte... Cadence gibt in seinem Online Support Portal Tipps wie man die Software auf nicht unterstützten OS zum Laufen bringen kann. Vielleicht macht Siemens das auch? BTW: ein aktuelles Fedora hat doch immer aktuelle Pakete
> Calibre / Virtuoso Genau das ist es. > Die können auch unabhängig voneinander laufen. Müssen meines Wissens > nach nur Zugriff auf die gleiche oa database haben. Ist halt etwas > umständlich. Ja, aber ich mich möchte ja nicht Nicht-Umständlichkeit von Ubuntu wieder gegen Umständlichkeit an anderer Stelle eintauschen. Ich hoffe, es morgen mit dem kleinen "fake uname"-Mechanismus hinzubekommen. > auf nicht unterstützten OS zum Laufen bringen kann. Vielleicht macht > Siemens das auch? Ich habe länger nicht mehr geguckt, aber ich habe Mentor-Foren als anstrengend in Erinnerung. Geht nicht, ham wer nicht, unterstützen wir nicht. > BTW: ein aktuelles Fedora hat doch immer aktuelle Pakete Ja stimmt, ich finde aber Distributionen, die mit *.rpm arbeiten immer doof. Früher oder später verklemmt sich da immer was, so dass der Admin gerufen werden muss. *.deb ist viel smarter, da kann man jahrelang mit produktiv arbeiten, auch mit moderner Bürosoftware. Ferner ist Canonical/Ubuntu die Firma, die am ehesten finanzielle Resourcen hat, um die Benutzerfreundlichkeit von Linux zu erhöhen.
Christian S. schrieb: > Ich lege irgendwo im Dateisystem ein fake uname ab, was sich fest > verdrahtet immer mit "Red Hat irgendwas" meldet. Nicht irgendwo im Dateisystem, sondern da, wo es hingehört: natürlich in /usr/local/bin/. Aaaber... > Dann setze ich die PATH-Variable für das Mentor Tool so, dass es auf das > fake uname eher trifft aus auf das echte uname. Geht das so? Wenn der Entwickler blöd war: ja. Wenn nicht, hat er /usr/bin/uname fest verdrahtet und ein Umbau von PATH hilft dann wenig. Angesichts der enormen Varianzen, die ich bei der Ausgabe von uname(1) bisher gesehen habe, halte ich es aber auch für unwahrscheinlich, daß irgendwer so blöd ist. Das würde beim ersten selbstkompolierten Kernel sofort explodieren und wäre keine stabile Lösung. An PATH herumzufummeln ist übrigens etwas, von dem ich aus verschiedenen Gründen dringend abrate. Du kannst ein Programm mit einem vorangestellten VARIABLE=name starten und die Umgebungsvariable damit nur für diesen einen Prozeß setzen, wie in: "LANG=C man ls". > Bitte seid gnädig, ich bin nur Linux-Anwender, kein Linux-Admin. Alles gut, mußt Du nicht sein. > ldd(1) und pldd(1) kenne ich nur wenig, weil mir dynamisches Linken eh > ein Buch mit sieben Siegeln ist. Eigentlich ist das sogar ziemlich einfach: ein Prozeß öffnet ein Shared Object (*.so, in der Windows-Welt eine *.dll-Datei) mit dlopen(3), löst dessen Symbole mit dlsym(3) auf... aber das mußt Du nicht wissen, wenn es nur darum geht, was der Prozeß tut. Probiers einfach mal aus, viel Glück und Erfolg dabei, und im Zweifelsfall fragst Du noch einmal. Hier gibt es viele gute Leute, ganz vorne Ernst und Daniel. ;-)
Christian S. schrieb: > Ja stimmt, ich finde aber Distributionen, die mit *.rpm arbeiten immer > doof. Früher oder später verklemmt sich da immer was, so dass der Admin > gerufen werden muss. *.deb ist viel smarter, da kann man jahrelang mit > produktiv arbeiten, auch mit moderner Bürosoftware. Wenn wir ehrlich sind: in beiden Fällen kann sich was verknoten, und man braucht dann einen Könner. De facto machen Debian-Pakete aber einen, auf lange Sicht, viel stabileren Eindruck. Das liegt allerdings weniger am Paketformat, sondern an der Pflege. RedHat und Konsorten haben sich früh auf serverseitige Installationen konzentriert und sind im Desktopbereich weniger angenehm als ein Debian, *Buntu oder Mint. > Ferner ist Canonical/Ubuntu die Firma, die am ehesten finanzielle > Resourcen hat, um die Benutzerfreundlichkeit von Linux zu erhöhen. Die Ressourcen hat RedHat sogar noch viel mehr, aber sie investieren ihr Geld anders. Eine lange Geschichte vom GCC-2.96 bis hin zu heute Podman belegt, daß RedHat nicht kooperativ sein möchte. Das wollen die Canonical-Leute auch nicht, aber sie versuchen es immerhin über Innovation statt über Einsperrungen und gezielte Inkompatibilität.
Christian S. schrieb: >> Calibre / Virtuoso > > Genau das ist es. Verstehe ich das richtig: Du machst schematic und Layout mit Virtuoso und dann DRC und LVS mit Calibre?
Nicht ich, sondern die Kollegen. Assura wird auch noch eingesetzt. Die Tools hat mein Chef ausgesucht. Wenn man das Mentor-Plugin sinnvoll ersetzen kann, gebe ich die Anregung gerne weiter. Ich bin aber noch nicht im Büro. Mir fällt auch auf, dass ich gar nicht mehr sicher bin, ob das Mentor-Plugin "Calibre" oder "Caliper" heisst .....
Christian S. schrieb: > Nicht ich, sondern die Kollegen. Assura wird auch noch eingesetzt. > Die Tools hat mein Chef ausgesucht. > Wenn man das Mentor-Plugin sinnvoll ersetzen kann, gebe ich die Anregung > gerne weiter. Ich bin aber noch nicht im Büro. Mir fällt auch auf, dass > ich gar nicht mehr sicher bin, ob das Mentor-Plugin "Calibre" oder > "Caliper" heisst ..... Welche Tools ihr verwendet liegt aber auch an der Fab und den vorhandenen PDKs. In aktuellen Prozessen < 130 nm setzen viele Halbleiterhersteller auf Calibre. Assura ist nur noch bis irgendwann nächstes Jahr erhältlich, wurde schon länger auf Cadence Seite durch PVS ersetzt. Ich würde so wenig an den Tools "rumoperieren" als möglich. Manchmal wird eine bestimmte Version vorausgesetzt und dann musst du den hack immer wieder neu machen.
Ich habe mir angewöhnt möglichst wenig am Host-System herumzubasteln. Früher oder später fällt dir das auf die Füße. Irgendwas läuft nach 'nem Update nicht mehr, du weißt nicht mehr was du alles geändert hast und wieso, usw. Ich würde hier schnell ne VM mit einer rpm-basierten Distribution aufsetzen und das Teil da reinpacken. Auch auf Arbeit gilt dass eine Toolchain möglichst einfach in Betrieb zu nehmen sein sollte. Wir haben hier noch Altlasten, alte Projekte wo niemand mehr so recht weiß wie man das zeugs zum Laufen bringt und man erstmal tagelang alte Dokus wälzen und abarbeiten darf. Neue Projekte werden natürlich zeitgemäßer aufgesetzt.
Ich bin ja froh, dass solche Probleme auch in einer professionellen Version auftreten. Ich hätte vermutet, dass man sich so nur nörgelnde Bastler fernhält, die kostenlosen Support suchen. Ich habe mir letztes Jahr Quartus Lite 21.1.0 unter dem damals aktuellen Ubuntu installiert, inzwischen gibt es schon mehrere Updates, die leider nicht automatisch nachinstalliert werden. Anscheinend muss ich alles deinstallieren, dazu gibt es irgendwo ein Skript, und das ganze Paket 22.1 (7 GByte .tar gepackt) mit einem mitgelieferten Skript komplett neu installieren. Ist da wirklich kein automatisches Update vorgesehen? https://www.intel.com/content/www/us/en/software-kit/757261/intel-quartus-prime-lite-edition-design-software-version-22-1-for-linux.html Leider wird öfters die Benutzeroberfläche geändert, sodass ältere Tutorials nicht mehr passen. Mein altes Projekt von 2008 läuft aber ohne Fehlermeldung durch, wenigstens hat sich daran nichts geändert. Den Luxus eines Updates werde ich mir jedenfalls nicht oft gönnen.
:
Bearbeitet durch User
Christian S. schrieb: > Wie merkt das Tool eigentlich, dass es "nicht supported" wird. Ich hab kaum Ahnung von Linux aber bei Windows würde ich einfach den VERSION-Befehl aufrufen, umlenken notfalls falls ich keine Kernel-Funktion habe, und das Ergebnis auslesen. Ich habe einige Befehle gelernt die mit unter Linux die genau Version-Daten geben. Und ich denke ich kann diesen Befehl auch in eine Textdatei umlenken bzw. ihn selbst ausführen . Würde mich echt wundern wenn es dafür kein Befehl im Compiler gibt, z.b. via Kernel-Abfrage im Code. Irgendwelche Ominöse Libs nach ihrer Version fragen halte ich für Unsinn. Das einzige was mich wirklich juckt ist das Kernel. ABER. Christian S. schrieb: > Der Installer entpackt einfach riesige Datenmengen in das > /opt-Verzeichnis, inklusive eigener Libraries in rauhen Mengen. Und genau DA liegt das Problem. Eine Fake-Meldung für die Falsche Linux-Version ihm unterzujubeln macht das System extrem instabil falls es überhaupt läuft. Libs werden fast immer auf das System abgestimmt. Aber da hier ja alle für VM's sind (inkl. mir) wieso nicht einfach eine VM installieren mit den passenden OS. Festplattenplatz kostet fast nix, und das sollte das Problem risikofrei lösen.
Schlaumaier schrieb: > > Ich hab kaum Ahnung von Linux. Dann halte doch einfach Dein Plappermaul oder bist Du nur noch ein Bot der besinnungslos irgendwas daherschreibt nur weil im Thread noch nix von Dir zu lesen ist?
Evtl. mal mit strace -f vorweg starten, mit etwas Glück erkannt man dann woran es hängt.
Christian S. schrieb: > Mit Containern habe ich mich nie groß befasst. Ich habe aber mal eine > Mechanik-CAD benutzt, die als Container lief. Ich war überrascht wie gut > das ging. Ich bin eigentlich mehr für Hardware zuständig. > > Ich denke, dass der Charakter des Mentor-Tools als Plugin irgendwie > gegen den Container-Einsatz spricht. Da wird es ja von der Software, der > es dienen soll, wegisoliert. Cotainerisierung schottet das Programm vom restlichen System ab, das stimmt. Allerdings kann man dann eben gezielt bestimmte Ressourcen wieder verfügbar machen. Damit kannst du dann z.B. einen RedHat-basierten Container machen und dann den Kommunikationsweg zum Hauptprogramm öffnen. Voraussetzung ist natürlich, dass du herausfindest, wie der aussieht. Karl Käfer schrieb: > Eine lange Geschichte vom GCC-2.96 bis hin zu heute Podman belegt, daß > RedHat nicht kooperativ sein möchte. Oh, beim "GCC 2.96" werden dunkle Erinnerungen wach…
Hallo Gemeinde, ich hatte noch nicht so viel Zeit mich drum zu kümmern, leider. Zwei Korrekturen: Das Tool heißt calibre, nicht caliper. Das Verzeichnis, in dem der Installer groß Dateien verteilt, fängt nicht mit /opt an, sondern mit /eda. Das Mentor-Tool hat dann irgendwie weiter dadrin seinen eigenen bin-Ordner. Konnte nur kurz was testen. Wenn man in dem bin-Ordner "grep uname *" ausführt, kommt folgendes:
1 | calibre: if test `uname -s` = AIX |
2 | Binary file calibre_Xvfb matches |
3 | calibre_env:MGC_WKSTN=`uname -s` |
4 | calibre_env: echo "## `date` -- `uname -a`" >&2 |
5 | calibredrv: if test `uname -s` = AIX |
6 | calibrelv: if test `uname -s` = AIX |
7 | calibremdpv: if test `uname -s` = AIX |
8 | calibrerve: if test `uname -s` = AIX |
9 | calibrewb: if test `uname -s` = AIX |
10 | calumcdecrypt: if test `uname -s` = AIX |
11 | cgi_app: if test `uname -s` = AIX |
12 | dfmexplorer: if test `uname -s` = AIX |
13 | ecofill: if test `uname -s` = AIX |
14 | fdi_env: unames=`$UNAME -s` |
15 | fdi_env: unamem=`$UNAME -m` |
16 | fdi_env: unamer=`$UNAME -r` |
17 | fdi_env: unamev=`$UNAME -v` |
18 | fdi_env: echo "ERROR: Could not find 'uname' system utility" >&2 |
19 | fdi_env: unames="UNKNOWN" |
20 | fdi_env: unamem="UNKNOWN" |
21 | fdi_env: unamer="UNKNOWN" |
22 | fdi_env: unamev="UNKNOWN" |
23 | fdi_env:MGC_WKSTN="$unames" |
24 | fdi_env:case "$unames" in |
25 | fdi_env: if test "$unamem" = "x86_64" |
26 | fdi_env: test "$unamem" != "x86_64" && CALIBRE_64BIT_CAPABLE='' |
27 | fdi_env: echo "ERROR: Unknown system type: $unames" >&2 |
28 | fdi_util:unamer=`uname -r` |
29 | fdi_util:unames=`uname -s` |
30 | fdi_util:unamem=`uname -m` |
31 | fdi_util: if test "$unamem" = "x86_64" |
32 | ge: if [ -f ${dir}/uname ] ; then
|
33 | ge: UNAME=`${dir}/uname`
|
34 | ge: UNAMER=`${dir}/uname -r`
|
35 | ge: UNAMER=`${dir}/uname -r`
|
36 | Binary file libScoring matches |
37 | Binary file lmcksum matches |
38 | Binary file lmdown matches |
39 | Binary file lmgrd matches |
40 | Binary file lmhostid matches |
41 | Binary file lmnewlog matches |
42 | Binary file lmpath matches |
43 | Binary file lmremove matches |
44 | Binary file lmreread matches |
45 | Binary file lmstat matches |
46 | Binary file lmswitchr matches |
47 | Binary file lmutil matches |
48 | Binary file lmver matches |
49 | memcached:if [ `uname -s` = "Linux" ]; then |
50 | memcached: if uname -m 2>/dev/null | fgrep -v 64 >/dev/null 2>&1 |
51 | memcapable:if [ `uname -s` = "Linux" ]; then |
52 | memcapable: if uname -m 2>/dev/null | fgrep -v 64 >/dev/null 2>&1 |
53 | memcat:if [ `uname -s` = "Linux" ]; then |
54 | memcat: if uname -m 2>/dev/null | fgrep -v 64 >/dev/null 2>&1 |
55 | memcp:if [ `uname -s` = "Linux" ]; then |
56 | memcp: if uname -m 2>/dev/null | fgrep -v 64 >/dev/null 2>&1 |
57 | memdump:if [ `uname -s` = "Linux" ]; then |
58 | memdump: if uname -m 2>/dev/null | fgrep -v 64 >/dev/null 2>&1 |
59 | memerror:if [ `uname -s` = "Linux" ]; then |
60 | memerror: if uname -m 2>/dev/null | fgrep -v 64 >/dev/null 2>&1 |
61 | memexist:if [ `uname -s` = "Linux" ]; then |
62 | memexist: if uname -m 2>/dev/null | fgrep -v 64 >/dev/null 2>&1 |
63 | memflush:if [ `uname -s` = "Linux" ]; then |
64 | memflush: if uname -m 2>/dev/null | fgrep -v 64 >/dev/null 2>&1 |
65 | memparse:if [ `uname -s` = "Linux" ]; then |
66 | memparse: if uname -m 2>/dev/null | fgrep -v 64 >/dev/null 2>&1 |
67 | memping:if [ `uname -s` = "Linux" ]; then |
68 | memping: if uname -m 2>/dev/null | fgrep -v 64 >/dev/null 2>&1 |
69 | memrm:if [ `uname -s` = "Linux" ]; then |
70 | memrm: if uname -m 2>/dev/null | fgrep -v 64 >/dev/null 2>&1 |
71 | memslap:if [ `uname -s` = "Linux" ]; then |
72 | memslap: if uname -m 2>/dev/null | fgrep -v 64 >/dev/null 2>&1 |
73 | memstat:if [ `uname -s` = "Linux" ]; then |
74 | memstat: if uname -m 2>/dev/null | fgrep -v 64 >/dev/null 2>&1 |
75 | memtouch:if [ `uname -s` = "Linux" ]; then |
76 | memtouch: if uname -m 2>/dev/null | fgrep -v 64 >/dev/null 2>&1 |
77 | mgcdocs: case "`uname -s`" in |
78 | mgcdocs: case "`uname -s`" in |
79 | mgcdocs: if [ "`uname -s`" = "Linux" ]; then |
80 | mpower: if test `uname -s` = AIX |
81 | rmemcached:if [ `uname -s` = "Linux" ]; then |
82 | rmemcached: if uname -m 2>/dev/null | fgrep -v 64 >/dev/null 2>&1 |
83 | tclmsc: if test `uname -s` = AIX |
84 | Binary file thermal3dstack matches |
85 | waiver_flow: if test `uname -s` = AIX |
Christian S. schrieb: > Das Tool heißt calibre Hm. Sehr ungewöhnlich das 2 verschiedene Programme wovon 1 berühmt ist, den selben Namen tragen. https://de.wikipedia.org/wiki/Calibre <- das ist das Prg. was ich kenne.
> Ich hab kaum Ahnung von "*" Und das in vollem Umfang! Also: Gusche zu. > Eine Fake-Meldung für die Falsche > Linux-Version ihm unterzujubeln macht das System extrem instabil Unfug. Der Installer wollte damals ein Redhat 7.0. So alte Hardware wollte man nicht mehr kaufen. Kein SATA, kein Nuex. Das System lief dann 24/7 unter Redhat 9(?) als Backupserver mit Tivoli TSM. Und zwar, und das zu meiner vollsten Zufriedenheit, stabil. > memcached:if [ `uname -s` = "Linux" ]; then > memcached: if uname -m 2>/dev/null | fgrep -v 64 >/dev/null 2>&1 ... > Binary file thermal3dstack matches > waiver_flow: if test `uname -s` = AIX Ein Versionsstring ist da ja leider noch nicht dabei. YMMV
Christian S. schrieb: > Wenn man in dem bin-Ordner "grep uname *" ausführt, kommt folgendes > ge: if [ -f ${dir}/uname ] ; then > ge: UNAME=`${dir}/uname` > ge: UNAMER=`${dir}/uname -r` Da ist evtl. was drin, da wird die Kernel-Version in $UNAMER gepackt. Was dann weiter damit passiert, sieht man mangels grep -i nicht. Ansonsten mal Teile der Fehlermeldung ("unsupported xxx") greppen.
Christian S. schrieb: > Ich habe mal von den Dateien /etc/lsb-release und /etc/os-release > gehört. Es gibt auch ein Tool namens lsb_release. Das wäre für eine Erkennung der Distribution deutlich besser geeignet als uname. Vielleicht wird das ja auch irgendwo aufgerufen.
Ganz ehrlich: mit den Tools verdient man Geld und dann sollen sie auch stabil laufen, oder? Wenn ich den Eingangspost richtig verstehe, läuft es auch unter Fedora? Da gibt es immerhin Recht aktuelle Pakete. Ubuntu ist eigentlich ja auch alles andere als „bleeding edge“.
Löppt schrieb: > Ganz ehrlich: mit den Tools verdient man Geld und dann sollen sie auch > stabil laufen, oder? Ach, das ist so eine Sache. Der Einsatzzweck ist hier kein großer Halbleiterkonzern, sondern eine Bildungseinrichtung. Meine Kollegen hatten alle gute Ubuntu-Installationen, bei der auch Büro-Sachen wie pdf-Verarbeitung und Treiber für das Büro-Multifunktionsgerät (nach paar kleine Eingriffen) gut funktionierten. Dann mussten wir auf eine *.rpm-Distro umsatteln. Dass wir eine mit eher älteren Paketen wählten lag daran, dass ja irgendwie die Schnittmenge der Kompatibiliäts-Matrix zwischen Mentor und Cadence gewahrt werden musste. Die CAD-EDA-Sachen laufen damit, ohne jede Frage. Die Bürosoftware jedoch nicht mehr so gut. Die Kollegen bringen teilweise einen Windows-Laptop von zuhause mit und stellen ihn neben den Büro-PC. > Wenn ich den Eingangspost richtig verstehe, läuft es auch unter Fedora? Offiziell laut Schnittmengen-Kompatibiltäts-Matrix nicht (glaube ich), aber es wäre einen Versuch wert. > Da gibt es immerhin Recht aktuelle Pakete. Ubuntu ist eigentlich ja > auch alles andere als „bleeding edge“. Ich mag irgendwie das *.rpm-Paketformat überhaupt nicht. Da ist immer so ein komisches Super-Überwachungs-Werkzeug wie "yum" oder "yast2" im Hintergrund tätig. Bei Debian-artigen Distros verstehe ich eher, was da im Hintergrund passiert und was apt, dpkg usw machen. Ich überlege sogar folgendes: Theoretisch könnte man ja aus den von einem krummen Installer irgendwo hinkopierten Dateien wieder ein *.deb-Paket machen. Das wäre schöner, wenn es mal ein Update gibt und man kann es einfacher an viele Leute verteilen. Leider reichen meine Kenntnisse hier noch nicht aus und die Zeit fehlt mir auch.
> Die Kollegen bringen teilweise einen Windows-Laptop von zuhause mit
Da wuerde ich ja eher einen Virtualisierer auf die Kiste tun.
Manch einer freut sich darueber an "seinem" Linux ohne
Beteiligung der Firmen-IT zu frickeln, aber andersherum
geht das natuelich auch...
Rolf M. schrieb: > Karl Käfer schrieb: >> Eine lange Geschichte vom GCC-2.96 bis hin zu heute Podman belegt, daß >> RedHat nicht kooperativ sein möchte. > > Oh, beim "GCC 2.96" werden dunkle Erinnerungen wach… Ja. Und diese Erinnerungen ziehen sich leider wie ein roter Faden durch die Geschichte von Linux und RedHat.
Karl Käfer schrieb: > Entweder ich setze das durch, dann aber bitte hart und nicht > in einem änderbaren Skript JA, wenn Du als Entwickler der SW das durchsetzen willst, dann machst Du die Sperre sicher härter, aber wenn Du als Entwickler bloß vom Management die Anweisung bekommst: darf nur auf Distro X, Y oder Z laufen - dann machst Du das absolute Minimum, um diese Vorgabe zu erfüllen, also ein simples Wrapper-Script; umso mehr, weil Du ja weist, daß Deine SW auf jeder gängigen, halbwegs aktuellen Distro laufen würde.
Karl Käfer schrieb: > Rolf M. schrieb: >> Karl Käfer schrieb: >>> Eine lange Geschichte vom GCC-2.96 bis hin zu heute Podman belegt, daß >>> RedHat nicht kooperativ sein möchte. >> >> Oh, beim "GCC 2.96" werden dunkle Erinnerungen wach… > > Ja. Und diese Erinnerungen ziehen sich leider wie ein roter Faden durch > die Geschichte von Linux und RedHat. OT: Seit Sommer diesen Jahres fliegt ein Satellit im All, dessen Nutzlast-SW wurde mit einem GCC-3.7 (oder 3.9 weiß nicht mehr genau) gebaut. :)) Nee, die SW wurde nicht schon vor 20 Jahren entwickelt sondern in den letzten Jahren.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.