|
From: | Riccardo Mottola |
Subject: | Re: libobjc2-clang |
Date: | Mon, 29 Jun 2020 23:23:01 +0200 |
User-agent: | Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0 SeaMonkey/2.53.2 |
Hi Wolfgang.good news that you are able to reproduce this. It means it is not just a red herring of my setup!
Wolfgang Lux wrote:
Apparently it is not even defined, but this is strange, since I compiled with OLDABI_COMPAT: I tried being more explicit: (gdb) b loader.c:328 Breakpoint 3 at 0x72b92fe1859f: file /home/multix/code/gnustep-vcs/libobjc2/loader.c, line 330. and re-run the program, it does not get into that function, so we can assume it is new code.Anyway, I was able to reproduce this issue on NetBSD 9. First of all getting the configuration right seems to be a royal PITA. So what I did was: 1. Configure libobjc2 with cmake -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -DCXX_RUNTIME_LIB=/usr/lib/libstdc++.so -DCMAKE_BUILD_TYPE=RelWithDebInfo The CXX_RUNTIME_LIB option is necessary because cmake by default wants to use /usr/lib/libsupc++.a (as Riccardo already noticed earlier). The CMAKE_BUILD_TYPE is only necessary to debug the runtime itself (but that was of course necessary in this case). 2. Configure gnustep-make with ./configure CC=clang CXX=clang --with-layout=gnustep --with-library-combo=ng The --with-library-combo option (yes, ng is sufficient, it's an alias for ng-gnu-gnu) is necessary to detect the new runtime system. ISTR, that this would be detected automatically when configuring with clang, but apparently it didn't work for me on NetBSD.
Also on FreeBSD.. and generally I found that it is best to set clang+ng. Otherwise you get the compatibility gnu runtine. I always hoped David would fix it... I'd like to see if I can use libobjc2 with gcc, but that is completely another story.
3. Install GNU binutils via pkgin, because the NetBSD loader seems to generate invalid objects files for subprojects, too.
Yes that is mandatory to get the gold linker too!
4. Build gnustep-base and gnustep-back with the command env AUXILIARY_LDFLAGS=-fuse-ld=/usr/pkg/gnu/bin/ld.gold make to make clang use gold instead of the standard linker. You can use AUXILIARY_LDFLAGS=-fuse-ld=/usr/pkg/gnu/bin/ld.gold make instead if you're not using a csh as I do.
I think I only set this for lobobjc2.. or anyway had to set the linker extra, I set it.
This was at least enough to get Ink compiled and running. I'm still facing problems with my favorite toy project StepTalk because apparently it doesn't get the compilation flags right and misses out the dependent libraries on at least the StepTalk framework itself. In effect that means that the framework can be initialized before gnustep-base and hence all protocols have their isa pointer set to 0, which obviously causes problems later.
I have most applications running.. only SWK+Vespucci give this strange errors. This linker differences are perhaps also the issues Patrick is seeing? I do wonder.
Anyway, do you have further ideas on this strange failure? does it happen for any other app? Ink is working, but the rest?
Also, another bad news- since David asked me. No Valgrind on NetBSD/amd64. There was a port for i386 but never made it in the official tree. To "linux-like" apparently.
Riccardo
[Prev in Thread] | Current Thread | [Next in Thread] |