rsync selbst kompilieren ohne overhead von homebrew

lisanet

Aktives Mitglied
Thread Starter
Registriert
05.12.2006
Beiträge
14.938
Reaktionspunkte
18.505
In einem Thread kürzlich kam das Thema eines updates von rsync auf. macOS liefert aufgrund der Bestimmungen der GPL 3 keine Software mit, die der GPL 3 unterleigen, so dass rsync in einer alten Version erscheint. Grundsätzlich ist das kein Problem. Wer, warum auch immer, aber eine aktuelle Version von rsync möchte, muss sich dann anders behelfen.

Recht einfach geht das im Grunde mit homebrfew. Allerdings nimmt man damit einen sehr großen overhead mit, nur um ein einzelnes binary zu aktualisieren.

Diesen overhead kann man sich sparen, indem man rsync selbst kompiliert. Da es nicht jederfraus Sache ist, das alles selbst zusammen zu bauen, habe ich ein script erstellt, welche alle nötigen Komponenten herunter lädet und rsync kompiliert. Am Ende habt ihr ein aktuelles rsync binary ohne den overhead von homebrew.

Das zwischenzeitlich fürs Kompilieren erstellte Verzeichnis könnt ihr einfach löschen. Ihr benötigt es nicht mehr.

Als Voraussetzung müsst ihr euch im Terminal bewegen können und sicherstellen, dass die command line tolls installiert sind. Falls diese noch nicht installiert sind, holt dies bitte nun nach und zwar mit

Code:
xcode-select --install

Nun legt eine neues Verzeichnis in eurem Homeverzeichnis an, hier im Beispiel nenne ich es "myrsync" (nennt es bitte nicht nur 'rsync'). Dann nehmt ihr das folgende Script via copy&paste und legt es als reine Textdatei in dieses Verzeichnis. Nehmt dazu bitte sowas wie BBEdit und nicht TextEdit.app. Dieses script nennt ihr dann "make_rsyc" (ohne jedes Suffix)

Hier das script:

Bash:
#!/bin/zsh

function download()
{
    base=$(basename "$1")
    [ ! -e "$base" ] && curl -LO "$1"
    tar -xzf "$base"
    rm -f "$base"
    cd $(basename "$base" .tar.gz)
}

function cleanup()
{
    cd "$1"
    [ -n "$2" ] && param="$2" || param="uninstall"
    sudo make "$param"
    cd ..
    rm -rf "$1"
}

#---

# download status 19.Jan.2025

# build libraries
# openssl
download https://github.com/openssl/openssl/releases/download/openssl-3.4.0/openssl-3.4.0.tar.gz
./Configure no-shared
make build_sw
sudo make install_sw
cd -


# xxHash
download https://github.com/Cyan4973/xxHash/archive/refs/tags/v0.8.3.tar.gz
cd xxHash-0.8.3
make
sudo make install
sudo rm -f /usr/local/lib/libxxhash*dylib
cd -

# lz4
download https://github.com/lz4/lz4/releases/download/v1.10.0/lz4-1.10.0.tar.gz
make
sudo make install
sudo rm -f /usr/local/lib/liblz4*dylib
cd -

# zstd
download https://github.com/facebook/zstd/releases/download/v1.5.6/zstd-1.5.6.tar.gz
make
sudo make install
sudo rm -r /usr/local/lib/libzstd*dylib
cd -

# now rsync
download https://download.samba.org/pub/rsync/src/rsync-3.4.1.tar.gz
./configure --disable-md2man
make
# and copy rsync into a path directory, /usr/local/bin
cp rsync ..
sudo mkdir -p /usr/local/bin
sudo cp rsync /usr/local/bin/
cd -


# cleanup
cleanup openssl* uninstall_sw
cleanup xxHash*
cleanup lz4*
cleanup zstd*
cleanup rsync-*

# end of script

Nun gehts los. Zuerst wechselt ihr in das gerade angelegte Verzeichnis

Code:
cd ~/myrsync

dann macht ihr das script ausführbar mit

Code:
chmod a+x make_rsync

und schließlich ruft ihr es auf mit (ihr müsst eurer Admin-PW eingeben)

Code:
sudo ./make_rsync

Nun werden allen benötigen libraries und rsync herunter geladen und kompiliert. Das fertige rsync liegt dann sowohl im Verzeichnis 'myrsync' und wird zusätzlich nach /usr/local/bin kopiert und ist dann ganz normal aufrufbar, das /usr/local/bin im PATH liegt.

Wenn ihr rsync noch für einen anderen Mac benötigt (mit gleicher macOS-Version) dann könnte ihr das rsync bniary einfach dorthin kopieren.

Wollt ihr irgendwann mal rsycn erneuern, dann müsst ihr lediglich die Links zu den jeweiligen downloads aktualiseren. Im script findet ihr diese immer in einer Zeile mit bspw

Code:
download https://github.com/facebook/zstd/releases/download/v1.5.6/zstd-1.5.6.tar.gz

Viel Spaß beim kompilieren.
 
Erstes Feedback:
Das script ist durch und ich habe nun unter /usr/local/bin ein rsync v3.4.1
Es gab am Ende des Scripts ein paar Meldungen wegen rm und rmdir ... aber wohl nix wildes

Testen muss ich nun noch ...
 
Es gab am Ende des Scripts ein paar Meldungen wegen rm und rmdir ... aber wohl nix wildes

Vergiss die Meldungen. Ich habe einfach in cleanup() Annahmen treffen müssen. Das macht das script übersichtlicher und generischer.
 
So, ich habe getestet:
Im Terminal einen /usr/local/bin/rsync gestartet: ok
Mein Backup-Script kurz auf /usr/local/bin/rsync Nutzung angepasst und gestartet: auch ok

Dann der grosse Test: läuft der LaunchAgent? Nein.
Fehler:
Code:
========== Sichere Verzeichnis: Dokumente =========================

rsync: [sender] failed to connect to omv.local (2001:9e8:5ef7:4200:da3a:ddff:fe83:55b8): No route to host (65)
rsync: [sender] failed to connect to omv.local (192.168.178.100): No route to host (65)
rsync: [sender] failed to connect to omv.local (fd00::da3a:ddff:fe83:55b8): No route to host (65)
rsync error: error in socket IO (code 10) at clientserver.c(139) [sender=3.4.1]

Aber man sieht: omv.local wird mit richtiger IPv4 aufgelöst

Dann wieder einfach altes Backup-Script mit Homebrew-rsync v3.3:
Ausgabe:
Code:
========== Sichere Verzeichnis: Dokumente =========================

sending incremental file list

sent 123,778 bytes  received 938 bytes  83,144.00 bytes/sec
total size is 1,029,792,153  speedup is 8,257.10

OK. Gehört in den anderen Thread ... und nicht hierher
 
@lisanet Ich bin nun dein Script genauer - Schritt für Schritt - durchgegangen, um genauer zu verstehen was da abläuft. Dabei habe ich mal jedes Kommando der Reihe nach im Terminal gestartet (jedenfalls teilweise), um genauer zu verstehen, was da eigenlich geladen/ausgeführt wird und welches Ergebnis erzeugt wird.
Soweit so gut. Das Script habe ich verstanden (war auch nicht allzu schwer :) )

Grundsätzliche Fragen als "Nicht-Programmierer" habe ich aber noch... Ich habe zwar mal vor Jahrzehnten unter HP-UX ein paar Sachen programmiert, aber der Zahn der Zeit .... Vielleicht magst du sie mir "high-level" beantworten (oder auch nicht)

1- "configure" bereitet ja das "make" vor, erzeugt zB ein ans System angepasstes makefile. Aber manchmal wird es verwendet und manchmal nicht.
Warum ist das eigentlich so?
Und wo bekommst du die verwendeten Optionen/Parameter her? Aus dem configure-script selbst?
2- "make": hier verwendest du verschiedene Parameter (install, build_sw, install_sw) und machmal keine.
Wo kommen die her und warum sind sie überhaupt unterschiedlich?
Ich habe in die man pages von "make" geschaut - aber da finde ich nichts davon (oder ich bin mal wieder blind ...)
3- Grundsätzlich zum finalen Build von rsync. Es werden zunächst ja 4 Bibliotheken/Binaries gebaut und in /usr/local abgelegt. Dann wird rsync kompiliert und landet in /usr/local/bin. ok.
Aber woher weiss das make, dass es die gerade gebauten 4 Bibliotheken nehmen soll und nicht evt bereits im System vorhandene?
Macht das "configure" und/oder wird da einfach eine "Pfadreihenfolge" eingehalten, so wie: /usr/local first?

Wie gesagt: wenn du keine Lust hast zu erklären, dann ist das auch ok. Vielleicht hast du auch nur einfach einen Tip, wo ich solche "Grundsatzfragen für Dummies" erklärt bekomme.
Denn: ein rsync-Update kommt bestimmt und dann kann ich "üben" ... zuvor würde ich aber gern die grundsätzlichen Abläufe verstehen. Vielleicht auch, um auch mal ein anderes Binary kompiliert zu bekommen. Dazu müsste ich ja nicht zwingend selbst programmieren können.
 
Oh, oh, oh...

