Re: libs-base fails to compile on OpenBSD
Hi Fred, Fred Kiefer wrote: Riccardo, you seem to be missing out on the underlying problem that Wolfgang tried to explain. For the GNUstep base library there are two cases which are supported. Either a new Obj-C runtime is installed on your machine then this gets used and the GNUstep additions won’t be needed. Or you only have an old Obj-C runtime, then the additions get compiled so that base is able to use the new functions although the runtime does not provide them. In your case a new runtime and an old one are present. Somehow both are detected and the additions get compiled against the new runtime. This has never been supported and is totally useless. Your unusual setup seem to trigger a bug in the configurations scripts where the wrong runtime gets used to decide whether or not to compile the additions. The best you could do now is just to remove the old runtime and everything should be detected correctly. I may be stubborn, but I do not understand where I have the "new" runtime. I have on my system two runtimes 1) old GCC 4.2 runtime installed in "system" /usr/include 2) newer GCC 4.9 runtime installed in /usr/local I do not have a the libobjc-2 runtime installed at all. removing the system one is not trivial, but for the sake of testing, I renamed /usr/include/objc so that it doesn't get found. I rerun configure, this is the output: checking the Objective-C runtime... GNU checking for custom shared objc library... NONE checking objc/runtime.h usability... yes checking objc/runtime.h presence... yes checking for objc/runtime.h... yes checking objc/objc.h usability... yes checking objc/objc.h presence... yes checking for objc/objc.h... yes this sounds plausible. Compilation fails: Making all for subproject ObjectiveC2... Compiling file runtime.c ... runtime.c:35:27: fatal error: objc/objc-api.h: No such file or directory #include ^ compilation terminated. which is expected, the gcc 4.9 runtime does not have that file... nor does it have gcc 6.5 or 8.2 Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: libs-base fails to compile on OpenBSD
> Am 18.12.2018 um 00:55 schrieb Riccardo Mottola : > Wolfgang Lux wrote: >> To be honest, no. The runtime.c file unconditionally includes objc-api.h, so >> it's obviously not supposed to compiled with a compiler that lacks the >> objc-api.h header file. So it doesn't really matter if the compiler would >> find the header from a different compiler version because the file shouldn't >> be compiled in the first place.:-) > > indeed this is tricky. > > First I tried renaming runtime.c to runtime.m and compile it with ObjC. > > It does not fix the issue. > > then I tried including thr.h instead of objc-api.h and thr.h, but it is not > enough, one symbnol I miss is in runtime.h > If I include that, I get tons of redefinitions, likle this: > > In file included from runtime.m:36:0: > /usr/local/lib/gcc/i386-unknown-openbsd6.4/4.9.4/include/objc/runtime.h:284:20: > error: conflicting types for 'object_getIndexedIvars' > objc_EXPORT void * object_getIndexedIvars (id object); >^ > > > I wonder a bit what kind of magic we are doing there: I actually wonder how > it works elsewhere where I use even more modern GCC. Riccardo, you seem to be missing out on the underlying problem that Wolfgang tried to explain. For the GNUstep base library there are two cases which are supported. Either a new Obj-C runtime is installed on your machine then this gets used and the GNUstep additions won’t be needed. Or you only have an old Obj-C runtime, then the additions get compiled so that base is able to use the new functions although the runtime does not provide them. In your case a new runtime and an old one are present. Somehow both are detected and the additions get compiled against the new runtime. This has never been supported and is totally useless. Your unusual setup seem to trigger a bug in the configurations scripts where the wrong runtime gets used to decide whether or not to compile the additions. The best you could do now is just to remove the old runtime and everything should be detected correctly. Hope this helps, Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
