Hi David
Okay, experimentation is perfectly fine by me.
I've tried a few ways to compile the libobjc2. None of my results were
successful - should I file a bug report? My results are included below.
Cheers
Chris
-------------
Using Debian Linux 5.0 on x86
* Compiling with clang r82855; copying over the unwind.h from GCC
(Debian 4.3.2-1.1) 4.3.2
I get a failure in exception.c with the errors:
ch...@debian:~/gnustep/libobjc2/trunk$ make
This is gnustep-make 2.2.0. Type 'make print-gnustep-make-help' for
help.
Making all for library libobjc...
Compiling file exception.c ...
In file included from exception.c:27:
./unwind.h:46:46: error: unknown machine mode '__unwind_word__'
typedef unsigned _Unwind_Word
__attribute__((__mode__(__unwind_word__)));
^
./unwind.h:47:45: error: unknown machine mode '__unwind_word__'
typedef signed _Unwind_Sword __attribute__((__mode__(__unwind_word__)));
^
./unwind.h:245:4: error: #error "__SIZEOF_LONG__ macro not defined"
#error "__SIZEOF_LONG__ macro not defined"
^
./unwind.h:249:4: error: #error "__SIZEOF_POINTER__ macro not defined"
#error "__SIZEOF_POINTER__ macro not defined"
^
In file included from exception.c:28:
./unwind-pe.h:65:18: error: typedef redefinition with different types
('intptr_t' (aka 'int') vs 'long')
typedef intptr_t _sleb128_t;
^
In file included from exception.c:27:
./unwind.h:262:16: note: previous definition is here
typedef long _sleb128_t;
^
In file included from exception.c:28:
./unwind-pe.h:66:19: error: typedef redefinition with different types
('uintptr_t' (aka 'unsigned int') vs 'unsigned long')
typedef uintptr_t _uleb128_t;
^
In file included from exception.c:27:
./unwind.h:263:25: note: previous definition is here
typedef unsigned long _uleb128_t;
^
8 diagnostics generated.
make[2]: *** [obj/exception.c.o] Error 1
make[1]: *** [internal-library-all_] Error 2
make: *** [libobjc.all.library.variables] Error 2
* Compiling with clang r82855; copying over the unwind.h header from
GCC (4.1.3 20080704 (prerelease) (Debian 4.1.2-25))
Compiles successfully however seems to be unusable because I'm unable
to get the ./configure script to work with gnustep-base (it fails with
a whole series of link errors). If I run ldd -r on the libobjc.so
created by clang I get:
undefined symbol: objc_read_string (obj/libobjc.so)
undefined symbol: objc_read_int (obj/libobjc.so)
undefined symbol: __objc_write_selector (obj/libobjc.so)
undefined symbol: pthread_mutexattr_settype (obj/libobjc.so)
undefined symbol: objc_read_unsigned_long (obj/libobjc.so)
undefined symbol: objc_read_unsigned_int (obj/libobjc.so)
undefined symbol: objc_read_char (obj/libobjc.so)
undefined symbol: pthread_mutexattr_destroy (obj/libobjc.so)
undefined symbol: __objc_write_class (obj/libobjc.so)
undefined symbol: __objc_get_forward_imp (obj/libobjc.so)
undefined symbol: objc_read_long (obj/libobjc.so)
undefined symbol: pthread_mutexattr_init (obj/libobjc.so)
undefined symbol: __objc_write_object (obj/libobjc.so)
undefined symbol: objc_read_unsigned_short (obj/libobjc.so)
undefined symbol: objc_read_unsigned_char (obj/libobjc.so)
undefined symbol: __builtin_extend_pointer (obj/libobjc.so)
undefined symbol: objc_read_short (obj/libobjc.so)
linux-gate.so.1 => (0xb7ee7000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7eb6000)
libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7d5b000)
/lib/ld-linux.so.2 (0xb7ee8000)
* Compiling with GCC (Debian 4.3.2-1.1) 4.3.2
I get the following errors:
ch...@debian:~/gnustep/libobjc2/trunk$ make
This is gnustep-make 2.2.0. Type 'make print-gnustep-make-help' for
help.
Making all for library libobjc...
Compiling file archive.c ...
Compiling file class.c ...
Compiling file encoding.c ...
Compiling file exception.c ...
In file included from exception.c:28:
unwind-pe.h:65: error: conflicting types for ‘_sleb128_t’
/usr/lib/gcc/i486-linux-gnu/4.3.2/include/unwind.h:262: error:
previous declaration of ‘_sleb128_t’ was here
unwind-pe.h:66: error: conflicting types for ‘_uleb128_t’
/usr/lib/gcc/i486-linux-gnu/4.3.2/include/unwind.h:263: error:
previous declaration of ‘_uleb128_t’ was here
make[2]: *** [obj/exception.c.o] Error 1
make[1]: *** [internal-library-all_] Error 2
make: *** [libobjc.all.library.variables] Error 2
On 04/10/2009, at 5:16 PM, David Chisnall wrote:
Hi Chris,
It doesn't build yet with clang because of the missing header. You
can try grabbing it from GCC, or building with GCC. To use the
newer features, you will need to compile Objective-C code with clang
-fobjc-nonfragile-abi, but the library itself can be built with GCC.
Please also be aware that it is still in active development. I may
still change the non-fragile ABI between now and the first official
release. There are probably still bugs that may break things for
you. There are a lot of compiler flags set in the default build
that make it easier for me to track down bugs, but are going to make
things very slow (for example, message sends call a few functions
that are inlined normally, but the default compile flags at the
moment disable inlining, so message sends are quite a lot slower
than they would be with an optimised build). Until the first
release, I wouldn't recommend it for anything other than
experimenting.
David
On 4 Oct 2009, at 16:03, Christopher Armstrong wrote:
Hi David
Thanks for tracking this down so quickly.
I realised that I forgot to mention that I'm using clang (r82855)
to compile it with (I presume that you need clang to compile code
that uses libobjc2?). If I search the headers included with llvm,
its not present. I didn't assume I should use GCC to compile
libobjc2, because as suggested by Matt Rice, and now by yourself,
its included with gcc (on my system at /usr/lib/gcc/i486-linux-gnu/
4.3/include/unwind.h).
I've tried with your fix, but because its not included with llvm,
obviously I'm going to have to either use GCC or include this
header somehow.
Cheers
Chris
On 04/10/2009, at 4:57 PM, David Chisnall wrote:
Ah, well spotted. I've fixed that now. Libobjc was originally
intended to be built as part of gcc (modularity is not something
that gcc team are big fans of) and so used "unwind.h" to make sure
it picked up the version of the header provided by GCC, not the
one provided by the system, which is the exact opposite of what we
want.
David
On 4 Oct 2009, at 15:52, Matt Rice wrote:
On Sun, Oct 4, 2009 at 7:30 AM, David Chisnall
<thera...@sucs.org> wrote:
Hi Chris,
It's a private GCC header which, unfortunately, varies a little
bit between
platforms. I'm a bit surprised it isn't found for you; it has
been on all
of the platforms that I've tried so far, but in some uleb128 is
defined and
in others it isn't. I plan on removing this dependency soon,
because the
unwind headers just contain copies of the functions from the ABI
specification (which doesn't seem to stop the FSF from slapping
a GPL header
on them).
Yeah, i thought it referred to that unwind.h,
the use of "unwind.h" made me wonder though, why not <unwind.h>?
http://packages.debian.org/lenny/gcc-3.4
http://packages.debian.org/lenny/gcc-4.1
http://packages.debian.org/lenny/gcc-4.2
http://packages.debian.org/lenny/gcc-4.3
all of the 'list of files' links i've followed from those contain
the header.
e.g.
http://packages.debian.org/lenny/sparc/gcc-4.3/filelist
http://packages.debian.org/sid/mips/gcc-4.1/filelist
http://packages.debian.org/squeeze/mipsel/gcc-4.1/filelist
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
-- Sent from my brain
--------
Christopher Armstrong
carmstr...@fastmail.com.au
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
-- Sent from my PDP-11
--------
Christopher Armstrong
carmstr...@fastmail.com.au
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev