Re: OS X and gnustep-base 1.21.1

[Ivan Vučica]

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