gnustep-dev
[Top][All Lists]
Advanced

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

Re: Building core/make, core/base and objc2 for OS X


From: Frank Rehwinkel
Subject: Re: Building core/make, core/base and objc2 for OS X
Date: Fri, 24 May 2013 20:33:05 -0400

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 <address@hidden> wrote:
On Fri, May 24, 2013 at 9:59 PM, Frank Rehwinkel <address@hidden> 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 address@hidden to the To: list?

That's right. Use the reply-to-all functionality or add "address@hidden" 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 - address@hidden



reply via email to

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