Hi David, The attached patch completes the MinGW 32-bit port, plus it has some bits for MinGW 64-bit and also some trivial fixes for OS X 32-bit.
The weak linking problem is solved by walking through the loaded DLLs at run time. This is done only once upon the first call to __cxa_begin_catch. The story with MinGW64 is this: I have the impression clang is not quite ready yet. Unfortunately my knowledge of EH personality stuff is virtually zero, but as I understand it, the fact that clang emits __gcc_personality_v0 (i.e. Dwarf2 model) on MinGW64 is just not right. The SEH patent has expired and there is mentioning on the internet that some work on llvm/clang is underway, but in any case it doesn't work out of the box. Unless of course I'm missing something. (In the meantime I have also ported GNUstep Base and packaged it together with libobjc2 into something I call Subjective: https://github.com/crontab/Subjective The idea is that you can have non-GUI runtime for Objective-C on WIndows and that you don't need the (overengineered) GNUstep build system for building it; simple makefiles are provided instead.) -- H.M. On Tue, Dec 30, 2014 at 6:27 PM, David Chisnall <thera...@sucs.org> wrote: > The windows version of dlsym (look up function by name at run time) could > probably be used here instead. On Windows, change the declarations of these > functions to function pointers and in the global init function, have some > code that looks up whether they're present. The rest of the logic can remain > the same. > > David > > On 30 Dec 2014, at 14:49, Hovik Melikyan <hovik.melik...@gmail.com> wrote: > >> Hi All, >> >> I need help with this last major thing to complete the Windows port of >> libobjc2. Someone knowledgeable in the GNU ld on Windows might be able >> to say what to do... >> >> This: >> >> __attribute__((weak)) void *__cxa_begin_catch(void *e); >> >> is supposed to link the function if it's available at run time and >> keep it NULL otherwise. The idea is that if you are compiling a pure >> Obj-C source (as in not C++) then this function shouldn't be called by >> libobjc2, thus NULL is fine. >> >> This doesn't work on Windows. Even if you link against libstdc++ this >> function address remains NULL at runtime and consequently your program >> crashes on a C++ exception. >> >> nm shows that this (and a few other) functions are marked as weak in >> the object. Also the fact that it stays NULL means the loader kind of >> "gets" it that it's a weak symbol. So what's the mechanism of >> resolving it at run time on Windows? >> >> One possibility I'm thinking of is to check one of these functions for >> NULL at run time (just __cxa_begin_catch should be enough because it's >> called first) then do LoadModule() etc. Somehow intuitively this >> doesn't feel right, although can be used as a last resort. >> >> Alternatively these symbols can be resolved at link time, which is >> what I do now. This is fine with me, but some might not like it. >> >> Any ideas? >> >> >> -- >> H.M. >> >> >> On Sun, Dec 21, 2014 at 11:32 AM, Hovik Melikyan >> <hovik.melik...@gmail.com> wrote: >>> Hi All, >>> >>> Current status of the libobjc2 MinGW (32-bit) port: >>> >>> 1. Everything compiles and runs, except there is one test that fails: >>> PropertyIntrospectionTest2. It fails even on my OSX and it appears to >>> be a bug in the test itself. Haven't fixed this yet. >>> >>> 2. There is a somewhat ugly hack that solves one of the problems with >>> exceptions: clang++ is always invoked at linking stage instead of >>> clang. I think it's a question of library ordering (because adding >>> -lstdc++ doesn't help), need to look closer at this. But at this time >>> I think theoretically there is no harm in using clang++ for linking >>> everything. Unfortunately there is another related hack, even uglier: >>> >>> 3. The __cxa_* external symbols are declared as __attribute__((weak)) >>> in libobjc. The idea is that if you are building Objective-C++ source >>> then the symbols will be found at run time, otherwise they won't be >>> called anyway. Unfortunately though this attribute either doesn't work >>> on MinGW or its semantics is different, because these symbols are not >>> resolved neither at compile time nor at run time, even if you link >>> against -lstdc++ dynamically or statically. So at the moment this hack >>> means you will have some C++ luggage linked even if your entire source >>> is pure Objective-C. >>> >>> 4. Shouldn't it be named to libobjc2.dll or something else to avoid >>> mixups on systems with GCC installed? Currently it's just libobjc.dll. >>> >>> 5. Installing and building: >>> >>> * Clone or download the fork from >>> https://github.com/crontab/libobjc2 >>> >>> * Install clang-3.5 >>> http://llvm.org/releases/download.html#3.5 >>> Preferable location is c:\LLVM >>> >>> * Install MinGW-32 + MSYS >>> http://sourceforge.net/projects/mingw/files/Installer/ >>> Make sure you have the gcc and pthreads packages >>> >>> * Download and compile CMake (under MinGW) >>> http://www.cmake.org/download/ >>> >>> * Build libobjc2: go to the source, then >>> mkdir Build ; cd Build >>> cmake .. -DCMAKE_C_COMPILER=/c/LLVM/bin/clang.exe \ >>> -DCMAKE_CXX_COMPILER=/c/LLVM/bin/clang++.exe \ >>> -G 'MinGW Makefiles' >>> # or add -DCMAKE_BUILD_TYPE=Debug for debug build >>> # You may need to run the above twice (a cmake glitch) >>> # Make sure pthread and the compilers are found >>> mingw32-make all test >>> >>> All comments and suggestions are welcome. Thanks! >>> >>> >>> -- >>> H.M. >>> >>> >>> On Sat, Dec 20, 2014 at 4:24 PM, Hovik Melikyan >>> <hovik.melik...@gmail.com> wrote: >>>> Hi David, >>>> >>>> The result will be a patch of course, this repository is just for >>>> convenience. There may be other contributors to the fork itself after >>>> all. Are there any legal or other issues with this? >>>> >>>> -- >>>> H.M. >>>> >>>> >>>> On Sat, Dec 20, 2014 at 4:17 PM, David Chisnall <thera...@sucs.org> wrote: >>>>> On 20 Dec 2014, at 13:35, Hovik Melikyan <hovik.melik...@gmail.com> wrote: >>>>> >>>>>> The fork is here: https://github.com/crontab/libobjc2 >>>>> >>>>> Is there a reason for forking the runtime, rather than contributing >>>>> patches? >>>>> >>>>> David >>>>> >>>>> -- Sent from my IBM 1620 >>>>> >> >> _______________________________________________ >> Gnustep-dev mailing list >> Gnustep-dev@gnu.org >> https://lists.gnu.org/mailman/listinfo/gnustep-dev > > > -- Sent from my STANTEC-ZEBRA >
mingw32.patch
Description: Binary data
_______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev