Binary compatibility und make.conf

gadean

Well-Known Member
Hi,
aktuell habe ich drei verschiedene poudriere Systeme (fragt nicht), würde die aber gerne auf ein System reduzieren.
System 1: 13.0-RELEASE + Intel CPU
System 2: 13.1-RELEASE + AMD CPU
System 3: 13.1-RELEASE + Intel CPU

Nun bräuchte ich etwas Hilfe von euch, beziehungsweise würde gerne wissen ob meine Infos stimmen.

1. Binary packages sind im Prinzip Minor kompatible (Beispiel. 13.0 und 13.1)
Ausnahme:
Pakete mit externen Modulen für den Kernel (Beispiel. virtualbox)
Abhängigkeiten älter als die wo kompiliert wurde

2. Auf einem 13.1 Host kann ohne Probleme eine 13.0 Jail laufen, umgekehrt aber nicht

3. CPU Flags in der make.conf würden zu Problemen führen, wenn die Pakete auf unterschiedlichen CPUs laufen soll

Wenn ich jetzt auf einer Machine (13.1), poudriere laufen lasse mit zwei "Build Jails" (1x 13.0, 1x 13.1) und folgender make.conf:
Code:
DEFAULT_VERSIONS+= ruby=2.7
OPTIONS_UNSET=X11 XCB CUPS NLS EXAMPLES
LICENSES_ACCEPTED=PDFlib

# questionable flags
OPTIMIZED_CFLAGS="YES"
BUILD_OPTIMIZED="YES"
WITH_OPTIMIZED_CFLAGS="YES"

Würden die Pakete dann auf unterschiedlichen Generationen von Intel und AMD CPUs funktionieren?
Sind die "OPTIMIZED" Flags überhaupt noch empfohlen?
 

Yamagi

Possessed With Psi Powers
Teammitglied
Erstmal vorweg: Grundsätzlich ist FreeBSD abwärts-, aber wie die meisten Systeme nicht aufwärtskompatibel. Was irgendwo logisch ist, schließlich kann man schlecht in die Zukunft schauen. Pakete oder insgesamt Binaries laufen daher auf neueren Systemen, aber nicht unbedingt auf älteren Systemen. Innerhalb eines Releasezweigs sollte es so gehen, über Releasezweige hinweg braucht man (eventuell) eines der misc/compat*-Pakete, um die älteren Bibiliotheken des Basissystem zur Verfügung zu stellen.

1. Binary packages sind im Prinzip Minor kompatible (Beispiel. 13.0 und 13.1)
Ausnahme:
Pakete mit externen Modulen für den Kernel (Beispiel. virtualbox)
Abhängigkeiten älter als die wo kompiliert wurde
Genau. Ältere Pakete auf neuerem System geht. Sobald Kernelmodule ins Spiel kommen, sollte das Paket auf der Version gebaut sein, wo es auch genutzt werden soll. Sonst kann es Ärger wie nicht ladende, nicht funktionierende oder das System crashende Module geben. Das ist unschön. :)

2. Auf einem 13.1 Host kann ohne Probleme eine 13.0 Jail laufen, umgekehrt aber nicht
Nochmal genau. ;) Älteres Jail auf neueren Host geht. Wobei bei unterschiedlichen Hauptversionen alle Tools, die mit dem Kernel kommunizieren müssen, Probleme machen können. Die Klassiker sind Tools wie top, ps oder auch ifconfig.

3. CPU Flags in der make.conf würden zu Problemen führen, wenn die Pakete auf unterschiedlichen CPUs laufen soll
Zumindest in dem Moment, in dem das Buildsystem des Ports aufgrund der veränderten CFLAGS CPU-Features aufgreift, die von der CPU im Buildsystem, aber nicht von der CPU im ausführenden System unterstützt werden. In den letzten Jahren haben sich AMD und Intel weitgehend angenähert und auch Intel hat den Wildwuchs stark zurückgefahren. Die größere Baustelle bei modernen CPUs ist AVX512, was nur einige Intel-CPUs und bisher keine AMD-CPUs unterstützen. Aber andererseits gibt es auch kaum Software für AVX512.

Als CFLAGS-geschädigter Maintainer von meinem Quake II Projekt - Quake II darf nicht mit zu hohen Optimierungen gebaut werden und benötigt einige Spezialitäten wie Aliasing, denn die ganze Sache ist ziemlich äh "optimiert" oder weniger diplomatisch gesagt "90er Jahre Style defekt" und da wir mit allem, was vorhanden ist, kompatibel bleiben wollen auch nicht ohne weiteres zu reparieren - würde ich von angepassten CFLAGS abraten. Die 0,x% Vorteile, die es Durchschnitt bringt, sind den potentiellen Ärger nicht wert. Wenn, dann sollte man es auf Ports begrenzen, wo man um die Wirkung weiß.
 

gadean

Well-Known Member
Vielen lieben dank für die Infos und vor allem die Anmerkung zu den CFLAGS!
Denke ich werde es erst mal ohne CFLAGS probieren und falls nötig für den Datenbankserver aktivieren.
 

gadean

Well-Known Member
Kleines Update:
Ich bin bei einigen Ports über OPTIMIZED_CFLAGS gestolpert und wollte es mit OPTIONS_UNSET deaktivieren, was leider nicht funktionierte.
Nach weiterem testen bin ich auf OPTIONS_FILE_UNSET gestoßen - damit funktioniert es - jedoch ist mir der Unterschied zwischen beiden Parametern nicht klar und bin anscheinend zu doof dazu etwas zu finden.
 
Oben