Thema: Bochs Debugmodus unter Linux

[scales of justice]

wie startet man denn unter Linux den Debugmodus von Bochs?
muss ich Bochs dafür selbst kompilieren?
(so stehts zumindest in der Anleitung von Bochs)

wenn ja, hat vielleicht jemand ne kompilierte Version die auf SuSE läuft?
(.deb kann man Notfalls auch mit Alien in ein .rpm umwandeln)

[Legend]

Gibts nicht bochs_dbg?

[scales of justice]

nein, deswegen frag ich ja

[hannibal]

Bochs sources runterladen und mit debug Features kompilieren.

Lg, Alex

[scales of justice]

wenn ja, hat vielleicht jemand ne kompilierte Version die auf SuSE läuft?
(.deb kann man Notfalls auch mit Alien in ein .rpm umwandeln)

[kevin]

Warum baust du sie dir nicht einfach selbst?

[Legend]

Also ich muss sagen, "einfach" und "selber bauen" ist eine Kombination die nur mit Glück funktioniert. Bestes Beispiel waren C++ Programme und der Wechsel von Gcc, ich glaub 3.3, auf 3.4 und die total veränderte Templatebehandlung.

Und schon an anderen Stellen gab selber kompilieren schon mehr als genug Probleme und ich möchte eigentlich nicht unnötigerweise in mir fremden Quellcode rumprobieren - aber bei Linux war das jedes mal irgendwann nötig.

[scales of justice]

weil ich noch ziemlich wenig Ahnung hab wie das geht,
ich hab schon mehrere Programme versucht zu kompilieren, aber bis jetzt mit mageren Ergebnissen

[kevin]

Also ich muss sagen, "einfach" und "selber bauen" ist eine Kombination die nur mit Glück funktioniert. Bestes Beispiel waren C++ Programme und der Wechsel von Gcc, ich glaub 3.3, auf 3.4 und die total veränderte Templatebehandlung.

Ganz so extrem würde ich das nicht sagen, aber grundsätzlich hast du recht - nicht immer geht alles problemlos. Nur glaube ich, daß eine .deb per alien installieren sicher auch nicht in 100% der Fälle gutgeht...

[Legend]

Ganz so extrem würde ich das nicht sagen, aber grundsätzlich hast du recht - nicht immer geht alles problemlos. Nur glaube ich, daß eine .deb per alien installieren sicher auch nicht in 100% der Fälle gutgeht...

Das stimmt wohl auch. Abgesehen von den Referenzen in Bibliothek die so ein installiertes Bochs nachher möglicherweise gar nicht findet. Oder man könnte sich ja praktisch alles doppelt installieren, einmal normal, und einmal für Bochs, ...

[hannibal]

Code: [Auswählen]


wget http://switch.dl.sourceforge.net/sourceforge/bochs/bochs-2.2.6.tar.gz
tar -xvzf bochs-2.2.6.tar.gz

2. Terminal aufmachen und ins bochs-2.2.6 Verzeichnis wechseln, dann das hier ausfuehren:

Code: [Auswählen]


./configure --help | less

Das ist eine Liste aller Moeglichkeiten es zu kompilieren (configure bastelt dir das Makefile).

So, nachdem du dich entschieden hast wie du ihn kompilierst einfach:

Code: [Auswählen]


./configure --alle --deine --argumente --hier --usw --und --sofort
make
make install


Noch als kleine Hilfestellung bzw Hinweis :
http://bochs.sourceforge.net/cgi-bin/topper.pl?name=New+Bochs+Documentation&url=http://bochs.sourceforge.net/doc/docbook/user/index.html


Viola! \o/

Lg, Alex

[Legend]

Genau, der Weg den ich in einen OS das ich schreiben würde NICHT als Ausweg akzeptieren würde.

[kevin]

Zum Glück kann ich mir als Benutzer aber noch selbst aussuchen, welche Programme ich laufen lasse und welche nicht. Oder was meinst du mit diesem Weg?

Ansonsten würde ich übrigens noch empfehlen, nicht direkt "make install" zu machen, sondern wenigstens checkinstall zu benutzen, damit das auch in der Paketdatenbank mit drin ist.

[Legend]

Sourcen compilieren nur um ein Programm auf einem einzigem Rechner zu installieren.

[kevin]

Das sag mir mal das Patentrezept, wie man sowas vermeidet. Oder meinst du, daß Benutzer auf deinem OS dann eben kein Bochs wollen, weil das Kompilieren nicht in deine Philosophie paßt?

[Legend]

Ne, das der Autor von Bochs ein funktionsfähiges Binary bereit stellen kann ist eine Vorraussetzung die für mein OS dann hätte. Bei Windows geht das ja auch - bei Linux hingegen nicht, da kannste höchstens für ein paar Distros selber was machen aber für alle, völlig unmöglich. Ausser du kompilierst statisch.

