1. Diese Seite verwendet Cookies. Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies. Weitere Informationen

Unix Source unter Leopard explizit gegen 10.4u SDK linken.

Dieses Thema im Forum "iOS-Developer" wurde erstellt von pepi, 23.04.08.

  1. pepi

    pepi Cellini

    Dabei seit:
    03.09.05
    Beiträge:
    8.741
    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
     
    #1 pepi, 23.04.08
    Zuletzt bearbeitet: 25.04.08
  2. quarx

    quarx Hadelner Sommerprinz

    Dabei seit:
    17.04.05
    Beiträge:
    8.541
    ... auch wenn Du versuchst, wie in configure.sh erwähnt...
    ... die Variablen als Argumente an configure weiterzuleiten?
     
  3. pepi

    pepi Cellini

    Dabei seit:
    03.09.05
    Beiträge:
    8.741
    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
     
  4. MacApple

    MacApple Lord Grosvenor

    Dabei seit:
    05.01.04
    Beiträge:
    3.470
    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
     
  5. Amin Negm-Awad

    Amin Negm-Awad Süsser Pfaffenapfel

    Dabei seit:
    01.03.07
    Beiträge:
    665
    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.
     
  6. ifthenelse

    ifthenelse Fießers Erstling

    Dabei seit:
    07.12.06
    Beiträge:
    129
    ***LOL***
     
  7. quarx

    quarx Hadelner Sommerprinz

    Dabei seit:
    17.04.05
    Beiträge:
    8.541
    Das kann man sich bei der Übersetzung von fremdem Quellcode (um den es hier geht) nicht immer aussuchen.
     
  8. Zettt

    Zettt Doppelter Melonenapfel

    Dabei seit:
    16.10.05
    Beiträge:
    3.374
    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...
     
  9. pepi

    pepi Cellini

    Dabei seit:
    03.09.05
    Beiträge:
    8.741
    Hoffentlich ist mein Aufsatz lang genug.

    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.

    // Wenn schon, dann
    /* LOL */
    :)


    Die Botschaft hör' ich wohl, allein mir fehlt der Glaube. (Goethe; Faust, der Tragödie erster Teil)
    Gruß Pepi
     
    #9 pepi, 25.04.08
    Zuletzt bearbeitet: 25.04.08
  10. tjp

    tjp Baldwins roter Pepping

    Dabei seit:
    07.07.04
    Beiträge:
    3.251
    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.
     
  11. Amin Negm-Awad

    Amin Negm-Awad Süsser Pfaffenapfel

    Dabei seit:
    01.03.07
    Beiträge:
    665
    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.
     
  12. Amin Negm-Awad

    Amin Negm-Awad Süsser Pfaffenapfel

    Dabei seit:
    01.03.07
    Beiträge:
    665
    Für Rest ∈ {quarx} stimmt diese Aussage. Eine Menge mit dieser Kardinalität bekommt man ja selten zu Gesicht.
     
  13. pepi

    pepi Cellini

    Dabei seit:
    03.09.05
    Beiträge:
    8.741
    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
     
  14. Amin Negm-Awad

    Amin Negm-Awad Süsser Pfaffenapfel

    Dabei seit:
    01.03.07
    Beiträge:
    665
    Wie bist du denn jetzt auf das Makro gekommen?
     
  15. pepi

    pepi Cellini

    Dabei seit:
    03.09.05
    Beiträge:
    8.741
    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
     
  16. Amin Negm-Awad

    Amin Negm-Awad Süsser Pfaffenapfel

    Dabei seit:
    01.03.07
    Beiträge:
    665
    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. ;)
     
  17. MacMark

    MacMark Biesterfelder Renette

    Dabei seit:
    01.01.05
    Beiträge:
    4.709
    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)
     
  18. MacApple

    MacApple Lord Grosvenor

    Dabei seit:
    05.01.04
    Beiträge:
    3.470
    Schön. Und was willst Du uns jetzt damit sagen?

    MacApple
     

Diese Seite empfehlen