Error compiling libobjc2 - unwind.h not found

[Christopher Armstrong-5]

I've been wanting to try out the new libobjc2 runtime (discussed at http://etoileos.com/news/archive/2009/09/10/1744/)
  that is in GNUstep SVN. I've compiled and installed gnustep-make  
from SVN, and now I'm trying to build libobjc2 but it fails with this  
error:

chris@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 ...
exception.c:27:10: fatal error: 'unwind.h' file not found
#include "unwind.h"
          ^
1 diagnostic generated.
make[2]: *** [obj/exception.c.o] Error 1
make[1]: *** [internal-library-all_] Error 2
make: *** [libobjc.all.library.variables] Error 2

I couldn't find unwind.h anywhere in the distribution, and it doesn't  
appear to be a public header on my system. Am I missing something  
before I try installing libobjc2? I have installed gnustep-make into a  
non-standard location, but I'm not sure how this would influence it.

Thanks
Chris

--------
Christopher Armstrong
carmstrong@...







_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@...
http://lists.gnu.org/mailman/listinfo/gnustep-dev

[David Chisnall]

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).

David

On 4 Oct 2009, at 15:19, Christopher Armstrong wrote:

> I've been wanting to try out the new libobjc2 runtime (discussed at http://etoileos.com/news/archive/2009/09/10/1744/ 
> ) that is in GNUstep SVN. I've compiled and installed gnustep-make  
> from SVN, and now I'm trying to build libobjc2 but it fails with  
> this error:
>
> chris@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 ...
> exception.c:27:10: fatal error: 'unwind.h' file not found
> #include "unwind.h"
>         ^
> 1 diagnostic generated.
> make[2]: *** [obj/exception.c.o] Error 1
> make[1]: *** [internal-library-all_] Error 2
> make: *** [libobjc.all.library.variables] Error 2
>
> I couldn't find unwind.h anywhere in the distribution, and it  
> doesn't appear to be a public header on my system. Am I missing  
> something before I try installing libobjc2? I have installed gnustep-
> make into a non-standard location, but I'm not sure how this would  
> influence it.
>
> Thanks
> Chris
>
> --------
> Christopher Armstrong
> carmstrong@...
>
>
>
>
>
>
>
> _______________________________________________
> Gnustep-dev mailing list
> Gnustep-dev@...
> http://lists.gnu.org/mailman/listinfo/gnustep-dev

-- Sent from my Apple II



_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@...
http://lists.gnu.org/mailman/listinfo/gnustep-dev

[Matt Rice-2]

On Sun, Oct 4, 2009 at 7:30 AM, David Chisnall <theraven@...> 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@...
http://lists.gnu.org/mailman/listinfo/gnustep-dev

[David Chisnall]

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 <theraven@...>  
> 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@...
> http://lists.gnu.org/mailman/listinfo/gnustep-dev

-- Sent from my brain



_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@...
http://lists.gnu.org/mailman/listinfo/gnustep-dev

[Christopher Armstrong-5]

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 <theraven@...>  
>> 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@...
>> http://lists.gnu.org/mailman/listinfo/gnustep-dev
>
>
> -- Sent from my brain
>

--------
Christopher Armstrong
carmstrong@...







_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@...
http://lists.gnu.org/mailman/listinfo/gnustep-dev

[David Chisnall]

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 <theraven@...>  
>>> 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@...
>>> http://lists.gnu.org/mailman/listinfo/gnustep-dev
>>
>>
>> -- Sent from my brain
>>
>
> --------
> Christopher Armstrong
> carmstrong@...
>
>
>
>
>
>
>
> _______________________________________________
> Gnustep-dev mailing list
> Gnustep-dev@...
> http://lists.gnu.org/mailman/listinfo/gnustep-dev

-- Sent from my PDP-11



_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@...
http://lists.gnu.org/mailman/listinfo/gnustep-dev

[Christopher Armstrong-5]

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:

chris@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:
chris@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  
>>>> <theraven@...> 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@...
>>>> http://lists.gnu.org/mailman/listinfo/gnustep-dev
>>>
>>>
>>> -- Sent from my brain
>>>
>>
>> --------
>> Christopher Armstrong
>> carmstrong@...
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Gnustep-dev mailing list
>> Gnustep-dev@...
>> http://lists.gnu.org/mailman/listinfo/gnustep-dev
>
>
> -- Sent from my PDP-11
>

--------
Christopher Armstrong
carmstrong@...







_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@...
http://lists.gnu.org/mailman/listinfo/gnustep-dev

[David Chisnall]

You can try the latest svn.  I've tidied up a few things.  Don't  
bother filing bug reports yet; as I said, it's still under development  
and getting it to build outside of the GCC tree will probably expose  
things.

David

On 4 Oct 2009, at 16:39, Christopher Armstrong wrote:

> 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:
>
> chris@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:
> chris@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  
>>>>> <theraven@...> 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@...
>>>>> http://lists.gnu.org/mailman/listinfo/gnustep-dev
>>>>
>>>>
>>>> -- Sent from my brain
>>>>
>>>
>>> --------
>>> Christopher Armstrong
>>> carmstrong@...
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Gnustep-dev mailing list
>>> Gnustep-dev@...
>>> http://lists.gnu.org/mailman/listinfo/gnustep-dev
>>
>>
>> -- Sent from my PDP-11
>>
>
> --------
> Christopher Armstrong
> carmstrong@...
>
>
>
>
>
>
>
> _______________________________________________
> Gnustep-dev mailing list
> Gnustep-dev@...
> http://lists.gnu.org/mailman/listinfo/gnustep-dev

-- Sent from my Difference Engine





_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@...
http://lists.gnu.org/mailman/listinfo/gnustep-dev