Nur sind Installer bei der Linuxcommunity recht unbeliebt, und zwei echte Gründe habe ich gefunden:

1. Installer schleppen häufig Dinge mit sich rum die Anwendungen dann doch teilen (z.B. VB-Runtimes ) Statisch gelinkte Binaries haben das selbe Problem.
2. Unter Windows gibt es kein Kommando um mal eben alles zu updaten (wie gut das in jeder Situation ist, sei mal dahingestellt)

Tja, wie kombiniert man beides?

Also mein Ansatz ist bislang - es gibt nur ein Repository für das OS. Ein Fork ist immer ein Problem wenn man solche Probleme wie ich sie im Visier habe vermeiden will.

Desweiteren muss das ganze etwas verteilter sein. Eine Idee wäre z.B. das jeder Autor sein eigenes kleines Repository hat auf seiner Webseite und Abhängikeiten repository übergreifend sein können. Also wenn ich von Entwickler A mir ein Package ziehen, doppelt draufklicken in der GUI startet dann automatisch den grafischen Packagemanager der das Ding installiert und die Abhängigkeiten aus den Repositories von den Entwicklern B und C zieht. Dann hätten wir ein grosses, verteiltes Repository. Keine zueinander Distribution wo ich in Distribution A Programm B finde was ich lieber mit Distribution C benutzen würde.

Das grösste Problem ist dabei nur, was passiert wenn Entwickler B seine Seite dichtmacht, hmm. Jedem Package sollte man wohl eine eindeutige ID zuweisen und ein BitTorrent-ähnliches Netzwerk als Ausweichmöglichkeit wäre wohl nicht verkehrt.

Dann kann ich auch meinem Packagemanager sagen, update mal alle Programme, und er zieht sich alles aus den Repositories selber, ich muss natürlich jedes installierte Packet seine Herkunft speichern lassen.

Apropos Packagemanager, das ganze funktioniert nur richtig wenn es genau 1 Format gibt.

Das ganze ist natürlich komplizierter als das was bislang gemacht wird, aber was bislang gemacht wird erfüllt nun mal nicht meine Anforderungen, ich finde so wie es bislang eingesetzt wird Package Managment ehrlich gesagt eher hinderlich als förderlich.

Bei FreeBSD wäre es wohl auch Möglich Binaries anzubieten, aber damit alles schön automatisch abläuft muss man die z.B. auf die FTP Server von denen kriegen usw. Da ist also auch noch Potential es besser zu machen.

Ich habe mal gehört das man auch bei apt-get oder ähnlichem verschiedene Repositories nebeneinander benutzen kann, aber das ist im Moment eher als schmückendes Beiwerk eingesetzt und da diese Repositories auf Debian und verwandte Distros beschränkt sind für das Gesamtbild wertlos.

So könnte man die Vorteile von Installern (Finden, Ziehen, Installieren, Läuft im Vergleich zu Finden, Nachgucken ob es in der Distro ist, wenn ja gut, wenn nicht extrem beschissen) und Packages (Typischerweise kleiner, besser zu updaten) vereinen.

[kevin]

Ne, das der Autor von Bochs ein funktionsfähiges Binary bereit stellen kann ist eine Vorraussetzung die für mein OS dann hätte. Bei Windows geht das ja auch - bei Linux hingegen nicht, da kannste höchstens für ein paar Distros selber was machen aber für alle, völlig unmöglich. Ausser du kompilierst statisch.

Naja, was wird denn unter Windows anderes gemacht? Entweder statisch kompilieren oder die passenden DLLs gleich mitliefern. Dasselbe kannst du natürlich unter Linux auch machen - nur ist es dort eben üblicher, eine Bibliothek nicht hundertmal, sondern genau einmal installiert zu haben. (Was nicht heißt, daß es teilweise nicht auch anders gemacht wird, wenn eine bestimmte Bibliothek oft Probleme macht)

1. Installer schleppen häufig Dinge mit sich rum die Anwendungen dann doch teilen (z.B. VB-Runtimes ) Statisch gelinkte Binaries haben das selbe Problem.
2. Unter Windows gibt es kein Kommando um mal eben alles zu updaten (wie gut das in jeder Situation ist, sei mal dahingestellt)

Jepp, dem kann ich soweit zustimmen und würde außerdem noch hinzufügen:
3. Installer funktionieren meistens ganz gut, bei Uninstallern sieht es schon wieder ganz anders aus. Und ein Paketmanager macht das einfach sauber.

