Re: libs-base fails to compile on OpenBSD
Hi Riccardo, > The base configure script reports: > > 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 > > > checking whether objc really works... yes > checking if the compiler supports -fconstant-string-class... yes > checking if +load method is executed before main... yes > checking for objc_sync_enter... no > checking for objc_setProperty... no > checking for _Block_copy... no > checking for objc_setUncaughtExceptionHandler() in runtime... no > checking for objc_set_unexpected() in runtime... no > checking for _objc_unexpected_exception in runtime... no > configure: Disabling native Objective-C exceptions because the ObjC runtime > configure: has no way to set an uncaught exception handler. Please install > configure: a recent Objective-C runtime if you want to use them. > checking whether to enable native Objective-C exceptions... no > checking for objc_sync_enter... (cached) no > > > this looks all correct? However, afterwards it fails as we had past month: > > Compiling file runtime.c ... > runtime.c:35:27: fatal error: objc/objc-api.h: No such file or directory > #include >^ > compilation terminated. > > > You suggested this all should not be built at all, but which test is getting > confused? Looking at Source/GNUmakefile in base (at the very end) the ObjectiveC2 subproject, which is where runtime.c lives, is built only when the OBJC2RUNTIME makefile variable is set to 0 (meaning that you only have an old Objective-C runtime system, or rather the configure script was not able to identify your runtime system as being compatible with the newer runtime system): ifeq ($(OBJC2RUNTIME),0) SUBPROJECTS = ObjectiveC2 endif Going back to configure.ac then, OBJC2RUNTIME is set according to the presence of objc_setProperty. So the problem is this test: checking for objc_setProperty... no Wolfgang ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: libs-base fails to compile on OpenBSD
Hi Wolfgang, Wolfgang Lux wrote: Am 18.12.2018 um 22:01 schrieb Riccardo Mottola : 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 Right. The ObjectiveC2 library is supposed to provide a compatibility interface layer around the historic GNU runtime API, providing API calls compatible with Apple's new ObjectiveC-2 runtime API. This Objective-C runtime bundles with gcc has been updated in gcc 4.6 IIRC, so the ObjectiveC2 directory shouldn't be compiled in the first place when you are using anything newer than gcc 4.6. Perhaps there's an issue with the configure script so that the ObjectiveC2 library incorrectly gets compiled on your system? Let me resurrect this thread - I was busy and did not use OpenBSD for a while, now I wanted to and hit this issue again, I am on a different laptop (x64 vs x86) but that doesn't matter I suppose. renamed /usr/include/objc so that it is not found, I don't care about using the system compiler, I only want to use gcc from pkg (why it is 4.9, I don't know... OpenBSD decisions). For the record, the "make" configure line is: $ ./configure --prefix=/ --with-layout=gnustep CC=egcc CXX=eg++ LDFLAGS=-Wl,-R/usr/local/lib egcc being the name for the newer gcc installed. (4.9 that is). The objc is in: /usr/local/lib/gcc/x86_64-unknown-openbsd6.4/4.9.4/include/objc which is, AFAIK, correct. The base configure script reports: 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 checking whether objc really works... yes checking if the compiler supports -fconstant-string-class... yes checking if +load method is executed before main... yes checking for objc_sync_enter... no checking for objc_setProperty... no checking for _Block_copy... no checking for objc_setUncaughtExceptionHandler() in runtime... no checking for objc_set_unexpected() in runtime... no checking for _objc_unexpected_exception in runtime... no configure: Disabling native Objective-C exceptions because the ObjC runtime configure: has no way to set an uncaught exception handler. Please install configure: a recent Objective-C runtime if you want to use them. checking whether to enable native Objective-C exceptions... no checking for objc_sync_enter... (cached) no this looks all correct? However, afterwards it fails as we had past month: Compiling file runtime.c ... runtime.c:35:27: fatal error: objc/objc-api.h: No such file or directory #include ^ compilation terminated. You suggested this all should not be built at all, but which test is getting confused? 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 22:01 schrieb Riccardo Mottola : > > 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 Right. The ObjectiveC2 library is supposed to provide a compatibility interface layer around the historic GNU runtime API, providing API calls compatible with Apple's new ObjectiveC-2 runtime API. This Objective-C runtime bundles with gcc has been updated in gcc 4.6 IIRC, so the ObjectiveC2 directory shouldn't be compiled in the first place when you are using anything newer than gcc 4.6. Perhaps there's an issue with the configure script so that the ObjectiveC2 library incorrectly gets compiled on your system? Wolfgang ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
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
Re: libs-base fails to compile on OpenBSD
Hi Wolfgang, 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 ___ 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 05.12.2018 um 10:38 schrieb Riccardo Mottola : > > Hi Wolfgang, > > Wolfgang Lux wrote: >> I haven't been using OpenBSD for years, so I'm not sure why there is an >> /usr/include/objc header directory that does not match the compiler. But >> anyway, this is a problem that you'll see on every system where you use a >> gcc version which does not match the default compiler. Gcc knowns about the >> special directory containing the Objective-C headers and includes that in >> the default search path. However, that applies only to Objective-C files and >> not to plain C files like runtime.c. I think the best way to move forward >> would be renaming runtime.c into runtime.m so that this file gets compiled >> with the correct search path. > > it could be a trick... I think here it is a little more awkward, however: the > "pkg" gcc is in its own directory: > > /usr/local/lib/gcc/i386-unknown-openbsd6.4/4.9.4/include/objc/objc.h > > The system gcc, is system-wide in the search path: > /usr/include/objc/objc.h > > Now, I suppose the GCC trick is that including "objc.h" works correctly. > > However, if you include objc-api.h, which does not exist anylonger in more > recent versions of gcc, it will include the "Old" one because it is the only > one and it is in a valid search path, do you get my reasoning? 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. :-) Wolfgang ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: libs-base fails to compile on OpenBSD
Hi Wolfgang, Wolfgang Lux wrote: I haven't been using OpenBSD for years, so I'm not sure why there is an /usr/include/objc header directory that does not match the compiler. But anyway, this is a problem that you'll see on every system where you use a gcc version which does not match the default compiler. Gcc knowns about the special directory containing the Objective-C headers and includes that in the default search path. However, that applies only to Objective-C files and not to plain C files like runtime.c. I think the best way to move forward would be renaming runtime.c into runtime.m so that this file gets compiled with the correct search path. it could be a trick... I think here it is a little more awkward, however: the "pkg" gcc is in its own directory: /usr/local/lib/gcc/i386-unknown-openbsd6.4/4.9.4/include/objc/objc.h The system gcc, is system-wide in the search path: /usr/include/objc/objc.h Now, I suppose the GCC trick is that including "objc.h" works correctly. However, if you include objc-api.h, which does not exist anylonger in more recent versions of gcc, it will include the "Old" one because it is the only one and it is in a valid search path, do you get my reasoning? I think we should include the "right" system headers in runtime, perhaps some should not be included or we should have some sort of "if gcc < XX" include one set, else other set (I don't know which version9. Instead, we check header-per-header and "somewhere" they will be found and then pulled in. I am sure thus your .m trick would work? 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 02.12.2018 um 18:12 schrieb Wolfgang Lux : > > > >> Am 02.12.2018 um 17:28 schrieb Riccardo Mottola : >> >> Sebastian Reitenbach wrote: >>> What platform are you on? Why don’t you take the path the packages take and >>> use base clang, and libobjc2? >> >> because libobjc2 I always have issues with that setup or clang or something. >> >> I like to use GCC and its runtime. >> >>> I definitely don’t recommend to use the system libobjc, at least you seem >>> to pick up system libobjc headers. >> >> You have a point here, it is not picking up the correct headers - I am not >> using the system GCC but the one from packages (gcc 4.9) which is a perfctly >> fine runtime and which worked in OpenBSD 6.3 (as well as on many other >> systems, FreeBSD, Linux... etc) >> >> With GCC no extra path is needed usually, it should just pick up "its own" >> runtime" > > I haven't been using OpenBSD for years, so I'm not sure why there is an > /usr/include/objc header directory that does not match the compiler. But > anyway, this is a problem that you'll see on every system where you use a gcc > version which does not match the default compiler. Gcc knowns about the > special directory containing the Objective-C headers and includes that in the > default search path. However, that applies only to Objective-C files and not > to plain C files like runtime.c. I think the best way to move forward would > be renaming runtime.c into runtime.m so that this file gets compiled with the > correct search path. Or alternatively, we could make use of the hack I've added to gnustep-make years ago to allow compiling the gnu-gnu-gnu combo on macOS, which tries to find out the directory where the Objective-C runtime headers are installed and adds those to the compilation flags for C files. Wolfgang ___ 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 02.12.2018 um 17:28 schrieb Riccardo Mottola : > > Sebastian Reitenbach wrote: >> What platform are you on? Why don’t you take the path the packages take and >> use base clang, and libobjc2? > > because libobjc2 I always have issues with that setup or clang or something. > > I like to use GCC and its runtime. > >> I definitely don’t recommend to use the system libobjc, at least you seem to >> pick up system libobjc headers. > > You have a point here, it is not picking up the correct headers - I am not > using the system GCC but the one from packages (gcc 4.9) which is a perfctly > fine runtime and which worked in OpenBSD 6.3 (as well as on many other > systems, FreeBSD, Linux... etc) > > With GCC no extra path is needed usually, it should just pick up "its own" > runtime" I haven't been using OpenBSD for years, so I'm not sure why there is an /usr/include/objc header directory that does not match the compiler. But anyway, this is a problem that you'll see on every system where you use a gcc version which does not match the default compiler. Gcc knowns about the special directory containing the Objective-C headers and includes that in the default search path. However, that applies only to Objective-C files and not to plain C files like runtime.c. I think the best way to move forward would be renaming runtime.c into runtime.m so that this file gets compiled with the correct search path. Wolfgang ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: libs-base fails to compile on OpenBSD
Sebastian Reitenbach wrote: What platform are you on? Why don’t you take the path the packages take and use base clang, and libobjc2? because libobjc2 I always have issues with that setup or clang or something. I like to use GCC and its runtime. I definitely don’t recommend to use the system libobjc, at least you seem to pick up system libobjc headers. You have a point here, it is not picking up the correct headers - I am not using the system GCC but the one from packages (gcc 4.9) which is a perfctly fine runtime and which worked in OpenBSD 6.3 (as well as on many other systems, FreeBSD, Linux... etc) With GCC no extra path is needed usually, it should just pick up "its own" runtime" Making all for subproject ObjectiveC2... egcc runtime.c -c \ -MMD -MP -Wall -Wdeclaration-after-statement -DGNUSTEP -DGNUSTEP_BASE_LIBRARY=1 -DGNU_RUNTIME=1 -DGNUSTEP_BASE_LIBRARY=1 -pthread -pthread -fPIC -Wall -DGSWARN -DGSDIAGNOSE -Wno-import -g -O2 -I/System/Library/Headers/ObjectiveC2 -I../. -I../ -I../../Headers -I. -I/home/multix/GNUstep/Library/Headers -I/Local/Library/Headers -I/System/Library/Headers -I/usr/local/include -I/Local/Library/Headers -I/Local/Library/Headers -I/System/Library/Headers -I/usr/local/include -I/usr/local/include/libxml2 -I/usr/local/include -I/usr/local/include -I/usr/local/include/p11-kit-1 \ -o obj/ObjectiveC2.obj/runtime.c.o In file included from runtime.c:35:0: /usr/include/objc/objc-api.h:365:1: error: unknown type name 'retval_t' retval_t objc_msg_sendv(id, SEL, arglist_t); ^ /usr/include/objc/objc-api.h:365:34: error: unknown type name 'arglist_t' retval_t objc_msg_sendv(id, SEL, arglist_t); If I look for the file, rohan$ sudo find /usr -name objc-api.h /usr/include/objc/objc-api.h /usr/src/gnu/gcc/libobjc/objc/objc-api.h /usr/src/gnu/lib/libobjc/libobjc/objc/objc-api.h which is the standard file! however, if I look for objc.h, I find "both" versions: rohan$ sudo find /usr -name objc.h /usr/include/objc/objc.h /usr/local/lib/gcc/i386-unknown-openbsd6.4/4.9.4/include/objc/objc.h /usr/src/gnu/gcc/libobjc/objc/objc.h /usr/src/gnu/lib/libobjc/libobjc/objc/objc.h objc-api.h seems to have disappeared! But I checked against latest gcc8 on debian linux and the file is not there. Perhaps we should not include it at all? Or stop including it from a certain version of GCC onwards because it does not exist? I can skip that, but then I hit another header... and then redefinitions. I actually wonder how this all worked before. It looks as if there is only one compiler, it works, but if two are installed, a mess ! 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
Hi Sent from my iPhone > On 2. Dec 2018, at 14:30, Riccardo Mottola wrote: > > Hi, > > I just upgraded OpenBSD to 6.4, including all packages. > The compiler did not change in revision, I guess it was just updated, so gcc > is still 4.9 from ports. > > I recompile GNUstep from scratch and it fails: > What platform are you on? Why don’t you take the path the packages take and use base clang, and libobjc2? I definitely don’t recommend to use the system libobjc, at least you seem to pick up system libobjc headers. Sebastian > Compiling file runtime.c ... > In file included from runtime.c:35:0: > /usr/include/objc/objc-api.h:365:1: error: unknown type name 'retval_t' > retval_t objc_msg_sendv(id, SEL, arglist_t); > ^ > /usr/include/objc/objc-api.h:365:34: error: unknown type name 'arglist_t' > retval_t objc_msg_sendv(id, SEL, arglist_t); > ^ > /usr/include/objc/objc-api.h:440:33: error: unknown type name 'MetaClass' > Method_t class_get_class_method(MetaClass _class, SEL aSel); > ^ > /usr/include/objc/objc-api.h: In function 'class_get_class_name': > /usr/include/objc/objc-api.h:476:10: error: dereferencing pointer to > incomplete type >return CLS_ISCLASS(_class)?_class->name:((_class==Nil)?"Nil":0); > > > > > I suspect something wrong in gcc, but since it stayed to the same version > since previous OpenBSD, I do wonder! > > Riccardo > > ___ > Gnustep-dev mailing list > Gnustep-dev@gnu.org > https://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
libs-base fails to compile on OpenBSD
Hi, I just upgraded OpenBSD to 6.4, including all packages. The compiler did not change in revision, I guess it was just updated, so gcc is still 4.9 from ports. I recompile GNUstep from scratch and it fails: Compiling file runtime.c ... In file included from runtime.c:35:0: /usr/include/objc/objc-api.h:365:1: error: unknown type name 'retval_t' retval_t objc_msg_sendv(id, SEL, arglist_t); ^ /usr/include/objc/objc-api.h:365:34: error: unknown type name 'arglist_t' retval_t objc_msg_sendv(id, SEL, arglist_t); ^ /usr/include/objc/objc-api.h:440:33: error: unknown type name 'MetaClass' Method_t class_get_class_method(MetaClass _class, SEL aSel); ^ /usr/include/objc/objc-api.h: In function 'class_get_class_name': /usr/include/objc/objc-api.h:476:10: error: dereferencing pointer to incomplete type return CLS_ISCLASS(_class)?_class->name:((_class==Nil)?"Nil":0); I suspect something wrong in gcc, but since it stayed to the same version since previous OpenBSD, I do wonder! Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
