gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: libs-base fails to compile on OpenBSD


From: Riccardo Mottola
Subject: Re: libs-base fails to compile on OpenBSD
Date: Wed, 5 Dec 2018 10:38:37 +0100
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.4

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]