Clang and 0.5
|
View:
New views
8 Messages
—
Rating Filter:
Alert me
|
 |
Clang and 0.5
by David Chisnall-3
::
Rate this Message:
Hi Everyone,
At some point, hopefully before 0.5, I would like us to start requiring clang for Étoilé. Currently, adopting clang gives us: - Declared properties. - Fast enumeration. - Blocks. - Sender-dependent dispatch (for Object Planes support). - Link-time optimisations. - A much less well-tested compiler. All of these, except the last one are positive. The only way we can fix the last one is by testing it, so can everyone try compiling Étoilé for your favourite platform with a recent svn build of clang? David _______________________________________________ Etoile-discuss mailing list Etoile-discuss@... https://mail.gna.org/listinfo/etoile-discuss |
|
|
Re: Clang and 0.5
by David Chisnall
::
Rate this Message:
On 14 Jun 2009, at 12:14, David Chisnall wrote:
> All of these, except the last one are positive. The only way we can > fix the last one is by testing it, so can everyone try compiling > Étoilé for your favourite platform with a recent svn build of clang? I forgot to add: let me know of any compiler bugs you encounter! David _______________________________________________ Etoile-discuss mailing list Etoile-discuss@... https://mail.gna.org/listinfo/etoile-discuss |
|
|
Re: Clang and 0.5
by Andrew Price-3
::
Rate this Message:
On 14/06/09 12:14, David Chisnall wrote:
> Hi Everyone, > > At some point, hopefully before 0.5, I would like us to start > requiring clang for Étoilé. Currently, adopting clang gives us: > > - Declared properties. > - Fast enumeration. > - Blocks. > - Sender-dependent dispatch (for Object Planes support). > - Link-time optimisations. > - A much less well-tested compiler. > > All of these, except the last one are positive. The only way we can > fix the last one is by testing it, so can everyone try compiling > Étoilé for your favourite platform with a recent svn build of clang? Am I doing something wrong here. (This is with an up-to-date llvm, clang and gnustep-* from svn as of this morning). $ . /usr/local/GNUstep/System/Library/Makefiles/GNUstep.sh $ make CC=clang messages=yes (...) clang UKRunner.m -c \ -MMD -MP -DGNUSTEP -DGNUSTEP_BASE_LIBRARY=1 -DGNU_GUI_LIBRARY=1 -DGNU_RUNTIME=1 -DGNUSTEP_BASE_LIBRARY=1 -D_REENTRANT -fPIC -g -Wall -DDEBUG -fno-omit-frame-pointer -DGSWARN -DGSDIAGNOSE -Wno-import -g -fno-strict-aliasing -fgnu-runtime -Wno-import -std=c99 -fconstant-string-class=NSConstantString -I./derived_src -I. -I/home/andy/GNUstep/Library/Headers -I/usr/local/GNUstep/Local/Library/Headers -I/usr/local/GNUstep/System/Library/Headers \ -o obj/UKRunner.m.o warning: unknown warning option: -Wno-import warning: unknown warning option: -Wno-import In file included from UKRunner.m:27: In file included from ./UKRunner.h:25: /usr/local/GNUstep/Local/Library/Headers/Foundation/Foundation.h:31:9: fatal error: 'objc/objc.h' file not found #import <objc/objc.h> ^ 1 diagnostic generated. make[5]: *** [obj/UKRunner.m.o] Error 1 Andrew _______________________________________________ Etoile-discuss mailing list Etoile-discuss@... https://mail.gna.org/listinfo/etoile-discuss |
|
|
Re: Clang and 0.5
by David Chisnall
::
Rate this Message:
On 14 Jun 2009, at 17:08, Andrew Price wrote:
> On 14/06/09 12:14, David Chisnall wrote: >> Hi Everyone, >> >> At some point, hopefully before 0.5, I would like us to start >> requiring clang for Étoilé. Currently, adopting clang gives us: >> >> - Declared properties. >> - Fast enumeration. >> - Blocks. >> - Sender-dependent dispatch (for Object Planes support). >> - Link-time optimisations. >> - A much less well-tested compiler. >> >> All of these, except the last one are positive. The only way we can >> fix the last one is by testing it, so can everyone try compiling >> Étoilé for your favourite platform with a recent svn build of clang? > > Am I doing something wrong here. (This is with an up-to-date llvm, > clang > and gnustep-* from svn as of this morning). What OS are you using and where is objc.h? Clang only searches /usr/ include and /usr/local/include by default for C / ObjC headers. If your headers are somewhere else, take a look in lib/Frontend/ InitHeaderSearch.cpp - we can add other search paths if they are required for specific operating systems. David _______________________________________________ Etoile-discuss mailing list Etoile-discuss@... https://mail.gna.org/listinfo/etoile-discuss |
|
|
Re: Clang and 0.5
by Andrew Price-3
::
Rate this Message:
On 14/06/09 17:15, David Chisnall wrote:
> What OS are you using and where is objc.h? Clang only searches /usr/ > include and /usr/local/include by default for C / ObjC headers. If > your headers are somewhere else, take a look in lib/Frontend/ > InitHeaderSearch.cpp - we can add other search paths if they are > required for specific operating systems. I'm using Debian and the only objc.h I can find (apart from the one in Etoile/Languages/libobjc/objc) is: /usr/lib/gcc/x86_64-linux-gnu/4.3/include/objc/objc.h Just to check this isn't unusual I looked on Fedora too, and it puts it here: /usr/lib/gcc/i386-redhat-linux/4.3.2/include/objc/objc.h Andrew _______________________________________________ Etoile-discuss mailing list Etoile-discuss@... https://mail.gna.org/listinfo/etoile-discuss |
|
|
Re: Clang and 0.5
by David Chisnall
::
Rate this Message:
On 14 Jun 2009, at 17:52, Andrew Price wrote:
> On 14/06/09 17:15, David Chisnall wrote: >> What OS are you using and where is objc.h? Clang only searches /usr/ >> include and /usr/local/include by default for C / ObjC headers. If >> your headers are somewhere else, take a look in lib/Frontend/ >> InitHeaderSearch.cpp - we can add other search paths if they are >> required for specific operating systems. > > I'm using Debian and the only objc.h I can find (apart from the one in > Etoile/Languages/libobjc/objc) is: > > /usr/lib/gcc/x86_64-linux-gnu/4.3/include/objc/objc.h > > Just to check this isn't unusual I looked on Fedora too, and it puts > it > here: > > /usr/lib/gcc/i386-redhat-linux/4.3.2/include/objc/objc.h Wow, that's completely messed up. See if this patch makes it work for you: Index: lib/Frontend/InitHeaderSearch.cpp =================================================================== --- lib/Frontend/InitHeaderSearch.cpp (revision 73341) +++ lib/Frontend/InitHeaderSearch.cpp (working copy) @@ -179,6 +179,8 @@ AddPath("/usr/include/c++/4.2", System, true, false, false); } + AddPath("/usr/lib/gcc/x86_64-linux-gnu/4.3/include", System, false, false, + false); AddPath("/usr/local/include", System, false, false, false); AddPath("/usr/include", System, false, false, false); _______________________________________________ Etoile-discuss mailing list Etoile-discuss@... https://mail.gna.org/listinfo/etoile-discuss |
|
|
Re: Clang and 0.5
by Andrew Price-3
::
Rate this Message:
On Sun, Jun 14, 2009 at 05:58:07PM +0100, David Chisnall wrote:
> On 14 Jun 2009, at 17:52, Andrew Price wrote: > > > On 14/06/09 17:15, David Chisnall wrote: > >> What OS are you using and where is objc.h? Clang only searches /usr/ > >> include and /usr/local/include by default for C / ObjC headers. If > >> your headers are somewhere else, take a look in lib/Frontend/ > >> InitHeaderSearch.cpp - we can add other search paths if they are > >> required for specific operating systems. > > > > I'm using Debian and the only objc.h I can find (apart from the one in > > Etoile/Languages/libobjc/objc) is: > > > > /usr/lib/gcc/x86_64-linux-gnu/4.3/include/objc/objc.h > > > > Just to check this isn't unusual I looked on Fedora too, and it puts > > it > > here: > > > > /usr/lib/gcc/i386-redhat-linux/4.3.2/include/objc/objc.h > > Wow, that's completely messed up. See if this patch makes it work for > you: warnings and eventually an error elsewhere. I've attached the output of make CC=clang messages=yes 2>build.err Andrew warning: unknown warning option: -Wno-import warning: unknown warning option: -Wno-import UKRunner.m:353:13: warning: method '-initForTest' not found (return type defaults to 'id') object = [object initForTest]; ^~~~~~~~~~~~~~~~~~~~ UKRunner.m:393:7: warning: method '-releaseForTest' not found (return type defaults to 'id') [object releaseForTest]; ^~~~~~~~~~~~~~~~~~~~~~~ UKRunner.m:495:7: warning: method '-conformsTo:' not found (return type defaults to 'id') if([protocol_list->list[i] conformsTo:aProtocol]) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 3 diagnostics generated. warning: unknown warning option: -Wno-import warning: unknown warning option: -Wno-import UKTestHandler.m:228:15: warning: implicit declaration of function 'fabs' is invalid in C99 [-Wimplicit-function-declaration] float c = fabs(a - b); ^ 1 diagnostic generated. warning: unknown warning option: -Wno-import warning: unknown warning option: -Wno-import warning: unknown warning option: -Wno-import warning: unknown warning option: -Wno-import warning: unknown warning option: -Wno-import warning: unknown warning option: -Wno-import warning: unknown warning option: -Wno-import warning: unknown warning option: -Wno-import warning: unknown warning option: -Wno-import warning: unknown warning option: -Wno-import ObjectPlanes.m:62:25: warning: receiver 'GSCInlineString' is a forward class and corresponding @interface may not exist GSCInlineStringClass = [GSCInlineString class]; ^ In file included from ObjectPlanes.m:1: In file included from /usr/local/GNUstep/Local/Library/Headers/Foundation/Foundation.h:33: In file included from /usr/local/GNUstep/Local/Library/Headers/Foundation/FoundationErrors.h:29: /usr/local/GNUstep/Local/Library/Headers/Foundation/NSObject.h:189:1: note: method 'class' is used for the forward class + (Class) class; ^ ObjectPlanes.m:67:2: warning: implicitly declaring C library function 'index' with type 'char *(char const *, int)' index = __sync_fetch_and_add(&nextPlane, 1); ^ ObjectPlanes.m:67:2: note: please include the header <strings.h> or explicitly provide a declaration for 'index' 4 diagnostics generated. warning: unknown warning option: -Wno-import warning: unknown warning option: -Wno-import warning: unknown warning option: -Wno-import warning: unknown warning option: -Wno-import warning: unknown warning option: -Wno-import warning: unknown warning option: -Wno-import warning: unknown warning option: -Wno-import warning: unknown warning option: -Wno-import warning: unknown warning option: -Wno-import warning: unknown warning option: -Wno-import warning: unknown warning option: -Wno-import warning: unknown warning option: -Wno-import warning: unknown warning option: -Wno-import warning: unknown warning option: -Wno-import warning: unknown warning option: -Wno-import warning: unknown warning option: -Wno-import warning: unknown warning option: -Wno-import warning: unknown warning option: -Wno-import warning: unknown warning option: -Wno-import warning: unknown warning option: -Wno-import warning: unknown warning option: -Wno-import warning: unknown warning option: -Wno-import warning: unknown warning option: -Wno-import warning: unknown warning option: -Wno-import warning: unknown warning option: -Wno-import warning: unknown warning option: -Wno-import warning: unknown warning option: -Wno-import warning: unknown warning option: -Wno-import warning: unknown warning option: -Wno-import warning: unknown warning option: -Wno-import warning: unknown warning option: -Wno-import warning: unknown warning option: -Wno-import warning: unknown warning option: -Wno-import warning: unknown warning option: -Wno-import warning: unknown warning option: -Wno-import warning: unknown warning option: -Wno-import warning: unknown warning option: -Wno-import warning: unknown warning option: -Wno-import ETXMLNode.m:75:8: error: implicitly declaring C library function 'index' with type 'char *(char const *, int)' while(index < count) ^ ETXMLNode.m:75:8: note: please include the header <strings.h> or explicitly provide a declaration for 'index' 2 diagnostics generated. make[5]: *** [obj/ETXMLNode.m.o] Error 1 make[4]: *** [internal-framework-run-compile-submake] Error 2 make[3]: *** [EtoileXML.all.framework.variables] Error 2 make[2]: *** [internal-all] Error 2 make[1]: *** [internal-all] Error 2 make: *** [internal-all] Error 2 _______________________________________________ Etoile-discuss mailing list Etoile-discuss@... https://mail.gna.org/listinfo/etoile-discuss |
|
|
Re: Clang and 0.5
by Niels Grewe
::
Rate this Message:
On Sun, Jun 14, 2009 at 06:37:15PM +0100, Andrew Price wrote:
> Yep that works. At least, it gets further now but there are a bunch more > warnings and eventually an error elsewhere. I've attached the output of > > make CC=clang messages=yes 2>build.err I'm running into virtually identical issues (but I'm only trying to build EtoileFoundation with clang, because that's where I'm still working on map/fold/filter stuff that uses blocks). > UKRunner.m:353:13: warning: method '-initForTest' not found (return type defaults to 'id') > object = [object initForTest]; > ^~~~~~~~~~~~~~~~~~~~ > UKRunner.m:393:7: warning: method '-releaseForTest' not found (return type defaults to 'id') > [object releaseForTest]; > ^~~~~~~~~~~~~~~~~~~~~~~ > UKRunner.m:495:7: warning: method '-conformsTo:' not found (return type defaults to 'id') > if([protocol_list->list[i] conformsTo:aProtocol]) > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 3 diagnostics generated. This kind of error seems to be very common. It goes away if you either explicitly declare that the object conforms to the NSObject protocol or cast it to NSObject. > ETXMLNode.m:75:8: error: implicitly declaring C library function 'index' with type 'char *(char const *, int)' > while(index < count) > ^ > ETXMLNode.m:75:8: note: please include the header <strings.h> or explicitly provide a declaration for 'index' > 2 diagnostics generated. This seems to result from the compiler treating index as a builtin while it is really an instance variable (same thing in ObjectPlanes.(m|h)). Renaming the index ivar will work around it. I had two additional problems: 1. clang uncovered an inconsistency between the ETUUID interface and implementation in EtoileFoundation: > ETUUID.m:232:1: error: conflicting return type in implementation of 'UUIDValue': 'unsigned char *' vs 'unsigned char const *' > - (const unsigned char *) UUIDValue > ^ > In file included from ETUUID.m:9: > .../Etoile/Frameworks/EtoileFoundation/Headers/ETUUID.h:50:1: note: previous definition is here > - (unsigned char *) UUIDValue; > ^ 2. In the unistd.h system header, the encrypt function for XOpen has an variable named __block which doesn't play nicely with the builtin clang macor __block. The solution is not to define (or undefine) __USE_XOPEN. With these workarounds, EtoileFoundation builds fine for me. Cheers, Niels _______________________________________________ Etoile-discuss mailing list Etoile-discuss@... https://mail.gna.org/listinfo/etoile-discuss |
| Free embeddable forum powered by Nabble | Forum Help |
