Forum: PC Hard- und Software Linux-Anwendung läuft nur unter bestimmten Distros, hackbar?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Christian S. (uhrenfreak)


Lesenswert?

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
von Hmmm (Gast)


Lesenswert?

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.

von Jack V. (jackv)


Lesenswert?

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.

von Karl Käfer (Gast)


Lesenswert?

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

von Christian S. (uhrenfreak)


Lesenswert?

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 ....

von Malte _. (malte) Benutzerseite


Lesenswert?

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.

von Max M. (Gast)


Lesenswert?

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.

von Decypher (Gast)


Lesenswert?

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....

von Marcus H. (mharnisch) Benutzerseite


Lesenswert?

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.

von HAAAAHAAAA (Gast)


Lesenswert?

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.

von Decypher (Gast)


Lesenswert?

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.

von ... (Gast)


Lesenswert?

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.

von Alexander S. (alesi)


Lesenswert?

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

von Hmmm (Gast)


Lesenswert?

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.

von Christian S. (uhrenfreak)


Lesenswert?

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
von Karl Käfer (Gast)


Lesenswert?

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.

von Karl Käfer (Gast)


Lesenswert?

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. ;-)

von Christian S. (uhrenfreak)


Lesenswert?

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.

von Hmmm2 (Gast)


Lesenswert?

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

von Christian S. (uhrenfreak)


Lesenswert?

> 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.

von Karl Käfer (Gast)


Lesenswert?

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. ;-)

von Karl Käfer (Gast)


Lesenswert?

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.

von Rolf R. (dankobum)


Lesenswert?

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?

von Christian S. (uhrenfreak)


Lesenswert?

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 .....

von Hmmm2 (Gast)


Lesenswert?

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.

von Le X. (lex_91)


Lesenswert?

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.

von Christoph db1uq K. (christoph_kessler)


Lesenswert?

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
von Schlaumaier (Gast)


Lesenswert?

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.

von MiWi (Gast)


Lesenswert?

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?

von Dolf (Gast)


Lesenswert?

Evtl. mal mit strace -f vorweg starten, mit etwas Glück erkannt man dann 
woran es hängt.

von Rolf M. (rmagnus)


Lesenswert?

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…

von Christian S. (uhrenfreak)


Lesenswert?

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

von Schlaumaier (Gast)


Lesenswert?

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.

von ... (Gast)


Lesenswert?

> 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

von Hmmm (Gast)


Lesenswert?

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.

von Rolf M. (rmagnus)


Lesenswert?

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.

von Löppt (Gast)


Lesenswert?

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“.

von Christian S. (uhrenfreak)


Lesenswert?

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.

von M$ (Gast)


Lesenswert?

> 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...

von Karl Käfer (Gast)


Lesenswert?

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.

von mIstA (Gast)


Lesenswert?

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.

von 900ss (900ss)


Lesenswert?

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
Bitte 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
Noch kein Account? Hier anmelden.