You seem to be trying to compile Objective-C with something that is not an Objective-C compiler.
Try: $ mkdir Build $ cd Build $ cmake .. -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ $ make $ make install You may wish to run ccmake . after the cmake step to tweak any options (e.g. install locations). David On 6 Mar 2013, at 12:06, Laurent Michel <l...@engr.uconn.edu> wrote: > Hi David.... > > Found a git repo and cloned it. But the build fails. > > Tried > > cmake . > make > > Also tried > > mkdir Build > cd Build > cmake .. > make > > And tried > > cmake . > make CC=clang CXX=clang++ > > All end in the same way: > > (With the tarball version, all I did was make -f Makefile) > > /usr/local/src/gnustep-libobjc2/objc/message.h:44:6: note: > 'objc_msgSend_stret' is a builtin with type 'id (id, SEL, ...)' > 1 warning generated. > [ 26%] Building C object CMakeFiles/objc.dir/protocol.c.o > [ 28%] Building C object CMakeFiles/objc.dir/runtime.c.o > [ 29%] Building C object CMakeFiles/objc.dir/sarray2.c.o > [ 31%] Building C object CMakeFiles/objc.dir/selector_table.c.o > [ 32%] Building C object CMakeFiles/objc.dir/sendmsg2.c.o > [ 34%] Building C object CMakeFiles/objc.dir/statics_loader.c.o > [ 35%] Building C object CMakeFiles/objc.dir/toydispatch.c.o > [ 37%] Building ASM object CMakeFiles/objc.dir/block_trampolines.S.o > [ 39%] Building ASM object CMakeFiles/objc.dir/objc_msgSend.S.o > [ 40%] Building C object CMakeFiles/objc.dir/NSBlocks.m.o > gcc: error trying to exec 'cc1obj': execvp: No such file or directory > make[2]: *** [CMakeFiles/objc.dir/NSBlocks.m.o] Error 1 > make[1]: *** [CMakeFiles/objc.dir/all] Error 2 > make: *** [all] Error 2 > > > This is where I cloned from: > > root@ubuntu:/usr/local/src/gnustep-libobjc2# cat .git/config > [core] > repositoryformatversion = 0 > filemode = true > bare = false > logallrefupdates = true > [remote "origin"] > fetch = +refs/heads/*:refs/remotes/origin/* > url = git://github.com/gnustep/gnustep-libobjc2.git > [branch "master"] > remote = origin > merge = refs/heads/master > > > Wrong place ? > > > -- > Laurent > > On Mar 6, 2013, at 4:10 AM, David Chisnall <thera...@sucs.org> wrote: > >> Hi Laurent, >> >> This doesn't look like the code from trunk. Are you using an old release? >> As I said, I think this bug is fixed some months ago. >> >> David >> >> On 6 Mar 2013, at 01:12, Laurent Michel <l...@thorgal.homelinux.org> wrote: >> >>> David, >>> >>> I recompiled and here is the trace: >>> >>> Program received signal SIGSEGV, Segmentation fault. >>> 0xb7a55695 in isEmptyProtocol (aProto=0xb7736f90) at protocol.c:62 >>> 62 isEmpty &= (p2->properties->count == 0); >>> (gdb) where >>> #0 0xb7a55695 in isEmptyProtocol (aProto=0xb7736f90) at protocol.c:62 >>> #1 0xb7a5553e in unique_protocol (aProto=0xb7736f90) at protocol.c:118 >>> #2 0xb7a534eb in init_protocols (protocols=0xb7736fb0) at protocol.c:189 >>> #3 0xb7a534da in init_protocols (protocols=0xb773a0c0) at protocol.c:186 >>> #4 0xb7a5328a in objc_init_protocols (protocols=0xb773a0c0) at >>> protocol.c:196 >>> #5 0xb7a48264 in load_category (cat=0xb773a2c0, class=0xb7a64340) at >>> category_loader.c:38 >>> #6 0xb7a47f02 in try_load_category (cat=0xb773a2c0) at category_loader.c:50 >>> #7 0xb7a47e6a in objc_try_load_category (cat=0xb773a2c0) at >>> category_loader.c:63 >>> #8 0xb7a5143f in __objc_exec_class (module=0xb773a398) at loader.c:89 >>> #9 0xb76c55a4 in .objc_load_function () from >>> /home/ldm/work/platform/Clo/queens2/../ORFoundation/libORFoundation.so >>> #10 0xb7fece9b in ?? () from /lib/ld-linux.so.2 >>> #11 0xb7fecf84 in ?? () from /lib/ld-linux.so.2 >>> #12 0xb7fdf20f in ?? () from /lib/ld-linux.so.2 >>> >>> >>> So line 62. >>> >>> It won't show the variables though: >>> >>> (gdb) p *p2 >>> $3 = { >>> isa = 0xb7a642f0, >>> name = 0xb771df54 "ORExpr", >>> protocol_list = 0xb7795a18, >>> instance_methods = 0xb7795a20, >>> class_methods = 0xb7795a20, >>> optional_instance_methods = 0xb7795a20, >>> optional_class_methods = 0xb7795a20, >>> properties = 0x0, >>> optional_properties = 0x0 >>> } >>> (gdb) l >>> 57 if (aProto->isa == ObjC2ProtocolClass) >>> 58 { >>> 59 struct objc_protocol2 *p2 = (struct >>> objc_protocol2*)aProto; >>> 60 isEmpty &= (p2->optional_instance_methods->count == 0); >>> 61 isEmpty &= (p2->optional_class_methods->count == 0); >>> 62 isEmpty &= (p2->properties->count == 0); >>> 63 isEmpty &= (p2->optional_properties->count == 0); >>> 64 } >>> 65 return isEmpty; >>> 66 } >>> >>> So p2->properties is NULL and trying to access the count attribute crashes. >>> This is happening on a protocol >>> of mine (ORExpr) which inherits from other protocols: >>> >>> @protocol ORExpr <ORConstraint,NSObject,NSCoding> >>> -(id<ORTracker>) tracker; >>> -(ORInt) min; >>> -(ORInt) max; >>> -(BOOL) isConstant; >>> -(BOOL) isVariable; >>> >>> .... >>> >>> @end >>> >>> Any ideas? >>> >>> >>> On Mar 5, 2013, at 7:20 AM, Laurent Michel <l...@thorgal.homelinux.org> >>> wrote: >>> >>>> >>>> On Mar 5, 2013, at 4:10 AM, David Chisnall <thera...@sucs.org> wrote: >>>> >>>>> Hi, >>>>> >>>>> How old is your runtime? Without debugging symbols, this looks like it >>>>> might be a bug that was fixed in May last year. It would really help if >>>>> you could do a debug build of the runtime and let me know exactly what is >>>>> failing. If you do ccmake . in your libobjc2 build directory, and change >>>>> the build type to Debug, you should get the symbols. >>>> >>>> libobjc2 was 1.6.1 >>>> >>>> >>>> ldm@ubuntu:/usr/local/src/old$ sha1sum libobjc2-1.6.tar.gz >>>> 348ab64899b25ecb2bfdfd13ebeeab2d6a2c8988 libobjc2-1.6.tar.gz >>>> >>>> >>>> total 9196 >>>> drwxr-xr-x 4 root root 4096 Mar 4 08:37 GNUstep >>>> lrwxrwxrwx 1 root root 23 Mar 4 08:37 libgnustep-base.so -> >>>> libgnustep-base.so.1.24 >>>> lrwxrwxrwx 1 root root 25 Mar 4 08:37 libgnustep-base.so.1.24 -> >>>> libgnustep-base.so.1.24.3 >>>> -rwxr-xr-x 1 root root 9105637 Mar 4 08:36 libgnustep-base.so.1.24.3 >>>> -r--r--r-- 1 root root 136452 May 18 2012 libobjc.a >>>> lrwxrwxrwx 1 root root 31 May 18 2012 libobjc.so -> >>>> /usr/local/lib/libobjc.so.4.6.0 >>>> lrwxrwxrwx 1 root root 31 May 18 2012 libobjc.so.4 -> >>>> /usr/local/lib/libobjc.so.4.6.0 >>>> lrwxrwxrwx 1 root root 31 May 18 2012 libobjc.so.4.6 -> >>>> /usr/local/lib/libobjc.so.4.6.0 >>>> -r--r--r-- 1 root root 140820 May 18 2012 libobjc.so.4.6.0 >>>> lrwxrwxrwx 1 root root 33 May 18 2012 libobjcxx.so -> >>>> /usr/local/lib/libobjcxx.so.4.6.0 >>>> lrwxrwxrwx 1 root root 33 May 18 2012 libobjcxx.so.4 -> >>>> /usr/local/lib/libobjcxx.so.4.6.0 >>>> lrwxrwxrwx 1 root root 33 May 18 2012 libobjcxx.so.4.6 -> >>>> /usr/local/lib/libobjcxx.so.4.6.0 >>>> -r--r--r-- 1 root root 13002 May 18 2012 libobjcxx.so.4.6.0 >>>> drwxrwsr-x 4 root staff 4096 Mar 3 13:33 python2.7 >>>> ldm@ubuntu:/usr/local/lib$ >>>> >>>> I was looking yesterday night for a more recent tar ball, but couldn't >>>> locate one. >>>> >>>> I'll recompile libobjc2 in debug and will update you. Thanks for the info >>>> David! >>>> >>>> -- >>>> Laurent >>>> >>>> >>>>> >>>>> David >>>>> >>>>> On 5 Mar 2013, at 01:37, Laurent Michel <l...@engr.uconn.edu> wrote: >>>>> >>>>>> PS/ I decided to recompile GNUstep simply because I was experiencing a >>>>>> crash with my compiled binary during the >>>>>> library initializations of GNUstep/libobjc. Namely, here is the >>>>>> backtrace: >>>>>> >>>>>> [Thread debugging using libthread_db enabled] >>>>>> Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1". >>>>>> [New Thread 0xb7021b40 (LWP 8378)] >>>>>> >>>>>> Program received signal SIGSEGV, Segmentation fault. >>>>>> 0xb7a58d50 in init_protocols () from /usr/local/lib/libobjc.so >>>>>> (gdb) where >>>>>> #0 0xb7a58d50 in init_protocols () from /usr/local/lib/libobjc.so >>>>>> #1 0xb7a58c47 in init_protocols () from /usr/local/lib/libobjc.so >>>>>> #2 0xb7a588c1 in objc_init_protocols () from /usr/local/lib/libobjc.so >>>>>> #3 0xb7a517e3 in objc_try_load_category () from >>>>>> /usr/local/lib/libobjc.so >>>>>> #4 0xb7a57251 in __objc_exec_class () from /usr/local/lib/libobjc.so >>>>>> #5 0xb76d15d4 in .objc_load_function () from >>>>>> /home/ldm/work/platform/Clo/queens2/../ORFoundation/libORFoundation.so >>>>>> #6 0xb7fece9b in ?? () from /lib/ld-linux.so.2 >>>>>> #7 0xb7fecf84 in ?? () from /lib/ld-linux.so.2 >>>>>> #8 0xb7fdf20f in ?? () from /lib/ld-linux.so.2 >>>>>> (gdb) quit >>>>>> A debugging session is active. >>>>> >>>>> -- >>>>> This email complies with ISO 3103 >>>>> >>>>> >>>>> _______________________________________________ >>>>> Gnustep-dev mailing list >>>>> Gnustep-dev@gnu.org >>>>> https://lists.gnu.org/mailman/listinfo/gnustep-dev >>>> >>> >>> >>> _______________________________________________ >>> Gnustep-dev mailing list >>> Gnustep-dev@gnu.org >>> https://lists.gnu.org/mailman/listinfo/gnustep-dev >> >> >> >> >> -- Sent from my Difference Engine >> >> >> > > > _______________________________________________ > Gnustep-dev mailing list > Gnustep-dev@gnu.org > https://lists.gnu.org/mailman/listinfo/gnustep-dev -- Send from my Jacquard Loom _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev