Re: win32 show-stoppers

[Hovik Melikyan]

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 <address@hidden> 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 <address@hidden> 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
>> <address@hidden> 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
>>> <address@hidden> 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 <address@hidden> wrote:
>>>>> On 20 Dec 2014, at 13:35, Hovik Melikyan <address@hidden> 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
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/gnustep-dev
>
>
> -- Sent from my STANTEC-ZEBRA
>

mingw32.patch
Description: Binary data