Du möchstest also in einem "highlevel" Posting erklärt erhalten, wie die GNU autotools funktionieren. Hhmm, ich weiß nicht, wie viele hunderte von Doku-Seiten es dazu gibt, aber ich kann es ja mal versuchen ;)

Also, wenn dir gerne der Kopf raucht, lies die GNU Doku -> https://www.gnu.org/software/automake/manual/html_node/index.html#SEC_Contents

In aller Kürze und nur wirklich an der Oberfläche. (Ich bitte diejenigen, die sich in den autotools auskennen, jetzt nicht einen auf Haarespalter zu machen. Bitte lasst das hier. Glaubt mir, ich kann mit den autotools umgehen und mag die mehr als CMake)

0) Der Entwickler erstellt mit Hilfe von ein paar Textfiles Anweisungen, wie der code zu bauen ist. Da stehen dann die source codes drin, Abhängigkeiten von anderen Libraries/Frameworks und mögliche unterschiedliche Tools, Dinge, Wege, die der Entwickler vorgesehen hat sein Projekt zu bauen. Diese Wege nennt man "targets".

0.1) Die GNU autotools können dann aus diesen Textfiles Shell-Scripte erzeugen (bspw "configure" und "Makefile"). Das tolle an den autotools ist nun, dass sie dabei eine rieisige Menge an Tests im script configure einfügen, die auf sehr vielen unixoide Systemen prüfen, ob die benötigten librariers vorhanden sind, ob einzelne Funktionen darin vorhanden sind, wie man diese lbiraries verwenden muss. Aus dieser gesamten gesammelten Info wird dann mit Hilfe der Textfiles automatisch ein oder mehrere (in den Unterverzeichnissen) Makefiles erzeugt, die dann für das ganz konkret vorliegende System, die eigentlichen Anweisungen zum Kompilieren incl aller vom Entwickler vorgesehenen targets enthält.

0.2) es gibt in Makefiles ein paar Standard-Targets: all, install, uninstall, clean (und noch einige mehr, das sind die wichtigsten)

Üblicherweise bereitet der Entwickler die scripte configure und die Makefiles vor und liefert es mit den sourcen aus.

Zu deinen Fragen

1) Durch configure werden die für das jeweilige System benötigen Makefiles erzeugt. configure bietet verschiedene Optionen. Einfach mal aufrufen ./configure --help
Will man andere Optionen als die vom Entwickler vorgesehenen Varianten nutzen, so muss man halt configure entsprechend aufrufen. Dadurch werden dann die Makefiles mit den gewählten Optionen erzeugt und die ausgelieferten Makefiles ersetzt

2) Die targets gibt der Entwickler vor. Ruft man nur "make" auf, wird das default target genutzt, üblicherweise "all", insoweit ist also "make" gleich mit "make all"

Die targets haben nichts mit der manpage zu tun. Die gibt der Entwickler vor (kuck mal in die Dateien Makefile.ac Aber bitte NICHTS daran ändern! Auch nichts unverändert abspeichern! Sobald das einen neueren Zeitstempel hat, wirden automatisch die autotools aufgerufen und alle anderen Textfiles benötigt um configure zu bauen. Also Finger weg!!!)

2.1) "the holy trinity" der autotools ist

./configure
make
sudo make install

3) ja, das ist das "magic" an den autotools. Es geht zum einen nach Pfaden, es werden Infos von pkgconfig genutzt, es werden include-Pfade zu Headerfiles des Systems genutzt, je nach dem, was der Entwickler vorgegeben hat und was configure wo bei seinen Tests findet.

Konkret findet configure auf macOS die 4 libs nicht, da sie so nicht in macOS bezeichnet / benannt werden, bzw an Pfaden liegen, die configure nicht erreicht bzw in macOS-Frameworks enthalten sind, die von außen nicht "vereinzelt" werden können.

4) Man muss halt wissen, was man haben will bzw. was unter macOS das gewünschte Ergebniss erzielt. Also ./configure --help, Makefiles lesen, Doku des Projektes lesen, Issues des Projetes lesen, Recherchen im Netz machen, Foren lesen, Programmiererfahrung einbringen, das Ganze einfach mal starten, Ergebnisse testen, Fehler analysieren, Fehler beheben und wieder erneut testen, bis man sein Ziel erreicht.

Reicht das?
 
Hallo ihr beiden,

Kompliment!
Das macht mal wieder richtig Spaß beim Lesen und geht mMn deutlich über "Compilieren für Dummies" hinaus.
Ich verstehe zwar nur die Hälfte aber ich finde es ist toll erklärt. Gilt sowohl für @lisanet und @jteschner.

Gruß reinhold
 
