In the course of analyzing some weird crashes I produced a new compiler by merging the Cocotron changes for gcc 4.3.1 into gcc 4.3.6. Luckily all conflicts could be resolved trivially. In the end, the cause of the crashes was unrelated (-mstackrealign appears to corrupt the stack in MinGW Objective-C++ code). Given the number of bugs fixed in gcc 4.3.6 I now wonder whether it is a good idea to keep using that compiler binary, or whether there are any incompatibilities with Cocotron (know already or to be expected).
How about different compilers in general? Some people seem to happily use Cocotron with clang. Are the Cocotron changes just there to produce Apple-compatible compiler options, or is there some other magic involved, e.g. in connection with the Cocotron runtime? Could Cocotron be used with the Apple (or GNU) runtimes instead?
I'm using Cocotron with clang directly under Linux. The latest version in the SVN clang repository worked fine for that. No patches where necessary to the compiler. Given Apple is now 100% clang and doesn't invest anymore into gcc, the changes for new stuff in Obective C naturally end up in Clang automatically. I'm using the gnustep runtime however which is somewhat required for new objective c stuff. The apple runtime I'm not sure if it's a) wise to use (license issues might be in the way) and b) if its still open sourced in the latest version by apple.
On 29.09.2012, at 12:46, Tim Schmielau <tim.schmie...@gmail.com> wrote:
> In the course of analyzing some weird crashes I produced a new compiler by merging the Cocotron changes for gcc 4.3.1 into gcc 4.3.6. Luckily all conflicts could be resolved trivially. In the end, the cause of the crashes was unrelated (-mstackrealign appears to corrupt the stack in MinGW Objective-C++ code). Given the number of bugs fixed in gcc 4.3.6 I now wonder whether it is a good idea to keep using that compiler binary, or whether there are any incompatibilities with Cocotron (know already or to be expected).
> How about different compilers in general? Some people seem to happily use Cocotron with clang. Are the Cocotron changes just there to produce Apple-compatible compiler options, or is there some other magic involved, e.g. in connection with the Cocotron runtime? Could Cocotron be used with the Apple (or GNU) runtimes instead?
> Thanks,
> Tim
> -- > You received this message because you are subscribed to the Google Groups "Cocotron Developers" group.
> To view this discussion on the web visit https://groups.google.com/d/msg/cocotron-dev/-/0HFG_OjxPJMJ.
> To post to this group, send email to cocotron-dev@googlegroups.com.
> To unsubscribe from this group, send email to cocotron-dev+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/cocotron-dev?hl=en.
On Oct 3, 2012, at 05:16, Andreas Fink <andr...@fink.org> wrote:
> I'm using the gnustep runtime however which is somewhat required for new objective c stuff. The apple runtime I'm not sure if it's a) wise to use (license issues might be in the way) and b) if its still open sourced in the latest version by apple.
The Apple runtime is still open source, under the APSL 2.0, which is a fiddly, copyleft license with stringent labelling requirements (you need to be clear about what comes from Apple and what's changed, include notices with binary distributions etc).
Of course, the Apple runtime doesn't support Linux. It does support Windows, although I don't know if it builds for Windows out of the box.
If I was actively working on Cocotron code, I'd definitely seek to target clang and the GNUstep runtime (libobjc2).
On Wednesday, October 3, 2012 11:45:43 AM UTC+1, Ahruman wrote: > On Oct 3, 2012, at 05:16, Andreas Fink <and...@fink.org <javascript:>> > wrote:
> > I'm using the gnustep runtime however which is somewhat required for new > objective c stuff. The apple runtime I'm not sure if it's a) wise to use > (license issues might be in the way) and b) if its still open sourced in > the latest version by apple.
> Of course, the Apple runtime doesn't support Linux. It does support > Windows, although I don't know if it builds for Windows out of the box.
> If I was actively working on Cocotron code, I'd definitely seek to target > clang and the GNUstep runtime (libobjc2).
Thank you both for your comments. I'll then keep using the gcc 4.3.6 based compiler eyeing a switch to to clang and the GNU runtime later.
On Oct 7, 2012, at 10:33, Tim Schmielau <tim.schmie...@gmail.com> wrote:
> Thank you both for your comments. I'll then keep using the gcc 4.3.6 based compiler eyeing a switch to to clang and the GNU runtime later.
Not the GNU runtime, the GNUstep runtime. ("GNU runtime" generally refers to the GCC libobjc runtime, which is different. It's at times like this that code names start looking good.)
On Sunday, October 7, 2012 12:13:28 PM UTC+1, Ahruman wrote:
> Not the GNU runtime, the GNUstep runtime. ("GNU runtime" generally refers > to the GCC libobjc runtime, which is different. It's at times like this > that code names start looking good.)
Thank you for clarifying that. I had indeed meant the GNUstep runtime, but this was a good reason to refresh my memory about the difference. Which naturally leads me to the issue of licenses. I'll have to carefully check that later. For now I'll just stay with the Cocotron runtime though.