Also mein Ansatz ist bislang - es gibt nur ein Repository für das OS. Ein Fork ist immer ein Problem wenn man solche Probleme wie ich sie im Visier habe vermeiden will.

Was praktisch bedeutet, daß es eine zentrale Instanz gibt, die sagt, was es gibt und was nicht. Sowas hat sich zum Glück noch nicht einmal Microsoft getraut. Und wenn man sich mal vorstellt, daß diese eine zentrale Instanz ausfällt, dann ist es sowieso vorbei.

Aber grundsätzlich ist das natürlich schon eine Strategie, wie man es sich einfach machen kann. Siehe Apple, die nur eine sehr begrenze Hardwareauswahl unterstützen müssen, weil es etwas anderes als die Standardauswahl eben nicht gibt.

Desweiteren muss das ganze etwas verteilter sein. Eine Idee wäre z.B. das jeder Autor sein eigenes kleines Repository hat auf seiner Webseite und Abhängikeiten repository übergreifend sein können. Also wenn ich von Entwickler A mir ein Package ziehen, doppelt draufklicken in der GUI startet dann automatisch den grafischen Packagemanager der das Ding installiert und die Abhängigkeiten aus den Repositories von den Entwicklern B und C zieht. Dann hätten wir ein grosses, verteiltes Repository.

Falls du es nicht bemerkt hast: Du beschreibst genau die Realität unter Linux. Das Problem bei der Überlegung: Der Autor muß erstmal ein Repository mit den Binärpaketen bereitstellen. Und das geht eben an der Realität vorbei, besonders wenn man das Paket mit speziellen Optionen (also z.B. Bochs mit Debug) kompiliert haben möchte.

[Legend]

Was praktisch bedeutet, daß es eine zentrale Instanz gibt, die sagt, was es gibt und was nicht. Sowas hat sich zum Glück noch nicht einmal Microsoft getraut. Und wenn man sich mal vorstellt, daß diese eine zentrale Instanz ausfällt, dann ist es sowieso vorbei.

Jeder einzelne Linux-Distributor traut sich sowas für seine Distribution.

Aber grundsätzlich ist das natürlich schon eine Strategie, wie man es sich einfach machen kann. Siehe Apple, die nur eine sehr begrenze Hardwareauswahl unterstützen müssen, weil es etwas anderes als die Standardauswahl eben nicht gibt.

Jo, und bei Linuxdistributionen kann ich entweder das was schon in Packages verpackt wurde nehmen oder auf doch nicht immer unproblematische (und speziell für das kompilieren, zu zeitaufwändige) Umwege auswechen.

Falls du es nicht bemerkt hast: Du beschreibst genau die Realität unter Linux. Das Problem bei der Überlegung: Der Autor muß erstmal ein Repository mit den Binärpaketen bereitstellen. Und das geht eben an der Realität vorbei, besonders wenn man das Paket mit speziellen Optionen (also z.B. Bochs mit Debug) kompiliert haben möchte.

Nein, unter Linux habe ich nicht ein verteiltes Repository sondern viele verschiedene, zueinander binär-inkompatible Repositories. Daher kommen ja solche Probleme, denn als Autor kann ich nicht sinnvollerweise für jedes Repository ein Binary zur Verfügung stellen. Wenn ich das probieren würde, würde ich ja mehr für verschiedene Distros kompilieren als selber zu programmieren.

Das der Autor selber Binaries zur Verfügung stellen kann ist genau das warum man unter Windows keine Probleme hat wenn man unbekannte Software XYZ ausprobieren will. Vorrausgesetzt XYZ ist so unbekannt das meine Linuxdistribution die Linuxvariante XYZ nicht im Angebot hat. Windows muss gar nicht die Software selber so mitliefern wie eine Linuxdistribution.

Und btw - welcher Volltrottel (sorry) hat bei der Distro von scales denn bitte Bochs ohne den Debugger übersetzt oder nicht als Extrapacket bereitgestellt (ich denke mal er hat diese Option vor dem Thread hier überprüft)? Ich hab auch schon Squids gesehen die so kompiliert waren das man über sie keine Foren wie dieses hier benutzen konnte.
Wenn man solche unsinnigen Optionen entfernen würde, dann gäbe es gar nicht so viel Auswahl Programme verschiedene zu kompilieren.

[kevin]

Was praktisch bedeutet, daß es eine zentrale Instanz gibt, die sagt, was es gibt und was nicht. Sowas hat sich zum Glück noch nicht einmal Microsoft getraut. Und wenn man sich mal vorstellt, daß diese eine zentrale Instanz ausfällt, dann ist es sowieso vorbei.

Jeder einzelne Linux-Distributor traut sich sowas für seine Distribution.

Nein, da gibt es nicht diese eine zentrale Instanz. Oder warum habe ich in meiner sources.list neben den zwei offiziellen Debian-Repositories noch 18 andere Einträge stehen? Und wenn ich will, kann ich die Software immer noch aus anderen Quellen und auf anderen Wegen installieren - selber Kompilieren, Installer, Klik und was es sonst noch so gibt. Gerade kommerzielle Software hat unter Linux Installer (leider, Pakete wäre schöner, aber wie gesagt aufwendig).

Aber was hier entscheidend ist: Ich kann Software auch aus anderen Quellen installieren. Du willst es beschränken, daß es nur noch die eine Quelle gibt (und wenn ich das falsch verstanden habe, sind wir doch wieder bei Linux).

Jo, und bei Linuxdistributionen kann ich entweder das was schon in Packages verpackt wurde nehmen oder auf doch nicht immer unproblematische (und speziell für das kompilieren, zu zeitaufwändige) Umwege auswechen.

Richtig. Was bei deinem OS nicht anders sein wird - denn selbst wenn es sourcekompatibel wäre, würde nicht jedes Projekt seine Software in allen Varianten für dich bereitstellen. Das mußt du entweder selbst machen oder du hast es eben nicht als Paket. Letzteres wird aber nicht dazu führen, daß die Benutzer die Software nicht benutzen wollen.

Nein, unter Linux habe ich nicht ein verteiltes Repository sondern viele verschiedene, zueinander binär-inkompatible Repositories. Daher kommen ja solche Probleme, denn als Autor kann ich nicht sinnvollerweise für jedes Repository ein Binary zur Verfügung stellen. Wenn ich das probieren würde, würde ich ja mehr für verschiedene Distros kompilieren als selber zu programmieren.

Erstmal wieder der Verweis auf meine sources.list. Es gibt durchaus kompatible Repositories - meine genannten 18 Einträge bauen natürlich alle auf den offiziellen Debian-Repositories auf. Das größte Problem zwischen den verschiedenen Distributionen dürften nicht mal die inkompatiblen Programme sein, sondern die unterschiedlichen Paketnamen und solches Zeug.

Das der Autor selber Binaries zur Verfügung stellen kann ist genau das warum man unter Windows keine Probleme hat wenn man unbekannte Software XYZ ausprobieren will. Vorrausgesetzt XYZ ist so unbekannt das meine Linuxdistribution die Linuxvariante XYZ nicht im Angebot hat. Windows muss gar nicht die Software selber so mitliefern wie eine Linuxdistribution.

Du hast wirklich noch nie gesehen, daß es für Linux durchaus Programme gibt, die nur in Binärform vertrieben werden? Im Vergleich zum Paketmanager ist das natürlich unbequemer, aber das heißt nicht, daß es sowas nicht gibt. Und funktionieren tut es meistens auch - und zwar im allgemeinen auf die Windows-Methode: Statisch kompilieren oder alle Bibliotheken selbst mitbringen.

Und btw - welcher Volltrottel (sorry) hat bei der Distro von scales denn bitte Bochs ohne den Debugger übersetzt oder nicht als Extrapacket bereitgestellt (ich denke mal er hat diese Option vor dem Thread hier überprüft)?

Vielleicht, weil man davon ausgeht, daß Bochs in erster Linie zum Benutzen von Betriebssystemen und nicht zum Entwickeln benutzt wird? Ich war es jedenfalls nicht.

[Termite]

Nabend

mich beschleicht das Gefühl, das hier jemand mit "Linux" eigentlich eine Linux Distribution meitn. Ein RedHead Linux , ein Suse Linux, Gentoo oder Debian Linux basiert zwar alle auf dem Linux Kern von Linus. Aber das angebot drumm herum, der Aufbau, die Versorgung mit zusätzlicher Software, kann ggf sehr unterschiedlich aussehen. Es harmonisiert sich mitlerweile, da gerade die suse unsitten von früher weniger werden, config fils an orten zu speichern, wo sie laut Standart gar nicht hingehören, ...

Debian z.B. unterstützt sowol seine eigenen deb pakete als auch die RPM (RedheadPackatManager) Dateien. Das RPMs sich ggf auf einem System nicht sauber installieren lässt, hängt meist mit problemen oder Standardabweichungen der distry zusammen als damit das der Produzent des RPMs misst gebaut hat. ( wobei das auch sein könnte )

Es ist änlich wie der verglich, wieso ein Programm für Windows XP nicht auf einem Windows 95 oder NT4 läuft. ist doch auch alles Windows oder etwa nicht. Bei einem grossteil der Programme geht das auch ohne probleme. nur bei manchen kann es probleme machen. Nur wieso? es ist doch alles Windows?

gruss