Lieber Sascha,
ich Danke Dir für den schnellen Fix.
Um schreiben oder kommentieren zu können, benötigst du ein Benutzerkonto.
Du hast schon ein Benutzerkonto? Melde dich hier hier an.
Jetzt anmeldenHier kannst du ein neues Benutzerkonto erstellen.
Neues Benutzerkonto erstellenLieber Sascha,
ich Danke Dir für den schnellen Fix.
Sorry, aber leider lädt er auch heute nur die 0.88er Version herunter.
Da scheint also leider immer noch etwas nicht ordnungsgemäß zu funktionieren.
Bist Du bitte so nett und schaust Dir das noch einmal an? Danke Dir im Voraus.
bei mir lädt er schon länger die OC 0.8.9
bei mir lädt er schon länger die OC 0.8.9
https://update.kextupdater.de/opencorenightly/version.html
Hm, ja Mist. Ein Fehler im Script war das nicht. Ich kriege OC nicht mehr kompiliert. Weder unter macOS noch Linux. Und eine Quelle für fertige Nightlybuilds wo ich mich "bedienen" könnte habe ich auch noch keine gefunden. Clover übrigens genau das selbe. Kompiliert auch nicht mehr durch. An zu altem System kanns nicht liegen, da ich in der VM Ventura laufen habe wo der immer das ganze Zeug zusammenklöppelt.
Das wirft OC mir unter Linux aus. Vllt. weiss ja jemand rat. Liegt scheinbar an dem clang Argument.
clang: error: unknown argument: '-mstack-protector-guard=global'
make: *** [GNUmakefile:326: /root/test/opencorepkg/UDK/Build/OpenCorePkg/DEBUG_CLANGPDB/X64/OpenCorePkg/Library/OcCompilertrinsicsLib/OcCompilertrinsicsLib/OUTPUT/OcCompilertrinsicsLib.obj] Fehler 1
build.py...
: error 7000: Failed to execute command
make tbuild [/root/test/opencorepkg/UDK/Build/OpenCorePkg/DEBUG_CLANGPDB/X64/OpenCorePkg/Library/OcCompilertrinsicsLib/OcCompilertrinsicsLib]
build.py...
: error 7000: Failed to execute command
make tbuild [/root/test/opencorepkg/UDK/Build/OpenCorePkg/DEBUG_CLANGPDB/X64/OpenCorePkg/Library/OcTimerLib/OcTimerLib]
build.py...
: error 7000: Failed to execute command
make tbuild [/root/test/opencorepkg/UDK/Build/OpenCorePkg/DEBUG_CLANGPDB/X64/MdePkg/Library/BaseReportStatusCodeLibNull/BaseReportStatusCodeLibNull]
build.py...
: error 7000: Failed to execute command
make tbuild [/root/test/opencorepkg/UDK/Build/OpenCorePkg/DEBUG_CLANGPDB/X64/OpenCorePkg/Library/OcDriverEntryPoint/UefiDriverEntryPoint]
build.py...
: error 7000: Failed to execute command
make tbuild [/root/test/opencorepkg/UDK/Build/OpenCorePkg/DEBUG_CLANGPDB/X64/MdeModulePkg/Library/BaseSerialPortLib16550/BaseSerialPortLib16550]
build.py...
: error F002: Failed to build module
/root/test/opencorepkg/UDK/OpenCorePkg/Library/OcCompilertrinsicsLib/OcCompilertrinsicsLib.inf [X64, CLANGPDB, DEBUG]
- Failed -
Build end time: 08:30:57, Feb.21 2023
Build total time: 00:00:06
Quelle für fertige Nightlybuilds wo ich mich "bedienen" könnte habe ich auch noch keine gefunden
Echt jetzt?
https://dortania.github.io/bui…=OpenCorePkg&viewall=true
Ich weiss. Das sind aber keine "echten" Nightlybuilds. Der letzt Build in der Repo ist bereits 3 Tage alt.
Letztlich wenn ich keinen anderen Weg finde (habe bei Insanely gerade mal nen Thread aufgemacht) werde ich dann wohl tats. darauf zurückgreifen müssen. Besser als nix.
Bei mtoc hab ich einfach mit "y" bestätigt das er die neue Version installieren soll. Daran kanns bei mir nicht liegen.
Ich vermute im Build-Script nen Bug. Mal sehen was auf Insanely geschrieben wird.
https://www.insanelymac.com/fo…er-linux-debian-11-fails/
EDIT:
Wobei ich gerade sehe .... der letzte commit war auch vor 3 Tagen. Das heisst die compilen das da nur dann wenn sich auch was ändert. So gesehen dann ja doch eigtl. ein aktuelles Nightlybuild.
Ich stelle gerade fest, dass die in ihrer Repo ein paar nette Pythonscripte haben womit man sich ganz komfortabel aus deren Build-Pool bedienen kann.
https://github.com/dortania/build-repo
Werde dann wohl mal mein "Repo-Abgras-Script" anpassen. Dann brauch ich mir die Kexte nicht mehr aus zig Repos zusammen suchen. Praktisch.
Alles anzeigenHallo,
der KU lädt bei mir immer nur die 0.88 nightly runter.
Als RELEASE zieht er korrekt die 0.89, aber nightly scheint nicht die neueste Version zu laden.
Kann das jemand bestätigen und kann das ggf. bitte gefixed werden? Danke im Voraus.
Mit freundlichen Grüßen...
Mork vom Ork
Arkturus weil Du mit Deiner 0.8.9 von was anderen schreibst, als es dem Fragesteller ging
Sascha_77 die bauen doch alle mit dem build_oc.tool, von daher wird der Fehler ja nicht im Script selber liegen.
Habe es auch bei mir selber gerade mal probiert
Ja nur dann frage ich mich warum es weder unter macOS noch Linux bei mir klappt. Dependencies habe ich alle.
EDIT:
So "nightly" 0.9.0 von OC ist nun on.
Also build_oc.tool vom aktuellen SourceCode funktioniert wie immer ohne Probleme im Terminal und liefert am Ende die Binaries OpenCore-0.9.0-DEBUG und OpenCore-0.9.0-Release.
SourceCode Lilu, AppleALC und Co. mittels Xcode auch keine Probleme hier.
Keine besonderen Probleme erkennbar hier.
Hmm stimmt. Ich hab das jetzt mal auf meinem T590 durchlaufen lassen und da gehts.
Vllt. hat meiner VM Installation ja die Migrierung von Catalina nach Ventura nicht so ganz gepasst. Werde das mal frisch aufsetzen.
EDIT:
Habs jetzt hinbekommen, dass er unter Ubuntu compiled. Da fehlten noch 2 Deps. Dann kann ich mir zum. dafür die VM sparen.
und auch bei mir funktioniert es nun wieder korrekt. Danke, Danke, Danke...
schön, dass es jetzt doch geht
Auch wenn Du via PM gefragt hast, ich antworte mal hier, denn davon lebt ja ein Forum, dass es alle mitbekommen und Ihre Erkenntnisse dadurch erweitern können.
Zu Deinen Fragen:
Auf meinem MacMini M1 (Ventura 13.3 DP1), wo ich diese Sache gestern im Terminal ohne Probleme gebaut habe, hat "/usr/local/bin/mtoc --version" folgendes ausgegeben: 1.0.2
Ich hoffe, es hilft Dir als Antwort.
Zitat: "...Nigthly, die am Ende keine sind weil es ja mehr nach Commit geht..."
Man muss hier schon unterscheiden. Nicht jedes Commit wird sofort in den main-SourceCode übernommen. Einige werden in anderen Branches getestet, andere wieder in externen Fork's, ist von den Entwicklern auch nicht anders gewollt und ist auch gut so, wie ich finde.
Wer sich auskennt, kann natürlich auch diese selbst bauen.
Je nach Entwicklung ist das Bauen der Nightly Build's anders geregelt, manche bauen täglich eine Nightly, manche alle drei Tage, andere wieder, wenn's tatsächlich Änderungen am main-SourceCode gegeben hat.
Im Beispiel OCLP ist das letzte vom 10.02. und selbst wenn man selbst baut vom main gibt's auch keine Änderung.
Es ist auch oft von den Entwicklern gar nicht gewollt, dass jeder Hans und Franz sofort auf diese Vorab-Versionen geht. Gut so.
Hier sind viele User, die sich wirklich auskennen und die können solche Dinge natürlich testen, mache ich ja auch, aber ich sehe hier oft folgendes Problem, gerade bei dieser Art Tool-App's, in Bezug auf unerfahrene User.
Sobald ein neues Release rauskommt (was die Entwickler ja nicht ungeprüft rausgeben und welches auch seinen Sinn hat), kommt hier irgendwo sofort die Frage "hat jemand schon die neue Nigthly getestet" und unerfahrene User versuchen mit diesen Versionen Ihren ersten Hackintosh aufzusetzen, ohne jegliche Erfahrung.
Woher kommt dieser Zwang?
Wenn Apple mal wieder was gravierend ändert, wie gerade mit 13.3 DP1 und dem OLCP-Bereich für realMac's, dann ist diese Erwartungshaltung schon verständlich, aber im OC-Bereich, worum es hier ja geht, ist dies nicht unbedingt nötig.
Ich verwende z.B. auf meinem Lenovo-Lappi noch immer OC 0.8.5 mit allen zeitgleichen Releases AppleALC, Lilu, WEG und Co., auf Dualboot macOS 12.6.4 und 13.3 DP1 und es läuft noch immer ohne Probleme.
Prinzipiell sind Tools ja eine hilfreiche Sache, wie vielleicht auch dieses Tool hier, aber für viele unerfahrene User geht der Lernfaktor natürlich dadurch nach unten. Leicht gemacht ist ja nicht immer besser, wenn man die Sache auch mal irgendwann verstehen muss und sollte, wo genau diese ganzen Kext's oder OC-Versionen herkommen.
Natürlich hilft es vielen Nutzern, welche diese Erkenntnisse noch nicht ihr eigen nennen können, aber verstehen werden sie die Dinge dadurch dann auch nicht.
Vielleicht sollte Sascha_77 hier mal in sein Tool Hinweise einfügen, dass nicht jeder Wechsel auf Nightly-Versionen für jeden unerfahrenen User wirklich Sinn macht, sondern hierbei auf stabiles Release hinweisen, zumindest für unerfahrene User.
Ok, viel eigene Meinung hierbei, muss auch nicht alles richtig sein, denn Meinungen gehen ja bekanntlich ohnehin auseinander .
Ich persönlich mache alles händisch, teste dieses Tool aber rein aus Interesse trotzdem regelmäßig, auch wenn ich es nicht benötige.
Wenn Du im Master Branch baust, ist jeder Commit der dort ist auch enthalten.
Das hat doch mit den anderen Branches gar nichts zutun.