macports - gsmartcontrol auf powerbook G4 1.33GHz 12" Aluminium, 768 MB kompilieren, dauert Tage.

Diskutiere das Thema macports - gsmartcontrol auf powerbook G4 1.33GHz 12" Aluminium, 768 MB kompilieren, dauert Tage. im Forum Mac OS - Unix & Terminal.

  1. floogy

    floogy Thread Starter Mitglied

    Beiträge:
    105
    Zustimmungen:
    2
    Mitglied seit:
    01.04.2009
    Hallo,

    kann mir jemand sagen, ob das so zu erwarten ist? libgcc7 und libgcc6 brauchten jeweils 12-24h um kompiliert zu werden.

    Ich möchte gsmartcontrol auf einem powerbook G4 1.33GHz 12" Aluminium, 768 MB RAM kompilieren. Es ist Leopard 10.5.8, xcode 3.1.4 und macports 12.6.2 installiert.

    Vielleicht weiß auch jemand, was die größten »Brocken« dabei sind. Vielleicht wird es auch besser, wenn man nach gcc6 den Vorgang erneut startet, da der compiler schneller sein könnte?

    Die Platte hat ein paar fehlerhafte Sektoren. Wie kann ich herausfinden, ob es an diesen liegen könnte? Wahrscheinlich aber ist der RAM einfach zu knapp?

    Welche Alternative außer disk drill free gibt es noch für PPC Leopard?

    Kennt jemand ein Universal-Binary von gsmartcontrol für Leopard PPC?
     
  2. Roman78

    Roman78 Mitglied

    Beiträge:
    3.537
    Zustimmungen:
    1.582
    Mitglied seit:
    02.10.2006
    Also um smart auszulesen und zu testen? Da gibt es doch... öööhh wie heißt das noch... Muss ich zuhause mal nachsehen, jedenfalls habe ich da software für PPC.
     
  3. Olivetti

    Olivetti Mitglied

    Beiträge:
    11.360
    Zustimmungen:
    3.851
    Mitglied seit:
    09.12.2005
    für das bisschen G in gsmartcontrol würde ich keinen compiler anwerfen. in jedem dieser smart-gui-tools steckt smartctl, mit dem du alles auslesen kannst. AFAIR gab es vom smartreporter immer eine UB.
     
  4. oneOeight

    oneOeight Mitglied

    Beiträge:
    53.717
    Zustimmungen:
    6.630
    Mitglied seit:
    23.11.2004
    warum kompilierst du nicht einfach nur die smartmontools?
    gsmartcontrol ist halt gtk und da braucht es wohl so lange beim kompilieren wegen den ganzen abhängigkeiten.

    das abfragen der SMART werte ist auch nicht so schwierig:
    smartctl -a /dev/disk0
     
  5. floogy

    floogy Thread Starter Mitglied

    Beiträge:
    105
    Zustimmungen:
    2
    Mitglied seit:
    01.04.2009
    Danke für den Hinweis. Bei Smartreporter 2.7.3 sind wohl die Smartmontools dabei. https://www.corecode.io/smartreporter_lite/index.html
    https://web.archive.org/web/20120323131230/https://www.corecode.at/smartreporter/


    Mich würde trotzdem interessieren, worauf ihr es zurückführt, dass eine einzelne Library wie libgcc6 schon fast einen Tag benötigt, um zu kompilieren. Es sind ja etliche weitere binaries durch die Abhängigkeiten zu kompilieren (ja, wegen gtk, xorg und weiteres).

    smartctl kenne ich von linux und FreeBSD.
     
  6. oneOeight

    oneOeight Mitglied

    Beiträge:
    53.717
    Zustimmungen:
    6.630
    Mitglied seit:
    23.11.2004
    gcc ist halt recht umfangreich, die CPU ist nicht die schnellste, die platte lahm.
    das dauert halt, selbst auf meinen dual g4 zieht sich das ewig.
     
  7. Kaito

    Kaito Mitglied

    Beiträge:
    6.741
    Zustimmungen:
    1.570
    Mitglied seit:
    31.12.2005
    Ich weiß noch als ich gcc auf einem Intel Core2(?)Duo MBP kompilieren durfte, da ich gnat brauchte. Configure + kompilieren hab ich nachts durchlaufen lassen (müssen), bis es irgendwann so durch lief wie gewünscht...
     
  8. floogy

    floogy Thread Starter Mitglied

    Beiträge:
    105
    Zustimmungen:
    2
    Mitglied seit:
    01.04.2009
    Ich habe halt auch schon mal auf einem Pentium 3 667MHz mit 2GB RAM unter Linux den Kernel gebaut. Das lief afair schneller. Mag aber sein, dass mir die Erinnerung einen Streich spielt. Mag mit mehr RAM und SWAP auf einer HDD ohne >78 reallocated blocks besser laufen. Obwohl: Die CPU läuft ja auf 100% Auslastung ...

    Werde die defekte HDD (Smart Status ist zwar OK, aber wenn ich ein ppc Linux oder BSD von cdrom starte, gibt es jede Menge DMA Fehler und der Kernel versucht ständig Leseversuche die scheitern) durch eine SSD austauschen und vielleicht auch mehr RAM einbauen.

    Jedenfalls Danke an alle!
     
  9. Olivetti

    Olivetti Mitglied

    Beiträge:
    11.360
    Zustimmungen:
    3.851
    Mitglied seit:
    09.12.2005
    eine SSD bringt diesbzgl. gar nichts (ansonsten natürlich schon).
    ich habe auf einem alten macbook core2duo u.a. brew als pkg-manager und mich graust's jedesmal, wenn rust fällig ist.
     
  10. floogy

    floogy Thread Starter Mitglied

    Beiträge:
    105
    Zustimmungen:
    2
    Mitglied seit:
    01.04.2009
    Ich wollte die Platte per smart im Auge behalten, bis ich dazu komme sie durch eine SSD zu tauschen. Das mache ich nun mit SMARTreporter-lite. disk drill finde ich etwas "kompliziert", obwohl die Temperaturanzeige praktisch ist.
     
  11. oneOeight

    oneOeight Mitglied

    Beiträge:
    53.717
    Zustimmungen:
    6.630
    Mitglied seit:
    23.11.2004
    wenn du schon schon über 78 reallocated hast und bestimmt noch einige pending, was willst da noch im auge behalten.
    tausch die platte.
    auch wenn das vielleicht für ein wenig benutztes gerät auch eine teure investition ist.
     
  12. floogy

    floogy Thread Starter Mitglied

    Beiträge:
    105
    Zustimmungen:
    2
    Mitglied seit:
    01.04.2009
    Das ist, wie gesagt auch geplant, per Sata2ide Adapter und SSD. Ich dachte ja auch ursprünglich, dass sei eine Sache von Minuten bis Stunden. Ich hatte merkwürdigerweise SMARTreporter vorher nicht für PPC gefunden.

    Hier ein dmesg-Ausschnitt zum Start von lubuntu, als die Platte noch einigermaßen okay war, und als es schon massiv Probleme gab. Mac Os X Leopard started aber einigermaßen zügig, ohne diese Probleme, wohl weil bei der HFS+ Formattierung diese badsectors berücksichtigt wurden(?).

    https://pastebin.com/qDehgQ6V


    Mi 4 Mär 2020 13:32:08 CET
    13:32 up 1 day, 10 hrs, 3 users, load averages: 1,13 1,10 1,08
     
  13. oneOeight

    oneOeight Mitglied

    Beiträge:
    53.717
    Zustimmungen:
    6.630
    Mitglied seit:
    23.11.2004
    das liegt einfach in anderen bereichen, HFS+ hat da kein spezielles bad block mapping so weit ich weiß.
    wenn du aber schon I/O error bekommst, dann solltest du deine pläne mal beschleunigen, falls du das gerät in kürze öfters verwenden willst.
     
  14. Roman78

    Roman78 Mitglied

    Beiträge:
    3.537
    Zustimmungen:
    1.582
    Mitglied seit:
    02.10.2006
    Ah, ich habe mal geschaut und was gefunden... DiskWarrior und Norton Utilities hat Festplatten tools.
     
  15. floogy

    floogy Thread Starter Mitglied

    Beiträge:
    105
    Zustimmungen:
    2
    Mitglied seit:
    01.04.2009
    Norton Utilities dachte ich auch. Die Norton System Works 3.0.1 gingen aber nicht, vielleicht laufen die nur unter Tiger 10.4.
    Vielleicht gut, dass die gar nicht erst liefen: https://www.cnet.com/news/warning-d...r-similar-utilities-on-mac-os-x-10-5-leopard/

    Danke auch für den Tipp mit DiskWarrior. Werde ich mir mal ansehen.

    Gerade wird gcc7 kompiliert. Bin mal gespannt wie es nach dem Brocken weiter geht. Die Programme und Bibliotheken dazwischen gingen relativ schnell.

    Ich werde aber morgen mal nach einer SSD und den Adapter schauen. Es sind keine persönlichen Daten auf der Festplatte. Ich bin da nur am Testen und ausprobieren.

    Solche Fehler kamen nur bei den Live- oder Recovery Linux CDs etc.

    Leopard hat sich nie über die Platte beschwert. Kann also gut sein, dass da zufällig gar nicht die Blöcke genutzt werden. DiskUtil allerdings scheitert an dem Check und der Reparatur (bzw. es bleiben Fehler nach erfolgreicher Reparatur: Loop).
     
Die Seite wird geladen...
  1. Diese Seite verwendet Cookies. Wenn du dich weiterhin auf dieser Seite weitersurfst, akzeptierst du unseren Einsatz von Cookies. Akzeptieren Weitere Informationen...