Re: win32 show-stoppers

[David Chisnall]

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