libs-base fails to compile on OpenBSD

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

libs-base fails to compile on OpenBSD

Riccardo Mottola-5
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);

<etc>


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
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

Re: libs-base fails to compile on OpenBSD

Sebastian Reitenbach-2
Hi



Sent from my iPhone

> On 2. Dec 2018, at 14:30, Riccardo Mottola <[hidden email]> 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);
>
> <etc>
>
>
> 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
> [hidden email]
> https://lists.gnu.org/mailman/listinfo/gnustep-dev


_______________________________________________
Gnustep-dev mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

Re: libs-base fails to compile on OpenBSD

Riccardo Mottola-5
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
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

Re: libs-base fails to compile on OpenBSD

Wolfgang Lux


> Am 02.12.2018 um 17:28 schrieb Riccardo Mottola <[hidden email]>:
>
> 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
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

Re: libs-base fails to compile on OpenBSD

Wolfgang Lux


> Am 02.12.2018 um 18:12 schrieb Wolfgang Lux <[hidden email]>:
>
>
>
>> Am 02.12.2018 um 17:28 schrieb Riccardo Mottola <[hidden email]>:
>>
>> 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
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

Re: libs-base fails to compile on OpenBSD

Riccardo Mottola-5
In reply to this post by Wolfgang Lux
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
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

Re: libs-base fails to compile on OpenBSD

Wolfgang Lux


> Am 05.12.2018 um 10:38 schrieb Riccardo Mottola <[hidden email]>:
>
> 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
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev