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 i...@vucica.net - http://ivan.vucica.net/ Coming soon for iPhone, Zombie Ball - http://j.mp/zbivmail
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev