I've gotten past the header not being found. I think the important step
was to install objc2 as LOCAL. But oddly when I first did that, an error
about not finding gnustep-config occurred. So, having seen that from
core/make, I used the environment variables cooked up for core/base and
used them for the objc2 cmake/build/install steps. Maybe the correct
install order is core/make, then objc2, then core/base, but the objc2 cmake
step needs tests turned off because core/base hasn't been installed yet.
(The objc2 tests are on by default but they don't compile without core/base
installed as far as I can tell.)
Well, anyway, it is looking like some things have installed correctly. But
I also found I needed to put a user version of GNUstep.conf in
~/Library/.GNUstep.conf with the one line
export
GNUSTEP_MAKEFILES=/Users/frank/local/GNUstep/Library/GNUstep/Makefiles
So maybe I should have installed in ~/Library/GNUstep, instead of
~/local/GNUstep.
Anyway, now the GSObjCRuntime.m file from core/base/Source/Additions fails
to compile because it pulled in some of darwin's system header files.
There's probably a way around this because the GNUstep.sh makes reference
to darwin in several places and these headers files aren't new. Anyone
with an idea what I might have missed this time or how the GNUmake is meant
to avoid pulling in the system header files? Here are the first few
errors. Thanks.
Making all for subproject Additions...
Compiling file GSObjCRuntime.m ...
In file included from GSObjCRuntime.m:32:
In file included from .././common.h:31:
.././GNUstepBase/GSConfig.h:403:13: warning: '__weak' macro redefined
# define __weak
^
<built-in>:165:9: note: previous definition is here
#define __weak __attribute__((objc_gc(weak)))
^
In file included from GSObjCRuntime.m:32:
In file included from .././common.h:32:
In file included from ./GNUstepBase/GSVersionMacros.h:319:
/usr/local/include/objc/blocks_runtime.h:16:21: error: conflicting types
for '_Block_copy'
BLOCKS_EXPORT void *_Block_copy(void *);
^
/usr/include/Block.h:31:20: note: previous declaration is here
BLOCK_EXPORT void *_Block_copy(const void *aBlock)
^
In file included from GSObjCRuntime.m:32:
In file included from .././common.h:32:
In file included from ./GNUstepBase/GSVersionMacros.h:319:
/usr/local/include/objc/blocks_runtime.h:17:20: error: conflicting types
for '_Block_release'
BLOCKS_EXPORT void _Block_release(void *);
^
/usr/include/Block.h:35:19: note: previous declaration is here
BLOCK_EXPORT void _Block_release(const void *aBlock)
^
In file included from GSObjCRuntime.m:32:
In file included from .././common.h:32:
./GNUstepBase/GSVersionMacros.h:370:11: warning: 'NS_FORMAT_ARGUMENT' macro
redefined
# define NS_FORMAT_ARGUMENT(A) __attribute__((format_arg(A)))
^
/System/Library/Frameworks/Foundation.framework/Headers/NSObjCRuntime.h:94:10:
note: previous definition is here
#define NS_FORMAT_ARGUMENT(A) __attribute__ ((format_arg(A)))
^
On Fri, May 24, 2013 at 5:30 PM, Ivan Vučica <[email protected]> wrote:
> On Fri, May 24, 2013 at 9:59 PM, Frank Rehwinkel <[email protected]
> > wrote:
>
>> Points taken. I'm prepared for a little pain. I've installed objc2 now
>> (had to disable the tests) and see the header is installed in my local
>> directory where I want but still I get the header file missing (my local
>> directory isn't part of the include path yet I guess), even when I hack the
>> source to change the angle brackets to double quotes. So I have a little
>> more playing around to do before posting again.
>>
>
> There is a way to figure out what the compiler thinks the include path is.
> Unfortunately, I don't know it offhand. In any case, if libobjc2 is
> installed into /usr/local/include, not only should GNUstep be picking up on
> it, but so should other software. Which may be good or bad. :-)
>
> Don't forget to rebuild and reinstall gnustep-make, and re-source
> GNUstep.sh; the installed copy of gnustep-make is where the compiler
> configuration is stored and system configuration is described.
>
>
>> By the way, how do I reply to your post so it appears as part of the
>> thread? Is it enough that I reply from email and add [email protected]
>> the To: list?
>>
>
> That's right. Use the reply-to-all functionality or add "
> [email protected]" manually once you hit "reply". Nearly all email
> software should add enough headers to get Mailman and email clients to
> figure out it's a part of the same thread. Avoid changing the subject and
> that's it.
>
> --
> Ivan Vučica - [email protected]
>
>
_______________________________________________
Gnustep-dev mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
