FSF GCC ObjC(++) Support
Am Mittwoch, den 01.04.2009, 00:48 +0100 schrieb David Chisnall: Well I'm not too fond of yet another compiler/runtime to support... but if it is what apple will be using and it will also replace the current apple runtime, I'm glad someone is working on it. But I think will need insure that our current main compiler / runtime stays in (or is restored to) a decent condition. Neither am I, but no one on the GCC side seems to be working on Objective-C. I tried to persuade the FreeBSD port maintainer to enable ObjC++ recently in the default build, and his reaction was that ObjC was basically unmaintained in GCC and ObjC++ was in an even worse state. Someone at Apple created some patches over a year ago for adding support for properties to GCC on the GNU runtime. Are they merged yet? No. Is anyone planning on merging them, or rewriting their functionality? Not as far as I can see. Do any of the GCC folks outside of Apple give a dam about Objective-C? Not that I can tell; we had a /stable/ release ship generating errors with any Objective-C program containing constant strings a while ago, and the GCC response was 'Objective-C is not a priority'. If we continue to treat GCC as our main compiler then run the risk that we are depending on a project which has no interest in maintaining the features we need. [snip] I currently have no insight into whether clang is a viable alternative to the FSF GCC ObjC(++) support. I'm glad that someone so close the GNUstep project is actively working on support GNUstep. I also have no insight on how portable clang is compared to FSF GCC ObjC++ (ie. we'd be back to defining and testing the platforms GNUstep should care about wrt to clang as I suggest for libffi). For production systems, I certainly will prefer the FSF GCC at least until clang has been packaged by major distributions. I understand the the price I need to pay is to either pay someone to maintain FSF ObjC support, or do it myself. Currently I'm trying to take the latter route and try to finance that work via my actual business [which is ERP implementations and not compiler/runtime/GNUstep development... but then again I doubt that's hardly anybodies business on this list] (well, I haven't talked to Andrew P. about his rate yet ;-) ). Yet I simply cannot offer meaningful help for ObjC++ since I'm simply not C++ literate. So I'm hoping that someone will step up help maintain that at least until other solutions become widely available. Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Deprecating ffcall
David Ayers wrote: I agree that if it is really the case that libffi supersedes ffcall on all Supported Platforms that we should aim to remove it: http://lists.gnu.org/archive/html/discuss-gnustep/2008-12/msg00019.html The last stable -base release at the end of last year already defaults to libffi. I'm still uneasy to completely remove ffcall, simply due to the lack of testing on various platforms which is why I start writing tests like these: http://svn.gna.org/viewcvs/gnustep/tests/testsuite/trunk/base/NSProxy/test01.m yet those do not go far enough as we actually need to test DO in action. So I agree that we could deprecate ffcall (and build_apply) but I think we should also find out which platforms we know we want to support and test them with libffi. [Granted that Linux 2.4 may not be a feasible target to keep support for.] This may sound strange, coming from my side as I already advocated the use of libffi when it still supported less platforms than ffcall, but I strongly advocate that we phase out support for ffcall very slowly. Remember that only two years ago somebody suggested that we should drop support for libffi :-) And please remember even asking on the discussion list wont be enough to find out whether anybody still needs ffcall. People will only start to complain after its gone. Cheers Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GCC Runtime Licensing
On 1 Apr 2009, at 06:24, David Ayers wrote: Indeed I believe this concern has just been addressed: http://www.gnu.org/licenses/gcc-exception.html http://gcc.gnu.org/ml/gcc/2009-04/msg5.html Thanks for the clarification. As I read it, this means that the exemption only applies to code compiled with GCC. This is bringing libgcc (and GNU libc?) into line with the existing exemption on GNU libobjc, which is exactly the opposite of what I wanted. This means that it is not possible, for example, to compile any GPLv2 program with any other compiler that uses the GNU runtime libraries. In fact, this entire exemption is potentially problematic, because it explicitly excludes preprocessors, which means that when GCC runs the preprocessor and copies inline functions from the libobjc headers into programs the exemption does not apply. This makes it impossible to use recent versions of GCC to compile GNUstep, since GPLv3 is incompatible with LGPLv2. The exemption I would like to see is: - Use of the headers is allowed for any purpose (you can't copyright an interface, so this only applies to the very small number of inline functions and macros defined in the headers). - Linking is permitted. This is the old exemption from libgcc: In addition to the permissions in the GNU General Public License, the Free Software Foundation gives you unlimited permission to link the compiled version of this file into combinations with other programs, and to distribute those combinations without any restriction coming from the use of this file. (The General Public License restrictions do apply in other respects; for example, they cover modification of the file, and distribution when not linked into a combine executable. This would be absolutely perfect for libobjc. I don't understand what they hope to gain by changing it, other than to force us to stop using GNU libobjc. David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Deprecating ffcall
Fred Kiefer wrote: This may sound strange, coming from my side as I already advocated the use of libffi when it still supported less platforms than ffcall, but I strongly advocate that we phase out support for ffcall very slowly. Remember that only two years ago somebody suggested that we should drop support for libffi :-) Since the one who suggested that (a bit provocatively) was me, I probably should state that I'm perfectly happy with deprecating ffcall. In fact, the main argument of the rant was that GNUstep should support just one callback implementation (either ffcall or libffi) and the reason for preferring ffcall at that time was a bug in message forwarding as implemented on top of libffi. Since this has been fixed since then and I'm working on some machines that do not even have a working ffcall implementation (e.g., Mac OS X on Intel; at least I wasn't able to get it working there) I would happily let ffcall support go. And please remember even asking on the discussion list wont be enough to find out whether anybody still needs ffcall. People will only start to complain after its gone. Indeed. So let's drop ffcall and eventually restore it later if (too) many people complain? Wolfgang ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GCC Runtime Licensing (sorry!)
Okay, it's official: I can't read[1]. Having reread that paragraph, I completely agree with your interpretation, this is exactly the kind of exemption I wanted. Thank you very much to the FSF. Absolutely perfect (when read with a fully- awake brain). Interestingly, this means that you can use clang + LLVM + proprietary optimisation passes, but not llvm-gcc + (the same) proprietary optimisations. I don't have a problem with this - it just means that if you want proprietary optimisations you don't get to benefit from the GCC code. This is excellent news for Étoilé too, since it means that LanguageKit is now able to compile code that is not GPL-compatible[2], and we can compile GNUstep with clang without issues (sadly not with llvm-gcc). I guess this means I've now run out of excuses for not improving the GNU runtime... David [1] In my defence, I read it first it before my first cup of coffee... [2] Only an issue when using it in static-compiler mode and distributing the binaries. The JIT mode was already exempt from this since the GPL is a distribution license and doesn't apply if you don't distribute the result, which you never do with JIT'd code. On 1 Apr 2009, at 12:31, Nicola Pero wrote: Indeed I believe this concern has just been addressed: http://www.gnu.org/licenses/gcc-exception.html http://gcc.gnu.org/ml/gcc/2009-04/msg5.html Thanks for the clarification. As I read it, this means that the exemption only applies to code compiled with GCC. I'm not a lawyer, but I got the opposite impression. It says A Compilation Process is Eligible if it is done using GCC, alone or with other GPL-compatible software, or if it is done without using any work based on GCC. So, for example, compiling using LLVM, which I think uses no work based on GCC, would be Eligible. And then the Grant of Additional Permission applies. Considering this comes from the FSF, it sounds like a very open licensing model. Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep base almost builds with clang
Both, they are moving over to clang (and LLVM) witness the subject line :). good stuff ;-) I should go re-visit llvm and clang really, I never took a proper look at it - I didn't realise it couod compile to native code, which is preseumably true if they are compiking a full OS with it [ thats probably reduyced the chnaces of me doing an real work the rest of the day to zero ! ] -pete. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GCC Runtime Licensing
Am Mittwoch, den 01.04.2009, 11:39 +0100 schrieb David Chisnall: On 1 Apr 2009, at 06:24, David Ayers wrote: Indeed I believe this concern has just been addressed: http://www.gnu.org/licenses/gcc-exception.html http://gcc.gnu.org/ml/gcc/2009-04/msg5.html Thanks for the clarification. As I read it, this means that the exemption only applies to code compiled with GCC. You have permission to propagate a work of Target Code formed by combining the Runtime Library with Independent Modules, even if such propagation would otherwise violate the terms of GPLv3, provided that all Target Code was generated by *Eligible Compilation Processes*. You may then convey such a combination under terms of your choice, consistent with the licensing of the Independent Modules. A Compilation Process is Eligible if it is done using GCC, alone *or with other GPL-compatible software*, or *if it is done without using any work based on GCC*. For example, using non-GPL-compatible Software to optimize any GCC intermediate representations would not qualify as an Eligible Compilation Process. This is bringing libgcc (and GNU libc?) into line with the existing exemption on GNU libobjc, which is exactly the opposite of what I wanted. This means that it is not possible, for example, to compile any GPLv2 program with any other compiler that uses the GNU runtime libraries. Is clang (I gather it's licensed under the MIT license?) not GPL-compatible? Note that it also doesn't specify a specific version of the GPL to be compatible with. Also note it talks about software used for the compilation process ie. IDE tools... and not the code being compiled. In fact, this entire exemption is potentially problematic, because it explicitly excludes preprocessors, which means that when GCC runs the preprocessor and copies inline functions from the libobjc headers into programs the exemption does not apply. This makes it impossible to use recent versions of GCC to compile GNUstep, since GPLv3 is incompatible with LGPLv2. The LGPLv2 is compatible with GPLv2. The exemption I would like to see is: - Use of the headers is allowed for any purpose (you can't copyright an interface, so this only applies to the very small number of inline functions and macros defined in the headers). - Linking is permitted. IANAL and jurisdictions vary but stating that you can't copyright an interface is a broad statement I'd like to be true but by no means would advise anyone to rely on. This is the old exemption from libgcc: In addition to the permissions in the GNU General Public License, the Free Software Foundation gives you unlimited permission to link the compiled version of this file into combinations with other programs, and to distribute those combinations without any restriction coming from the use of this file. (The General Public License restrictions do apply in other respects; for example, they cover modification of the file, and distribution when not linked into a combine executable. This would be absolutely perfect for libobjc. I don't understand what they hope to gain by changing it, other than to force us to stop using GNU libobjc. I'm not sure who you mean by us but I for sure am fine with using the license. But if you have issues I think the correct place to discuss this is licens...@fsf.org (or the possibly the http://www.fsfeurope.org/projects/ftf/ftf.en.html if your interested in the a European perspective). Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Deprecating ffcall
Am Mittwoch, den 01.04.2009, 11:27 +0100 schrieb David Chisnall: On 1 Apr 2009, at 09:05, Fred Kiefer wrote: This may sound strange, coming from my side as I already advocated the use of libffi when it still supported less platforms than ffcall, but I strongly advocate that we phase out support for ffcall very slowly. Remember that only two years ago somebody suggested that we should drop support for libffi :-) In that case, can someone add support for moving the return value address off the stack to GSFFCallInvocation? At the moment, certain uses of GSFFCallInvocation that work on Cocoa cause stack corruption on GNUstep, as I mentioned in an earlier email. Could I ask you for a bug report and/or a test case? It's stuff like this that we really need in our test suite. Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep base almost builds with clang
On 1 Apr 2009, at 01:51, Pete French wrote: Apple has moved away from GCC so you can no longer depend on them. This I did not know. Interesting. I assumed Xcode was still using gcc. XCode currently ships with gcc and llvm-gcc. Only llvm-gcc is supported for iPhone developement (if you take a look at the LLVM commit logs, you'll notice a massive amount of ARM-backend code was committed the day the first iPhone developer kits were released). llvm-gcc is a hybrid compiler, which uses GCC to parse, then translates GIMPLE (the GCC intermediate representation) into LLVM IR and then uses LLVM for optimisation and code generation. Because it includes parts of GCC, it is GPL'd. Unfortunately for us, llvm-gcc uses Apple's branch of GCC, which is GPLv2, and (more importantly) only supports the Apple runtime. You can use it with to compile C and C++ code on non-Apple platforms, but you can't use it with Objective-C, so GNUstep can't use it. Clang is a new front-end for LLVM, written completely from scratch, which is more-or-less feature complete for C99 and Objective-C 2 (parsing anyway - code generation is only finished for the Apple runtimes), and now working towards C++ support. My understanding is that Apple intends to drop llvm-gcc once clang is a drop-in replacement (it almost is now for C and Objective-C on the Apple runtimes, but it's still probably about a year away from being ready for C++ / ObjC++). There are a few other reasons why clang might interest the GNUstep community: - It contains a static analyser, which can find a lot of different types of Objective-C bug. - It is built from several libraries, which means that you can easily reuse the parser in other programs, for example to implement code completion and syntax highlighting, or to write a version of autogsdoc that is aware of macros. - One of the demos is a rewriter, which translates ObjC code into pure C code (for the Apple runtime). Modifying this to use the GNU runtime calls would give a mechanism for compiling GNUstep on any platform with a working C compiler. Alternatively, LLVM has a C back end which can generate (completely unreadable, but semantically valid) C code from the IR. If you want an overview of LLVM, you can read this article: http://www.informit.com/articles/article.aspx?p=1215438 David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep base almost builds with clang
Would it be possible for you to check whether GNUstep works with libffi? On FreeBSD/i386, it defaults to using ffcall, but works better with libffi (i.e. doesn't randomly corrupt the stack when you pass NSInvocations between threads). You probably need to explicitly specify /usr/local/include and /usr/local/lib as ffi lib/include directories in configure. Using the latest SVN this now works out of the box with just 'configure' and the libffi port installed. So no need for ffcall on this platform anymore. cheers, -pete. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep base almost builds with clang
Clang is a new front-end for LLVM, written completely from scratch,
which is more-or-less feature complete for C99 and Objective-C 2
(parsing anyway - code generation is only finished for the Apple
runtimes), and now working towards C++ support.
Is this what you were using to try and compile GNustep base ? I
have just soent a while playing around with the llvm port on
FreeBSD (which seems to be lacking the compiler driver). Had some
success with plain old C, but not a lot with ObjC, eeven when I am not
doing anything objecty. e.g:
#include stdio.h
#include objc/objc.h
#include objc/Object.h
@interface foo : Object
@end
@implementation foo : Object
@end
int
main(int argc, char *argv[])
{
puts(Hello world);
return 0;
}
-pete.
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep base almost builds with clang
On 1 Apr 2009, at 15:10, Pete French wrote: Clang is a new front-end for LLVM, written completely from scratch, which is more-or-less feature complete for C99 and Objective-C 2 (parsing anyway - code generation is only finished for the Apple runtimes), and now working towards C++ support. Is this what you were using to try and compile GNustep base ? I have just soent a while playing around with the llvm port on FreeBSD (which seems to be lacking the compiler driver). Had some success with plain old C, but not a lot with ObjC, eeven when I am not doing anything objecty. e.g: Not sure what you are using to compile here. There is not FreeBSD port for clang, and trunk clang requires trunk LLVM (i.e. not the port). Can you tell me what commands you are trying to use to compile? David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep base almost builds with clang
Not sure what you are using to compile here. There is not FreeBSD
port for clang, and trunk clang requires trunk LLVM (i.e. not the
port). Can you tell me what commands you are trying to use to compile?
I installed llvm-dev from ports. Which gives me a 'clang' command
that I can use like this:
clang test.m -emit-llvm -o - | llvm-as | opt -std-compile-opts | llc test.s
cc test.s -lobjc
./a.out
That works fine as long as there are no actual Objective C
constructs inside test.m . Its a basic hello world at the
moment:
#include stdio.h
#include objc/Object.h
int
main(int argc, char *argv[])
{
puts(Hello world);
return 0;
}
That works fine. But if I add the line id x = [Object new];
at the start of main() then I get this at runtime:
Module (null) version 8 doesn't match runtime 8
Abort trap: 6 (core dumped)
That's due to me having the wrong libobjc, yes ? I was wondering what
runtime you use which works... now I can compile and run code I
am interested in experimenting with this a bit
-pete.
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep base almost builds with clang
Patch to fix this problem is here if you want to apply it to your
local tree:
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2009-April/004759.html
As far as I know, you are the first person to test clang Objective-C
support on a 64-bit platform. Please keep sending me reports of
things that don't work.
David
On 1 Apr 2009, at 16:35, Pete French wrote:
Not sure what you are using to compile here. There is not FreeBSD
port for clang, and trunk clang requires trunk LLVM (i.e. not the
port). Can you tell me what commands you are trying to use to
compile?
I installed llvm-dev from ports. Which gives me a 'clang' command
that I can use like this:
clang test.m -emit-llvm -o - | llvm-as | opt -std-compile-opts | llc
test.s
cc test.s -lobjc
./a.out
That works fine as long as there are no actual Objective C
constructs inside test.m . Its a basic hello world at the
moment:
#include stdio.h
#include objc/Object.h
int
main(int argc, char *argv[])
{
puts(Hello world);
return 0;
}
That works fine. But if I add the line id x = [Object new];
at the start of main() then I get this at runtime:
Module (null) version 8 doesn't match runtime 8
Abort trap: 6 (core dumped)
That's due to me having the wrong libobjc, yes ? I was wondering what
runtime you use which works... now I can compile and run code I
am interested in experimenting with this a bit
-pete.
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep base almost builds with clang
Patch to fix this problem is here if you want to apply it to your local tree: Just working out how to get a local tree ;-) Aside from GNUstep I usually just build from ports. As far as I know, you are the first person to test clang Objective-C support on a 64-bit platform. Please keep sending me reports of things that don't work. Will do - and I think this has strayed a very long way from GNUstep now, so wont do so here. I have a lot of stuff I want to compile up. WWe have several tens of thousands of lines of straight objeective C built on top of libc directly, so we can eaily use llvm to run it. cheers, -pete. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep base almost builds with clang
Am 01.04.2009 um 14:11 schrieb David Chisnall: If you want an overview of LLVM, you can read this article: http://www.informit.com/articles/article.aspx?p=1215438 I added your interesting article to DZone http://www.dzone.com/links/ how_the_llvm_compiler_infrastructure_works.html feel free to vote it up David regards, Lars ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
