[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: OS X and gnustep-base 1.21.1
From: |
Ivan Vučica |
Subject: |
Re: OS X and gnustep-base 1.21.1 |
Date: |
Mon, 11 Apr 2011 21:34:47 +0200 |
Hi,
Is someone from the core team try to work on this?
If so, it may be also nice to make an official prerelease when done, so users
on Mac can run something more modern more easily.
If not, I have a few ideas I might try to implement (but if anyone is willing
to try them out before me, feel free to, I'm not sure when I'll be working on
this)
Regarding 1, we should probably enforce inclusion of stuff in
/opt/local/lib/gcc44/gcc/x86_64-apple-darwin10/4.4.5/include prior to anything
in /usr/include via change to CFLAGS or something similar. That should fix the
problem.
Regarding 2, we could fix this by explicitly adding that directory to the
include path. It's unfortunate that under MacPorts, a nonstandard directory is
selected for gnu runtime's objc files.
Regarding 3, this looks like the most technical one to me. It doesn't seem like
blocks_runtime is conditionally trying to use x86_64 assembler. Could someone
(David?) comment on this one?
Problems 1 and 2 sound like they may require patching of config.make in
GNUstep's Makefiles directory post-installation of gnustep-base.
On 11. tra. 2011., at 06:40, Eric Wasylishen wrote:
> Hi,
>
> After getting GNUstep-base 1.19.1 working on OS X with macports thanks to
> Ivan's help, I decided to try base 1.21.1.
>
> I'm running in to some problems now in the ObjectiveC2 framework.
>
>
> 1. The Source/ObjectiveC2/Availability.h file conflicts with apple's in
> /usr/include.
> This is because:
> a) gnustep-make supplies -I. to gcc
> b) blocks_runtime.c includes stdlib.h
> c) apple's /usr/include/stdlib.h #includes <Availability.h>, which is in
> /usr/include, but the copy in Source/ObjectiveC2/ takes precedence because of
> the -I. This breaks some things in apple's stdlib.h
>
>
> 2. The #include <objc/objc.h> in runtime.c is a problem.
> I've learned that if gcc thinks it is compiling objective-c (i.e. .m file, or
> .c file with the -x objective-c flag), and it is passed the -fgnu-runtime
> flag, it will automatically add the
> /opt/local/lib/gcc44/gcc/x86_64-apple-darwin10/4.4.5/include-gnu-runtime/
> directory to the include path, so the #include <objc/objc.h> would pick up
> the right file. But, since runtime.c is a c file, this doesn't happen, and
> apple's objc.h in /usr/include/objc is picked up instead.
>
>
> 3. there's an error caused by the -march=i686 flag:
>
> 712 :info:build /opt/local/bin/gcc-mp-4.4 blocks_runtime.m -c \
> 713 :info:build -MMD -MP -I/opt/local/include -Wall
> -Wdeclaration-after-statement -DGNUSTEP -DGNUSTEP_BASE_LIBRARY=1 -DGNU_RUNTIM
> E=1 -DGNUSTEP_BASE_LIBRARY=1 -fno-common -Wall -DGSWARN -DGSDIAGNOSE
> -Wno-import -pipe -O2 -fno-strict-aliasing -fgnu-runtime -fgnu-run time
> -march=i686 -fconstant-string-class=NSConstantString
> -I../../Headers/Additions -I../. -I../ -I../../Headers -I. -I/opt/local/inclu
> de -I/opt/local/GNUstep/System/Library/Headers
> -I/opt/local/GNUstep/Local/Library/Headers
> -I/opt/local/GNUstep/Local/Library/Headers -I /opt/local/include/libxml2 \
> 714 :info:build -o obj/ObjectiveC2.obj/blocks_runtime.m.o
> 715 :info:build blocks_runtime.m:1: error: CPU you selected does not support
> x86-64 instruction set
>
> It goes away if I delete this part of Source/ObjectiveC2/GNUmakefile:
> 54 ifeq ($(GNUSTEP_TARGET_CPU), ix86)
> 55 ADDITIONAL_OBJCFLAGS += -march=i686
> 56 endif
>
> I'm not sure why the march=i686 was causing an error.
>
>
> It would be nice to get base 1.21.1 and more recent versions to work on OS X
> but I'm not sure if I can figure these out..
>
> Cheers,
> Eric
--
Ivan Vučica
address@hidden - http://ivan.vucica.net/
Coming soon for iPhone, Zombie Ball - http://j.mp/zbivmail
smime.p7s
Description: S/MIME cryptographic signature
Re: OS X and gnustep-base 1.21.1,
Ivan Vučica <=