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
