Das leidige Thema: Objective-C und Redmonds Fenster

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Das leidige Thema: Objective-C und Redmonds Fenster

    Nur um den üblichen Fragen/Verdächtigungen vorzubeugen:
    Nein, ich will keine bestehende Apple-Anwendung portieren.
    Ich habe auch keine Lust, irgendwas in GNUstep zu entwickeln.
    Oh, und Anwendungen mit UserInterface für die Windowskiste will ich auch nicht haben.

    Mein Problem ist eigentlich ein ganz einfaches, aber halt ziemlich speziell auf der Windows-Plattform.

    Ich möchte quasi an den Wurzeln allen Übels herumspielen und testen, was da so geht. Als Mittel der Wahl soll da der Arbeitsrechner in den Mittagspausen her halten. Deshalb verzichte ich gern auf AppKit, Foundation, IOKit und ähnlichen 'überflüssigen' Kleinkram und bastle hauptsächlich an Instanzen von Object und Kindeskindern herum.

    Die Idee dazu überkam mich nach dem Durchforsten von kressevadders Speicherverwaltungsartikel.

    Lange Rede, kurzer Sinn: die Windows GCC ärgert mich. Genauer gesagt der linke Linker der Windows GCC. Er mag offenbar eigene Subklassen nicht.
    Ich hatte den MinGW 3.4.5 getestet, einmal standalone, einmal aus dem GNUstep System.

    Der Erfolg ist immer der Gleiche: ich erhalte Fehler.

    Quellcode

    1. gcc main.m -lobjc
    2. Temp/cclOLlPE.o:main.m:(.data+0x54): undefined reference to `__objc_class_name_OCObject'
    3. collect2: ld returned 1 exit status

    Mal das Codeschnippselchen der main.m:

    Quellcode

    1. // for the windows api, not really needed at all except for the WinMain function
    2. #import <windows.h>
    4. #import <stdio.h>
    5. #import "OCObject.h"
    7. int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow)
    8. {
    9. // Just to keep the compiler quiet...
    10. // Otherwise it complains that no WinMain@16 was found...
    11. }
    13. int main( int arc, const char *argv[] ) {
    14. OCObject* rootObject;
    15. rootObject = [[OCObject alloc] init];
    17. printf("qwerty\n");
    19. [rootObject release];
    21. return 0;
    22. }
    Alles anzeigen

    Wie geschrieben, so wird dat nix.
    Ein Gegentest:

    Quellcode

    1. // for the windows api, not really needed at all except for the WinMain function
    2. #import <windows.h>
    4. #import <stdio.h>
    5. #import "OCObject.h"
    7. int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow)
    8. {
    9. // Just to keep the compiler quiet...
    10. // Otherwise it complains that no WinMain@16 was found...
    11. }
    13. int main( int arc, const char *argv[] ) {
    14. Object* rootObject;
    15. rootObject = [[Object alloc] init];
    17. printf("qwerty\n");
    19. [rootObject free];
    21. return 0;
    22. }
    Alles anzeigen

    Die Ausgabe lautet:
    C:> a.exe
    qwerty
    C:>

    (wer hätte das gedacht?)

    Ich kämpfe also nach wie vor mit dem Fehler:

    Quellcode

    1. Temp/cclOLlPE.o:main.m:(.data+0x54): undefined reference to `__objc_class_name_OCObject'
    2. collect2: ld returned 1 exit status

    Dieser scheint ganz offensichtlich mit meiner eigenen Klasse und dem Linker zusammen zu hängen.
    'Vergesse' ich, gegen die Objective-C runtime zu linken, gesellen sich zu __objc_class_name_OCObject noch undefinierte Referenzen zu __objc_get_class und __objc_msg_lookup.

    Ich erstelle die gesamten Sourcen mittels VIM für Windows und möchte die Resultate einfach nur kompiliert bekommen.

    Wer hat nen Tipp oder nen Link zu nem funktionsfähigen Objective-C Compiler unter Windows OHNE die ganzen Frameworks dran?
    Wer hat obendrein noch einen Tipp für ein Compilerflag, mit dem ich ihm die Suche nach dieser blöden WinMain abgewöhnen kann?
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P

  • RE: Das leidige Thema: Objective-C und Redmonds Fenster

    Original von Lucas de Vil
    ...
    Der Erfolg ist immer der Gleiche: ich erhalte Fehler.

    Quellcode

    1. gcc main.m -lobjc
    2. Temp/cclOLlPE.o:main.m:(.data+0x54): undefined reference to `__objc_class_name_OCObject'
    3. collect2: ld returned 1 exit status



    Ist das Problem nicht ganz einfach, dass Du noch gegen die Lib bzw. die Sourcen reinlinken musst, in denen das OCObject definiert wird?

    Rainer

  • RE: Das leidige Thema: Objective-C und Redmonds Fenster

    Original von ashcatch
    Original von Lucas de Vil
    ...
    Der Erfolg ist immer der Gleiche: ich erhalte Fehler.

    Quellcode

    1. gcc main.m -lobjc
    2. Temp/cclOLlPE.o:main.m:(.data+0x54): undefined reference to `__objc_class_name_OCObject'
    3. collect2: ld returned 1 exit status


    Ist das Problem nicht ganz einfach, dass Du noch gegen die Lib bzw. die Sourcen reinlinken musst, in denen das OCObject definiert wird?


    Dachte ich mir auch. Die Sourcen selbst sind aber noch nicht kompiliert.
    Und ein (naiv) beherztes -L./ hat auch nix gebracht.
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P

  • RE: Das leidige Thema: Objective-C und Redmonds Fenster

    Original von Lucas de Vil
    Dachte ich mir auch. Die Sourcen selbst sind aber noch nicht kompiliert.

    +haut schwungvoll den Kopf auf die Tischkante+
    Schön, wenn man den Fehler selbst findet. Natürlich muss die einzubeziehende Objektdatei mit kompiliert werden...

    Nur fürs Protokoll:

    Quellcode

    1. gcc OCObject.m main.m -lobjc


    Typischer Fall von UZB.
    (User Zu Blöd)

    Danke. :)
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P

  • RE: Das leidige Thema: Objective-C und Redmonds Fenster

    Original von ashcatch
    Ist das Problem nicht ganz einfach, dass Du noch gegen die Lib bzw. die Sourcen reinlinken musst, in denen das OCObject definiert wird?


    Welche Möglichkeit habe ich, dem Compiler zu sagen, er soll beim Linken alle Objektdateien in Ordner /sonstwas nutzen?
    Falls 'keine': Ist es sinnvoll, dafür shared objects zu generieren?

    (So langsam verstehe ich die Existenzberechtigung von Makefiles...)
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P

  • Original von kressevadder
    Warum haust du auf deine Winkiste eigentlich nicht die VirtualBox von Sun drauf und installierst da mal BSD oder Linux.

    Ein bissl übergroß für kleine Pausenprojekte.
    Allerdings werde ich mal meinen Uraltlaptop reanimieren. +glaub+
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P

  • RE: Das leidige Thema: Objective-C und Redmonds Fenster

    Original von Lucas de Vil
    Dachte ich mir auch. Die Sourcen selbst sind aber noch nicht kompiliert.

    Und da wunderst Du Dich?
    Erst wird alles compiliert, danach linkt man alle Objektdateien zum Programm zusammen.
    gcc -c bla1.m -o bla1.o
    …
    gcc -c blan.m -o blan.o
    ld bla1.o bla2.o bla3.o … blan.o -lobjc -o my_binary

    Wenn man den gcc, wie übrigens alle anderen UNIX Kommandozeilen Compiler, ohne -c aufruft, versucht er aus einer Sourcedatei direkt ein Binary zu machen. Das scheitert natürlich bei Dir.

    P.S. Wohl zu lange IDEs genutzt?

  • RE: Das leidige Thema: Objective-C und Redmonds Fenster

    Original von tjp
    P.S. Wohl zu lange IDEs genutzt?

    Vielleicht. :P
    Auf jeden Fall zu lange nicht mit Makefiles rumgeschlagen.

    Wie bist du denn eigentlich auf diesen Thread aufmerksam geworden?
    Die Sache ist seit gefühlten zwei Monaten gegessen. ;)

    Aber die gemachten Erfahrungen waren schon schön. :)
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P

  • Im Groben war es das. :D
    Die fünf anderen Objekte habe ich gerade nicht im Kopf. ;)
    Das kann ich aber morgen ganz flugs berichten.
    (Hab den Windows-Rechner nur auf Arbeit, hier am Mac ist natürlich die Apple-Variante druff)
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P

  • RE: Das leidige Thema: Objective-C und Redmonds Fenster

    Original von Lucas de Vil
    Wie bist du denn eigentlich auf diesen Thread aufmerksam geworden?

    Ich lese selten im Forum, es ist der neuste Eintrag im Unterforum gewesen, und die Antwort war schon geschrieben als ich auf das Datum geschaut habe.

  • Original von -Nuke-
    Was kann "reines Objective-C" eigentlich? Gibt's unterhalb von "Object" noch andere Sachen, oder war's das schon?


    Viel ist da nicht mehr.
    Wichtige Objective-C Header:
    • encoding.h
    • hash.h
    • objc.h
    • objc-api.h
    • objc-decls.h
    • objc-list.h
    • sarray.h
    • thr.h
    • typedstream.h


    Klassenheader:
    • Object.h
    • NXConstStr.h
    • Protocol.h


    Ist also recht übersichtlich gehalten.

    Obacht: Typisieren mit id kann zu Fehlern führen, will man auf die Methode 'name' zugreifen. Object liefert via -name eine C-String der Klasse zurück. Liefert das eigentliche Objekt via -name ein Objekt zurück, an welches man eine Nachricht schicken will, dann knallts. Bei NSObject hingegen gibt es die Methode 'name' nicht. Dort heißt sie className und gibt einen NSString zurück. Apple hat da ganz schön getrickst. ;)
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P

  • RE: Das leidige Thema: Objective-C und Redmonds Fenster

    Original von tjp
    Ich lese selten im Forum, es ist der neuste Eintrag im Unterforum gewesen.

    Ah, verstehe.
    Hast du vielleicht eine Idee, wie ich die blöden Objekte nur einmal kompilieren und in einem Ordner ablegen kann und dem Makefile dann erkläre, er solle alle benötigten Objekte zuerst in diesem Ordner suchen? Also ohne ihm explizit mitteilen zu müssen, welche Objekte ich jetzt noch in dieser einen Klasse verwenden will.

    Momentan ist das Makefile für so nen Kleinkram doch recht groß:

    Quellcode

    1. CC = gcc
    2. CFLAGS = -Wall -Werror -O0 -o ../_build/RCTest/app.exe
    3. LDFLAGS = -lobjc
    5. all: main.m OCPet.o OCArray.o
    6. $(CC) $(CFLAGS) main.m OCPet.o OCString.o OCArray.o OCObject.o $(LDFLAGS)
    8. OCPet.o: OCPet.m OCPet.h OCString.o OCObject.o
    9. $(CC) -c OCPet.m
    11. OCString.o: OCObject.o OCString.h OCString.m
    12. $(CC) -c OCString.m
    14. OCArray.o: OCObject.o OCArray.m OCArray.h
    15. $(CC) -c OCArray.m
    17. OCObject.o: OCObject.h OCObject.m
    18. $(CC) -c OCObject.m
    20. clean:
    21. del *.o
    22. clear
    Alles anzeigen


    Ich würd gern die Zusatztargets (OCPet.o, OCString.o, OCObject.o) loswerden, so dass sich der Linker den ganzen Kram bitte aus dem Ordner 'precompiled' zusammensucht und verdrahtet.
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P

  • RE: Das leidige Thema: Objective-C und Redmonds Fenster

    Kannst mein Makefile verwendent, der macht alles von selbst und trackt sogar dependencies.
    Musst nur an einer Stelle die Dateien eintragen, welche kompiliert werden sollen..Musst natürlich noch für Deine Zwecke Compiler, Flags etc. anpassen..

    Brainfuck-Quellcode

    1. CXX=g++
    2. CXXFLAGS=-g -O0 -Wall -Wabi -Wextra -Wshadow
    4. CPPFLAGS= \
    5. -Iextlib/tiff-3.9.2/libtiff \
    6. -I/opt/local/include
    8. LDFLAGS= \
    9. -Lextlib \
    10. -L/opt/local/lib \
    11. -ltiff \
    12. -lz \
    13. -lcv -lcxcore -lhighgui
    15. BUILDDIR=obj
    16. #-------------------------------------------------------------------#
    17. SOURCES= \
    18. src/main.cpp
    19. #-------------------------------------------------------------------#
    20. OBJECTS=$(patsubst %.cpp, $(BUILDDIR)/%.o, $(filter %.cpp, $(SOURCES)))
    21. DEPS=$(patsubst %.cpp, $(BUILDDIR)/%.d, $(filter %.cpp, $(SOURCES)))
    25. all: $(OBJECTS)
    26. $(CXX) $(LDFLAGS) $(OBJECTS)
    28. $(BUILDDIR)/%.d: %.cpp $(BUILDDIR)/.dirs
    29. $(CXX) $(CPPFLAGS) -MM $< -MT '$(@:.d=.o) $@' > $@
    31. $(BUILDDIR)/%.o: %.cpp $(BUILDDIR)/.dirs
    32. $(CXX) $(CPPFLAGS) -c $(CXXFLAGS) $< -o $@
    34. $(BUILDDIR)/.dirs:
    35. @mkdir -p $(foreach i, $(OBJECTS), $(dir $i))
    36. touch $@
    38. ifneq ($(MAKECMDGOALS),clean)
    39. -include $(DEPS)
    40. endif
    42. .PHONY: clean
    43. clean:
    44. @echo "Cleaning..."
    45. @rm -fv a.out
    46. @rm -fv $(OBJECTS)
    47. @rm -fv $(DEPS)
    48. @rm -rfv $(BUILDDIR)
    Alles anzeigen
    ♥C++

  • RE: Das leidige Thema: Objective-C und Redmonds Fenster

    Original von Lucas de Vil
    Hast du vielleicht eine Idee, wie ich die blöden Objekte nur einmal kompilieren und in einem Ordner ablegen kann und dem Makefile dann erkläre, er solle alle benötigten Objekte zuerst in diesem Ordner suchen?

    Man definiert in so einem Fall Ruels für Patterns, dadurch muß man das nur einmal definieren. Make compiliert dann automatisch alle *.m zu *.o, die man für das Target angibt. GNUmake hat bereits eine ganze Reihe von Standardvorgaben, einfach mal anschauen das ganze "make -p".

    Quellcode

    1. CC = gcc
    2. CFLAGS = -Wall -Werror -O0
    3. LDFLAGS = -lobjc
    4. TARGET = ../_build/RCTest/app.exe
    5. OBJS = main.o OCPet.o OCArray.o OCString.o OCObject.o
    7. all: $(OBJS)
    8. $(CC) $(CFLAGS) $(LDFLAGS) $(OBJS) -o $(TARGET)
    10. %.0 : %.m
    11. $(CC) -c $(CFLAGS) $< -o $@
    13. clean:
    14. del *.o
    15. clear
    Alles anzeigen

    Das ganze ist jetzt nicht getestet.

  • Was für eine Standardbibliothek?
    Welche Standards sollte diese Bibliothek denn bedienen?

    Die Programmiersprache ist vollständig und uneingeschränkt einsetzbar.
    Nur halt gänzlich ohne Frameworks. ;) An denen bastelt aber beispielsweise GNUStep mehr oder minder fleißig.
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P

  • Original von -Nuke-
    Original von Lucas de Vil
    Ist also recht übersichtlich gehalten.


    Danke für die Info. :)

    Da hat man wohl verschlafen eine Standard-Bibliothek zu erschaffen ^^

    Die Header werden vom Compiler benutzt. Du musst sie nicht einbinden. Das macht der Compiler.

    Du kannst also bei 0 anfangen, hast dann allerdings das Problem, dass das Laufzeitsystem ein paar Methoden benötigt (-methodSignaturForSelector: usw.)
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?