Unix Source unter Leopard explizit gegen 10.4u SDK linken.

[pepi]

Hi!

Ich habe hier eine kleine Herausforderung mit dem Quellcode von rsync 3.0.2. Diesen zu compilieren ist ein Kinderspiel und gelingt erwartungsgemäß auch unter Leopard völlig problemlos. Lösungen konnte ich leider weder bei Apple, noch hier noch sonstwo per Google finden. Meine Aufgabenstellung präsentiert sich folgendermaßen:

Ich möchte diese Source explizit gegen das 10.4u SDK linken und nicht gegen das 10.5 SDK. Ziel soll ein Universal-Binary sein welches für ppc, ppc64, i386 und x86_64 optimiert ist und eben unter 10.4.x (von mir aus 10.4.11) und 10.5 läuft.

Leider gelingt es mir nicht dem gcc und dem ld klarzumachen, daß ich auch unter Leopard gegen das 10.4u SDK builden möchte.

Installiert ist Xcode 3.1 (beta, aus dem iPhone SDK beta 2, noch nicht die aktuelle beta 3)

Component versions
Xcode IDE: 1057.0
Xcode Core: 1056.0
ToolSupport: 1056.0

$ gcc --version
powerpc-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5478)

Die rsync 3.0.2 Source wurde aus dem offiziellen stable tarball genommen.

Ich habe schon versucht vor dem ./configure die Environment Variablen wie folgt zu setzen:


CFLAGS"=-g -O3 -DHAVE_CONFIG_H -Wall -W -I./popt -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch i386 -arch ppc64 -arch x86_64"
LDFLAGS="-arch ppc -arch i386 -arch ppc64 -arch x86_64"


Leider werden die Architekturen und mein SDK Wunsch völlig ignoriert. Selbst wenn ich diese Angaben dann im Makefile manuell korrigiere, kann ich nicht mit dem 10.4u SDK builden. gcc will immer das 10.5 SDK verwenden.

Die ./configure Optionen --disable-dependency-tracking oder --with-macosx-sdk=/Developer/SDKs/MacOSX10.4u.sdk werden leider nicht verstanden.

Für Hinweise welche Verrenkungen notwendig sind um das so hinzubekommen bin ich natürliich dankbar. Gegen das 10.5 SDK kann ich alles problemlos mit 4 Mach-O executables in einem Fat-Binary builden. Das sieht dann so aus:

$ file rsync
rsync: Mach-O universal binary with 4 architectures
rsync (for architecture i386): Mach-O executable i386
rsync (for architecture ppc64): Mach-O 64-bit executable ppc64
rsync (for architecture x86_64): Mach-O 64-bit executable x86_64
rsync (for architecture ppc7400): Mach-O executable ppc

(Das "allerschärfste" wäre natürlich ein PPC binary gegen das 10.3.9 SDK und das intel binary gegen das 10.4u SDK zu linken und alle vier mit lipo in ein executable zu packen. Wobei ich mit der Lösung alles erfolgreich gegen 10.4u zu builden schon gücklich wäre.)

Wer noch genauere Infos braucht um helfen zu können, kann gerne ein config.log oder andere Infos bekommen.

Dankeschön
Gruß Pepi

 

[quarx]

Ich habe schon versucht vor dem ./configure die Environment Variablen wie folgt zu setzen:


CFLAGS"=-g -O3 -DHAVE_CONFIG_H -Wall -W -I./popt -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch i386 -arch ppc64 -arch x86_64"
LDFLAGS="-arch ppc -arch i386 -arch ppc64 -arch x86_64"


Leider werden die Architekturen und mein SDK Wunsch völlig ignoriert.

... auch wenn Du versuchst, wie in configure.sh erwähnt...