Oh, oh, oh...

Du möchstest also in einem "highlevel" Posting erklärt erhalten, wie die GNU autotools funktionieren. Hhmm, ich weiß nicht, wie viele hunderte von Doku-Seiten es dazu gibt, aber ich kann es ja mal versuchen ;)

Also, wenn dir gerne der Kopf raucht, lies die GNU Doku -> https://www.gnu.org/software/automake/manual/html_node/index.html#SEC_Contents

In aller Kürze und nur wirklich an der Oberfläche. (Ich bitte diejenigen, die sich in den autotools auskennen, jetzt nicht einen auf Haarespalter zu machen. Bitte lasst das hier. Glaubt mir, ich kann mit den autotools umgehen und mag die mehr als CMake)

0) Der Entwickler erstellt mit Hilfe von ein paar Textfiles Anweisungen, wie der code zu bauen ist. Da stehen dann die source codes drin, Abhängigkeiten von anderen Libraries/Frameworks und mögliche unterschiedliche Tools, Dinge, Wege, die der Entwickler vorgesehen hat sein Projekt zu bauen. Diese Wege nennt man "targets".

0.1) Die GNU autotools können dann aus diesen Textfiles Shell-Scripte erzeugen (bspw "configure" und "Makefile"). Das tolle an den autotools ist nun, dass sie dabei eine rieisige Menge an Tests im script configure einfügen, die auf sehr vielen unixoide Systemen prüfen, ob die benötigten librariers vorhanden sind, ob einzelne Funktionen darin vorhanden sind, wie man diese lbiraries verwenden muss. Aus dieser gesamten gesammelten Info wird dann mit Hilfe der Textfiles automatisch ein oder mehrere (in den Unterverzeichnissen) Makefiles erzeugt, die dann für das ganz konkret vorliegende System, die eigentlichen Anweisungen zum Kompilieren incl aller vom Entwickler vorgesehenen targets enthält.

0.2) es gibt in Makefiles ein paar Standard-Targets: all, install, uninstall, clean (und noch einige mehr, das sind die wichtigsten)

Üblicherweise bereitet der Entwickler die scripte configure und die Makefiles vor und liefert es mit den sourcen aus.

Zu deinen Fragen

1) Durch configure werden die für das jeweilige System benötigen Makefiles erzeugt. configure bietet verschiedene Optionen. Einfach mal aufrufen ./configure --help
Will man andere Optionen als die vom Entwickler vorgesehenen Varianten nutzen, so muss man halt configure entsprechend aufrufen. Dadurch werden dann die Makefiles mit den gewählten Optionen erzeugt und die ausgelieferten Makefiles ersetzt

2) Die targets gibt der Entwickler vor. Ruft man nur "make" auf, wird das default target genutzt, üblicherweise "all", insoweit ist also "make" gleich mit "make all"

Die targets haben nichts mit der manpage zu tun. Die gibt der Entwickler vor (kuck mal in die Dateien Makefile.ac Aber bitte NICHTS daran ändern! Auch nichts unverändert abspeichern! Sobald das einen neueren Zeitstempel hat, wirden automatisch die autotools aufgerufen und alle anderen Textfiles benötigt um configure zu bauen. Also Finger weg!!!)

2.1) "the holy trinity" der autotools ist

./configure
make
sudo make install

3) ja, das ist das "magic" an den autotools. Es geht zum einen nach Pfaden, es werden Infos von pkgconfig genutzt, es werden include-Pfade zu Headerfiles des Systems genutzt, je nach dem, was der Entwickler vorgegeben hat und was configure wo bei seinen Tests findet.

Konkret findet configure auf macOS die 4 libs nicht, da sie so nicht in macOS bezeichnet / benannt werden, bzw an Pfaden liegen, die configure nicht erreicht bzw in macOS-Frameworks enthalten sind, die von außen nicht "vereinzelt" werden können.

4) Man muss halt wissen, was man haben will bzw. was unter macOS das gewünschte Ergebniss erzielt. Also ./configure --help, Makefiles lesen, Doku des Projektes lesen, Issues des Projetes lesen, Recherchen im Netz machen, Foren lesen, Programmiererfahrung einbringen, das Ganze einfach mal starten, Ergebnisse testen, Fehler analysieren, Fehler beheben und wieder erneut testen, bis man sein Ziel erreicht.

Reicht das?

Super erklärt - high level und gibt eine tolle erste Übersicht! Danke!
Das reicht mir so, weil es meine grundsätzlichen Fragen klärt - und ist eigentlich schon mehr als ich erwartet hatte.
Wenn ich genaueres will, muss ich halt lesen ...
 
Zurück
Oben Unten