\`configure' configures this package to adapt to many kinds of systems.

Usage: $0 [OPTION]... [VAR=VALUE]...

To assign environment variables (e.g., CC, CFLAGS...), specify them as
VAR=VALUE.

... die Variablen als Argumente an configure weiterzuleiten?

 

[pepi]

Keine schlechte Idee, hilft aber leider nicht. Wenn ich mit $ ./configure CFLAGS"=-g -O3 -DHAVE_CONFIG_H -Wall -W -I./popt -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch i386 -arch ppc64 -arch x86_64" LDFLAGS="-arch ppc -arch i386 -arch ppc64 -arch x86_64" configurieren möchte, dann (ver)endet das ganze mit der Meldung

autoconf -o configure.sh
autoheader && touch config.h.in
configure.sh: Configuring rsync 3.0.2
checking build system type... powerpc-apple-darwin9.2.2
checking host system type... powerpc-apple-darwin9.2.2
checking target system type... powerpc-apple-darwin9.2.2
checking for gcc... gcc
checking for C compiler default output file name...
configure.sh: error: C compiler cannot create executables
. (Returncode 77, kompletter config.log Output verfügbar.)
Wobei der gcc sowas bald mal sagt.

Im config.log steht trotz der Plattformangaben drinnen target_cpu='powerpc'.

Wird also auch so, wie das Environment einfach ignoriert. Ich weis leider nicht ob die Angabe -isysroot /Developer/SDKs/MacOSX10.4u.sdk überhaupt passend ist. Das ist nur ein Analogieversuch aus einem anderen OSS Projekt den ich gefunden habe. Leider sind Apples Tips zum UB builden von Unix Tools einigermaßen mangelhaft.

Die target_cpu bzw. die arch könnte ich ja noch manuell im Makefile ausbessern, aber das SDK müßte ich schon beim ./configure irgendwie "erzwingen" können.
Gruß Pepi

 

[MacApple]

Ich möchte diese Source explizit gegen das 10.4u SDK linken und nicht gegen das 10.5 SDK. Ziel soll ein Universal-Binary sein welches für ppc, ppc64, i386 und x86_64 optimiert ist und eben unter 10.4.x (von mir aus 10.4.11) und 10.5 läuft.

Tut es das denn nicht, wenn Du mit dem 10.5 SDK baust? Wenn man gegen das 10.5 SDK linkt heißt das ja nicht automatisch, dass das Programm nicht unter 10.4 läuft.

MacApple

 

[Amin Negm-Awad]

Definiere mal testweise ein Macro macosmin

Ansonsten:

1. In Xcode ein C-Projekt anlegen.
2. .4 als Ziel setzen.
3. compilieren
4. schauen, was als Optionen übergeben werden.
5. Mit eigenen vergleichen
6. Einen Beitrag hier verfassen, warum die CLI-Bedienung von Development-Tools viel besser ist als eine IDE mit GUI.

 

[ifthenelse]

...6. Einen Beitrag hier verfassen, warum die CLI-Bedienung von Development-Tools viel besser ist als eine IDE mit GUI.

***LOL***

 

[quarx]

6. Einen Beitrag hier verfassen, warum die CLI-Bedienung von Development-Tools viel besser ist als eine IDE mit GUI.

Das kann man sich bei der Übersetzung von fremdem Quellcode (um den es hier geht) nicht immer aussuchen.

 

[Zettt]

Ich kann mich irren aber fuer mich hat es sich so angehoert als wollte Amin sagen, dass die Loesung fuer dieses Problem hier mit Xcode ganz einfach zu loesen ist...

 

[pepi]

Hoffentlich ist mein Aufsatz lang genug.

Definiere mal testweise ein Macro macosmin

Ansonsten:

1. In Xcode ein C-Projekt anlegen.
2. .4 als Ziel setzen.
3. compilieren
4. schauen, was als Optionen übergeben werden.
5. Mit eigenen vergleichen
6. Einen Beitrag hier verfassen, warum die CLI-Bedienung von Development-Tools viel besser ist als eine IDE mit GUI.

Danke für den Tip Amin. Ich habe das probiert und es bestätigt mir lediglich, daß meine Annahme mit der Übergabe von -isysroot durchwegs korrekt war. Leider konnte ich bisher mit den dadurch gewonnenen Erkenntnissen mein Problem nicht lösen.

Ad 6) Warum CLI Tools besser sind als eine IDE mit GUI…
Ich habe nicht behauptet, daß sie besser sind, das möchte ich erstmal vorausschicken.

Ich bin allerdings der Meinung, daß CLI Tools per SSH deutlich besser zu bedienen sind als Xcode. Vor allem wenn es um einen Server geht der irgendwo auf diesem Planeten steht. Auch Automatisierungen sind per shell irgendwie komfortabler als per GUI, welches ich in diesem Falle nicht zur Verfügung habe. Jedenfalls nicht auf der Deployment Platform. Natürlich ist es nett beim Testen und Ausprobieren auf meinem PowerBook die Möglichkeiten nutzen zu können, was ich dank Deines Tips auch getan habe. Wenn mein Ziel ist das per CLI überall machen zu können, bzw. in ein Shellscript zur Automation einbauen zu können, dann ist eine IDE mit GUI der falsche Ansatz, und definitiv nicht die Lösung.

Wie quarx schon sagte kann ich mir in dem Fall nicht aussuchen, wie ich meinen Quellcode bereitgestellt bekomme. Mich persönlich stört es auch überhaupt nicht auf der CommandLine zu arbeiten, ganz im Gegenteil, ich fühle mich dort (auch historisch gesehen) sehr wohl. Die wenigsten Unix Projekte kommen halt als .xcodeproj daher…

Xcode ist durchaus eine gute Lösung, allerdings für andere "Probleme"/Aufgabenstellungen.

***LOL***

// Wenn schon, dann
/* LOL */

Ich kann mich irren aber fuer mich hat es sich so angehoert als wollte Amin sagen, dass die Loesung fuer dieses Problem hier mit Xcode ganz einfach zu loesen ist...

Die Botschaft hör' ich wohl, allein mir fehlt der Glaube. (Goethe; Faust, der Tragödie erster Teil)
Gruß Pepi

 

[tjp]

Ich kann mich irren aber fuer mich hat es sich so angehoert als wollte Amin sagen, dass die Loesung fuer dieses Problem hier mit Xcode ganz einfach zu loesen ist...

Tja, und was der Rest sagt ist ganz einfach: Xcode ist ein proprietäres Tool, welches es auf den anderen Plattformen nicht gibt, und somit kein Option ist. Bei SUN, IBM, HP gibt es für das jeweiligen UNIX eine detaillierte Doku wie man Binaries für die jeweiligen Plattform zu bauen hat. Apples Doku verdient diesen Namen nicht, sie ist lückenhaft und unvollständig.

 

[Amin Negm-Awad]

Neee, ich wollte nicht sagen, dass es im konkreten Falle mit Xcode einfacher geht. Ich wollte sagen, dass man generell so etwas mit Xcode irgendwie einfacher hinbekommt. Das war daher weder auf Pepi gemünzt, noch auf das konkrete Projekt. Es war auf die generelle "Supi-dupi-CLI-Fraktion" gemünzt.

Allerdings wunderte ich mich dann doch, dass zu den problembezogenen 5 Punkten eine kurze Antwort kommt, dzu dem etwas neben der Sache liegenden 6. Punkt ein ganzer Roman. *Ohne Worte*

Zurück zum Thema:
Mit Xcode kann man das. Es geht also. Wenn bei dir die Optionen übereinstimmen, dann können es nicht die Optionen sein. Ich würe daher mal testweise alles aus dem Build-Prozess übernehmen und einfach nur den Dateinamen austauschen. Dann so lange anpassen, bis es nicht mehr funktioniert.

Selbstverständlich müsste man sich auch die Variablen anschauen. Möglicherweise sind die ja anders gesetzt.

 

[Amin Negm-Awad]

Tja, und was der Rest sagt ist ganz einfach: Xcode ist ein proprietäres Tool, welches es auf den anderen Plattformen nicht gibt, und somit kein Option ist.[…]

Für Rest ∈ {quarx} stimmt diese Aussage. Eine Menge mit dieser Kardinalität bekommt man ja selten zu Gesicht.

 

[pepi]

Apples so-called "Documentation" ist immer wieder ein Grund einen Bug am Radar zu filen. Manchmal weil sie fehlerhaft ist, meist aber in gänzlicher Ermangelung Ihrerselbst. Das betrifft aber nicht nur die DevTools.


Ich glaube ich habe inzwischen eine funktionierende Lösung gefunden, die bei mir momentan wie folgt aussieht:

Nachdem das Environment sichtlich einigermaßen ignoriert wird, muß man die Parameter direkt ans configure übergeben. Das sieht dann bei mir so aus und hat tatsächlich reproduzierbar funktioniert.

(Alles auf einer Zeile natürlich)
./configure CC="gcc -std=gnu99 -mmacosx-version-min=10.4 -isysroot /Developer/SDKs/MacOSX10.4u.sdk" CFLAGS="-g -O3 -DHAVE_CONFIG_H -Wall -W -I./popt -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch i386 -arch ppc64 -arch x86_64" LDFLAGS="-mmacosx-version-min=10.4 -arch ppc -arch i386 -arch ppc64 -arch x86_64"

Das resultiert in eben diesen Angaben auch im Makefile so wie ich mir das gewünscht habe. Danach das obligatorische make

Das Resultat ist bei mir 2153848 Bytes groß:

$ file rsync
rsync: Mach-O universal binary with 4 architectures
rsync (for architecture ppc): Mach-O executable ppc
rsync (for architecture i386): Mach-O executable i386
rsync (for architecture ppc64): Mach-O 64-bit executable ppc64
rsync (for architecture x86_64): Mach-O 64-bit executable x86_64

$ md5 rsync
MD5 (rsync) = 6342b56cb019c1fca48722136877aa67


Man könnte da bestimmt noch einiges mehr feintunen um noch etwas bessere Performance aus dem Binary rauszuschlagen. Inwiefern sich der Aufwand lohnt sei dahingestellt. Fürs erste bin ich mal zufrieden und glaube, daß mein Problem gelöst werden konnte. Danke an alle die Hilfestellungen gegeben haben.

Vielleicht kann uns Amin ja noch sein rsync.xcodeproj zeigen. Mich würde es grundsätzlich schon interessieren wie man aus einem Unix Projekt (tarball) ein Xcode Projekt bastelt. (Ich habs nicht zamgebracht, ich bin aber auch definitiv kein Xcode Profi sondern maximal Padawan.)
Gruß Pepi

 

[Amin Negm-Awad]

Wie bist du denn jetzt auf das Makro gekommen?

 

[pepi]

Ich hatte zeitlich die Gelegenheit die genannten Schritte 1-5 nochmal genauer durchzusehen und habe mich mit den Tuning Möglichkeiten vom gcc noch mehr rumgespielt.
Auf meinem PowerBook dauert es doch knapp 7 Minuten um eine Variante durchzuprobieren. Konnte es vorhin auf einem Quad-Xeon Xserve probieren, und dort isses in etwas mehr als einer Minute erledigt, was beim Trial-Error-Iterieren sehr förderlich ist. (Geht aber nur per ssh in dem Fall. )
Gruß Pepi

 

[Amin Negm-Awad]

Na, dann waren Tipps und Doku doch gar nicht so schlecht. Vielleicht hättest du darauf dann doch mehr Zeit verbringen sollen als auf Romane schreiben.

 

[MacMark]

Hausaufgabe: Wir schreiben ein Programm und compilieren es in eine einzige Datei, die dann von PPC, PPC-64, Intel und Intel-64 nativ ausgeführt werden kann. Ich habe da mal etwas vorbereitet:

KeyWest:~ macmark$ cat hello.c
/* Hello World program */

#include<stdio.h>

main()
{
printf("Hello World");

}
KeyWest:~ macmark$ gcc -arch ppc -arch ppc64 -arch i386 -arch x86_64 -c hello.c
KeyWest:~ macmark$ file hello.o
hello.o: Mach-O universal binary with 4 architectures
hello.o (for architecture ppc7400): Mach-O object ppc
hello.o (for architecture ppc64): Mach-O 64-bit object ppc64
hello.o (for architecture i386): Mach-O object i386
hello.o (for architecture x86_64): Mach-O 64-bit object x86_64
KeyWest:~ macmark$ lipo -detailed_info hello.o
Fat header in: hello.o
fat_magic 0xcafebabe
nfat_arch 4
architecture ppc7400
cputype CPU_TYPE_POWERPC
cpusubtype CPU_SUBTYPE_POWERPC_7400
offset 4096
size 744
align 2^12 (4096)
architecture ppc64
cputype CPU_TYPE_POWERPC64
cpusubtype CPU_SUBTYPE_POWERPC_ALL
offset 8192
size 852
align 2^12 (4096)
architecture i386
cputype CPU_TYPE_I386
cpusubtype CPU_SUBTYPE_I386_ALL
offset 12288
size 512
align 2^12 (4096)
architecture x86_64
cputype CPU_TYPE_X86_64
cpusubtype CPU_SUBTYPE_X86_64_ALL
offset 16384
size 728
align 2^12 (4096)

 

[MacApple]

Hausaufgabe: Wir schreiben ein Programm und compilieren es in eine einzige Datei, die dann von PPC, PPC-64, Intel und Intel-64 nativ ausgeführt werden kann. Ich habe da mal etwas vorbereitet:

Schön. Und was willst Du uns jetzt damit sagen?

MacApple