Re: Clang/LLVM migration roadmap

> But what is a user? I can think at least of two types. >> 1) User of GNUstep libraries because user of GNUstep applications. >> 2) User of GNUstep because he writes GNUstep applications, > > I would say "User of GNUstep because he writes GNUstep applications *becau

Re: Clang/LLVM migration roadmap

user of GNUstep applications. 2) User of GNUstep because he writes GNUstep applications, I would say "User of GNUstep because he writes GNUstep applications *because there is users*. This Clang/LLVM migration looks like a lot of work for a small team. Maintaining the GNUStep fram

Re: Clang/LLVM migration roadmap

Hi, Hugo Melder wrote: > Mainly Windows support and some signature differences between Apple's > runtime (private APIs etc). The libobjc2 github repository keeps track > of that in the issues segment. I wonder if - besides ARC which is a compiler feature - we could make the GCC runtime more

Re: Clang/LLVM migration roadmap

> On 14 Feb 2022, at 08:54, Andreas Fink wrote: > > > > Daniel Boyd wrote on 14.02.22 08:54: >> Riccardo, >> >> Thanks for the response. I agree there is certainly a distinction between >> the user types and I, as a developer myself, was referring to #2. However, I >> disagree that

Re: Clang/LLVM migration roadmap

er does not work anymore for some reason. Most of the tests fail with it. Using the stock linker doesn't work neither, nor did the LLVM linker ldd which I found rather surprising. So we are in delicate areas here. As far as portability goes, all the platforms I am targeting are supported by

Re: Clang/LLVM migration roadmap

Riccardo, Thanks for the response. I agree there is certainly a distinction between the user types and I, as a developer myself, was referring to #2. However, I disagree that catering to each group is equally important at this juncture for two reasons: 1) GNUstep doesn’t currently have

Re: Clang/LLVM migration roadmap

Hi, On 2022-02-10 02:31:44 + Gregory Casamento wrote: Riccardo, I don't believe that GNUstep should hold back features to remain compatible with any given compiler. Not implementing features that are widely used (not even particularly "modern" ones) because the less capable

Re: Clang/LLVM migration roadmap

Hi, On 2022-02-06 10:51:49 + Richard Frith-Macdonald wrote: I think general portability is an issue, not just MSYS. MSYS is very sensitive itself - it took 2 years of work to upgrade from the original "msys 1" setup with gcc 3.4 (all newer gcc's had subtle issues!) to a failry

Re: Clang/LLVM migration roadmap

Hi Daniel, I think unvoluntary you made a very important point, I don't know by being aware of it or not. > If you’re looking to recruit more GNUStep users, I just don’t think you > can do that without ARC, @[], @{}, etc. There are plenty of ObjC developers > out there right now who are

Re: Clang/LLVM migration roadmap

nt the following in GCC: >> >> 1) Support for ARC properties (weak, strong, etc) >> 2) Syntactic sugar as I have specified in recent discussions >> 3) Internal compiler support for ARC (i.e. use the features in #1 to >> drive memory management) >> 4) Runtime

Re: Clang/LLVM migration roadmap

llowing in GCC: > > 1) Support for ARC properties (weak, strong, etc) > 2) Syntactic sugar as I have specified in recent discussions > 3) Internal compiler support for ARC (i.e. use the features in #1 to > drive memory management) > 4) Runtime changes to support the above >

Re: Clang/LLVM migration roadmap

the above In LLVM/clang the above features already exist. What is missing is: 1) The ability of the runtime to work on a number of different platforms: (Windows, etc) (if you can think of anything else that's missing, I'm sure you can think of something) Who is going to write this code, you? (y

Re: Clang/LLVM migration roadmap

Hi, On 2022-02-06 19:55:10 + Richard Frith-Macdonald wrote: Yes, I remember thinking (and should have said) that I know of no bugs in the GCC implementation (though of course there may be some), and that a bad release many years ago is not indicative of current or recent support.

Re: Clang/LLVM migration roadmap

of politics we lost some members of this community. Because of licenses and politics there are companies insisting using GCC and others CLang/LLVM! so... Personally, I deem almost unaccebtale (to use your own words) to loose "the GNU compiler" since we are a GNU project. My ultimate go

Re: Clang/LLVM migration roadmap

No. I don’t think this is a good idea. I really have no desire to maintain a fork of GCC. On Mon, Feb 7, 2022 at 12:32 Max Chan wrote: > Dear Mr. Casamento: > > I wonder if it is appropriate to just copy/paste code from LLVM/clang into > GCC? Legally speaking LLVM/clang is under

Re: Clang/LLVM migration roadmap

Dear Mr. Casamento: I wonder if it is appropriate to just copy/paste code from LLVM/clang into GCC? Legally speaking LLVM/clang is under a permissive license which should allow redistribution under GPLv3. Politically speaking I have no idea. If there is nothing stopping us from doing

Re: Clang/LLVM migration roadmap

ing technical and functional compability with > OpenStep and Cocoa over whatever toolchain to use to maintain that > compatibility? > > > > > > Compatibility is more important than the toolchain. > >> > >> 4) Clang/LLVM was initiated by Apple,

Re: Clang/LLVM migration roadmap

hink is more political than technical in any angle. > > > No. >> >> 3) Is GNUstep valuing technical and functional compability with OpenStep and >> Cocoa over whatever toolchain to use to maintain that compatibility? > > > Compatibility is more important tha

Re: Clang/LLVM migration roadmap

functional compability with OpenStep > and Cocoa over whatever toolchain to use to maintain that compatibility? > Compatibility is more important than the toolchain. > 4) Clang/LLVM was initiated by Apple, if I recall correctly, precisely > because GCC support for Objective-C is n

Re: Clang/LLVM migration roadmap

to qualify as an FSF sponsored project? This I think is more political than technical in any angle. 3) Is GNUstep valuing technical and functional compability with OpenStep and Cocoa over whatever toolchain to use to maintain that compatibility? 4) Clang/LLVM was initiated by Apple, if I recall correctly

Re: Clang/LLVM migration roadmap

I think the decision needs to tie back to the core mission of the project. I’m not 100% sure what that is. Is it “Grow the GNUStep user base?” Or is it “Maintain a fully copy-left tool chain?” Or some combination? Honesty, either way, I think llvm/clang is the right choice right now

Re: Clang/LLVM migration roadmap

Fred, On Sun, Feb 6, 2022 at 2:09 PM Fred Kiefer wrote: > > > > Am 06.02.2022 um 01:14 schrieb Gregory Casamento < > greg.casame...@gmail.com>: > > > > There are a number of factors that are driving this: > > -- > > 1) GCC lacks support for many memory management features that are > commonly

Re: Clang/LLVM migration roadmap

> On 6 Feb 2022, at 19:09, Fred Kiefer wrote: > > > >> Am 06.02.2022 um 01:14 schrieb Gregory Casamento : >> >> There are a number of factors that are driving this: >> -- >> 1) GCC lacks support for many memory management features that are commonly >> used today >> 2) GCC's objective-c

Re: Clang/LLVM migration roadmap

> Am 06.02.2022 um 01:14 schrieb Gregory Casamento : > > There are a number of factors that are driving this: > -- > 1) GCC lacks support for many memory management features that are commonly > used today > 2) GCC's objective-c support is lagging behind and doesn't include support > for @[],

Re: Clang/LLVM migration roadmap

Hi Max, > Apple has released Swift for Linux amd64 and Windows. Can we piggyback on > that? The Objective-C interoperability layer of the Swift programming language depends on the internal Apple Objective-C runtime and is therefore not available on Linux and Windows. It is possible to

Re: Clang/LLVM migration roadmap

> On 6 Feb 2022, at 09:35, Andreas Fink wrote: > > So to summarize up, we need to get libobjc2 properly working under MSYS2 and > we can continue with clang. > What are the isuses with libobjc2 not working under MSYS2? From what I know > libobj2 should not have many dependencies on the

Re: Clang/LLVM migration roadmap

his is not a show-stopper but is > something to consider. > > Advantages of LLVM/Clang > -- > 1) ARC > 2) support for modern features in objc that are commonly used > 3) more developers will be able to port their applications to GNUstep > > Disadvantages > -- > 1) li

Re: Clang/LLVM migration roadmap

ile some older architectures are, > perhaps, not as important, building on Windows under MSYS2 is critical. > 2) GNUstep is an FSF project, so there is a political component if we don't > support GCC anymore. This is not a show-stopper but is something to > consider. > > Advantages o

Clang/LLVM migration roadmap

there is a political component if we don't support GCC anymore. This is not a show-stopper but is something to consider. Advantages of LLVM/Clang -- 1) ARC 2) support for modern features in objc that are commonly used 3) more developers will be able to port their applications to GNUstep Disadvantages -- 1

Re: LLVM ERROR: Cannot select: intrinsic %llvm.objc.clang.arc.use

/lib64 -L/usr/local/lib64 -L/usr/lib64 > -L/usr/lib64/ng-gnu-gnu -L/usr/lib64 -lgnustep-base -lpthread -lobjc -lm > LLVM ERROR: Cannot select: intrinsic %llvm.objc.clang.arc.use > clang-11: error: unable to execute command: Aborted (core dumped) > clang-11: error: linker command fai

LLVM ERROR: Cannot select: intrinsic %llvm.objc.clang.arc.use

/lib64 -L/usr/lib64/ng-gnu-gnu -L/usr/lib64 -lgnustep-base -lpthread -lobjc -lm LLVM ERROR: Cannot select: intrinsic %llvm.objc.clang.arc.use clang-11: error: unable to execute command: Aborted (core dumped) clang-11: error: linker command failed due to signal (use -v to see invocation

Re: Only build llvm backend parts needed for GNUstep

lds are quite large, but release builds are >>> a lot smaller. The back ends only add a couple of MBs, so it’s not worth >>> removing them. >>> >>> David >> >> Hmmm... is the default to do a debug build? I simply checked out llvm and >&g

Re: Only build llvm backend parts needed for GNUstep

’s not worth removing them. David Hmmm... is the default to do a debug build?  I simply checked out llvm and build using the following steps: Ah, yes, I see from the first line of cmake's output that it defaults to a Debug build.  I will try doing a release build, hopefully it'll take much less sp

Re: Only build llvm backend parts needed for GNUstep

On 13 Dec 2015, at 19:06, Patryk Laurent <plaur...@me.com> wrote: > > Does anyone know, offhand, how to have clang/llvm only build what is required > for GNUstep? I recently built the latest clang/llvm from sources, and found > that the whole thing requires about 20GB! But I s

Re: Only build llvm backend parts needed for GNUstep

On Dec 13, 2015, at 12:25 PM, David Chisnall <thera...@sucs.org> wrote: On 13 Dec 2015, at 19:06, Patryk Laurent <plaur...@me.com> wrote: Does anyone know, offhand, how to have clang/llvm only build what is required for GNUstep? I recently built the latest clang/llvm from source

Re: Problems building gnustep-base on Ubuntu Linux with clang/llvm-3.7

On 30 Sep 2015, at 17:09, David Lobron wrote: > > Ah, you are right. I modified the conftest.c compile command so that it has > -L/usr/lib as the first -L argument, and it now compiles fine (my libobjc > from libobjc2 lives in /usr/lib, whereas the gcc versions are in >

Re: Problems building gnustep-base on Ubuntu Linux with clang/llvm-3.7

> This implies that you’re linking the wrong libobjc. _Block_copy is provided > by libobjc2, so if you can’t find it then you’re probably linking the gcc > libobjc. Did you force-uninstall the gcc objective-c package? Ah, you are right. I modified the conftest.c compile command so that it

Re: Problems building gnustep-base on Ubuntu Linux with clang/llvm-3.7

Hi David- > Can you find the output in config.log from the test that’s determining that > you don’t have blocks support? It may be that you need to add -fblocks to > [OBJ]C[C]FLAGS. Just to confirm: You did reconfigure / reinstall > GNUstep-make after reinstalling the runtime? Yes- I'm

Re: Problems building gnustep-base on Ubuntu Linux with clang/llvm-3.7

On 29 Sep 2015, at 16:21, David Lobron wrote: > > configure:14837: clang -o conftest -m64 -march=opteron -mno-3dnow -ggdb -O2 > -Wall > -I/home/dlobron/build/clangport/akamai/common/GNUstep/Local/Library/Headers >

Re: Problems building gnustep-base on Ubuntu Linux with clang/llvm-3.7

On 28 Sep 2015, at 19:02, David Lobron wrote: > > Hey David, > >> /usr/local/{include,lib} is not in the default search path for gcc / clang >> on Ubuntu. You should install libobjc2 with the prefix set to /usr/ or >> explicitly add /usr/local to the search paths when

Re: Problems building gnustep-base on Ubuntu Linux with clang/llvm-3.7

: /usr/local/bin/clang ... Compiler: /usr/local/bin/clang++ > On Ubuntu, we’ve had some issues here because the clang package depends on > gcc-objc (for no good reason), which pulls in the gcc runtime. Force > uninstalling it helps. I build and installed clang/llvm from source

Re: Problems building gnustep-base on Ubuntu Linux with clang/llvm-3.7

Thanks very much for the help, David. A few more comments: > Please try the most recent release (1.8.1, see: > https://github.com/gnustep/libobjc2/releases ), which incorporates some more > error checking and recovery into the build process (not to mention a number > of other bug fixes).

Re: Problems building gnustep-base on Ubuntu Linux with clang/llvm-3.7

Hey David, > /usr/local/{include,lib} is not in the default search path for gcc / clang on > Ubuntu. You should install libobjc2 with the prefix set to /usr/ or > explicitly add /usr/local to the search paths when configuring -make (see my > earlier email). I rebuilt libobjc2 with the prefix

Re: Problems building gnustep-base on Ubuntu Linux with clang/llvm-3.7

r no good reason), which pulls in the gcc runtime. Force >> uninstalling it helps. > > I build and installed clang/llvm from source (I checked out the sources with > svn, and then did mkdir build; cd build; cmake -G "Unix Makefiles" ../llvm; > make; make install).

Re: Problems building gnustep-base on Ubuntu Linux with clang/llvm-3.7

On 28 Sep 2015, at 17:18, David Lobron wrote: > > The above line appears under the "Cache variables" section in the config.log. > I do not have a cache file in my build tree, so I don't think I'm picking up > an obsolete value. Do you know how this variable would be set

Re: Problems building gnustep-base on Ubuntu Linux with clang/llvm-3.7

Hi David, > On 24 Sep 2015, at 20:14, David Lobron <dlob...@akamai.com> wrote: > > Hi All, > > I am trying to build gnustep-base-1.24.8 on Ubuntu Linux, and hitting a few > snags. I would be very grateful if someone could suggest where I'm going > wrong. >

Re: Problems building gnustep-base on Ubuntu Linux with clang/llvm-3.7

Hi, David Lobron ha scritto: mkdir Build; cd Build; cmake .. -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ This resulted in the following error: -- Untested version of LLVM (3.8.0svn) found. -- Disabling LLVM options unless explicitly enabled. -- No C++ runtime library found

Problems building gnustep-base on Ubuntu Linux with clang/llvm-3.7

Hi All, I am trying to build gnustep-base-1.24.8 on Ubuntu Linux, and hitting a few snags. I would be very grateful if someone could suggest where I'm going wrong. I first installed the llvm compiler, clang-3.8.0. I tried to build gnustep-base after that with clang, but the configure script

Re: Compile GNUStep Base (Foundation) with Xcode and Clang/LLVM 5.0

The main issue, probably, is that you often unintentionally pull in a lot of the Apple frameworks when trying to compile GNUstep code. Here’s some description of that: http://wiki.gnustep.org/index.php/Platform:BSD#Mac_OS_X On Jan 29, 2015, at 2:34 PM, Fred Kiefer fredkie...@gmx.de wrote: Hi

Compile GNUStep Base (Foundation) with Xcode and Clang/LLVM 5.0

Hey everyone, With the introduction of Apple's Swift, I recently started a pet project of sorts to port the Cocos2D-iPhone engine to rid it of all Apple dependencies in order to turn it into a multi-platform Obj-C game engine for us Objective-C lovers out there. The initial objective is to get

Re: Compile GNUStep Base (Foundation) with Xcode and Clang/LLVM 5.0

Hi Uriel, the only GNUstep system that I am aware of that compiled on MacOSX was the attempt Marat Ibadinov made. You find his code on github https://github.com/Ibadinov?tab=repositories Hope this helps Fred Am 29.01.2015 um 07:19 schrieb Uriel Griffin: Hey everyone, With the introduction

Re: Typedef errors when building llvm/clang/gnustep

that it can work with old versions of GCC. It shouldn't be needed anymore. and daily llvm/clang svn. Is the llvm/clang svn needed anymore? or is it safe to use a release version such as 3.2 or 3.3 of LLVM? No, although there are improvements in clang trunk relating to property introspection

Re: Typedef errors when building llvm/clang/gnustep

I had been checking out libobjc2, the previous e-mail had a typo. As far as I understand it LLVM 3.3 came out today, but as I was saying I'd been having issues building llvm/clang/gnustep. I'll give it another go and see if I can make some headway on it :) On 27 March 2013 19:36, David Chisnall

Re: Typedef errors when building llvm/clang/gnustep

On 27 Mar 2013, at 09:11, James Carthew wrote: I had been checking out libobjc2, the previous e-mail had a typo. As far as I understand it LLVM 3.3 came out today, but as I was saying I'd been having issues building llvm/clang/gnustep. I'll give it another go and see if I can make some

Re: Typedef errors when building llvm/clang/gnustep

using current clang svn and current llvm svn so version 3.3 HAVE_BLOCKS=' ' OBJCRUNTIME=' ' On 25 March 2013 07:24, Fred Kiefer fredkie...@gmx.de wrote: On 24.03.2013 21:13, James Carthew wrote: When compilling gnustep-base receiving error messages like these: Making all for subproject

Typedef errors when building llvm/clang/gnustep

'struct objc_property *') typedef void *objc_property_t; ^ Have been trying to use the gnustep install script which checks out and downloads llvm/clang/gnustep/gnustep-apps from svn. I've also tried to manually compile each package using llvm/clang

Re: Typedef errors when building llvm/clang/gnustep

with different types ('void *' vs 'struct objc_property *') typedef void *objc_property_t; ^ Have been trying to use the gnustep install script which checks out and downloads llvm/clang/gnustep/gnustep-apps from svn. I've also tried to manually compile each package using llvm

Re: building llvm optimizations for libobjc2

. which would build the whole llvm/cmake and install the whole llvm/cmake No, it will build and install just the optimisations, but it needs to build it inside the LLVM tree currently. . Is there a way to just only build and install the optimizations? Yes, build_opts.sh gmake, build_opts.sh gmake

Re: building llvm optimizations for libobjc2

to run a build_opts.sh gmake all and then later a build_opts.sh gmake install, Correct. which would build the whole llvm/cmake and install the whole llvm/cmake No, it will build and install just the optimisations, but it needs to build it inside the LLVM tree currently

Re: building llvm optimizations for libobjc2

the llvm optimizer, reading further, I should do opt -load=libGNUObjCRuntime.so -gnu-nonfragile-ivar -gnu-objc-type-feedback inputfile You can do that too, although if it's built against LLVM 3 or later it will automatically add the optimisations in sensible points at the default places

Re: building llvm optimizations for libobjc2

as well, but I've never tried. but unfortunately, this doesn't tells me much :( man opt tells me, its the llvm optimizer, reading further, I should do opt -load=libGNUObjCRuntime.so -gnu-nonfragile-ivar -gnu-objc-type-feedback inputfile You can do that too, although if it's built

Re: [cfe-dev] LLVM / Clang 3.0 rc1 Binaries Available

Le 7 nov. 2011 à 13:08, Richard Frith-Macdonald a écrit : On 7 Nov 2011, at 11:51, Quentin Mathé wrote: Hi, Just to mention that with Clang 3.0 rc1 and the current libobjc2 from trunk, I can compile GNUstep core and Gorm without troubles on Ubuntu 10.4 x86-32. For the test suite,

Re: [cfe-dev] LLVM / Clang 3.0 rc1 Binaries Available

On 21 Oct 2011, at 11:02, David Chisnall wrote: FYI: Please test on platforms you care about and file bugs... Using svn trunk for make/base/libobjc2 and using the 3.0 rc1 on debian 64bit I get a failure ~(uncaught exception) in the NSURL tests in basic.m ... I don't know whether it's a

Re: [cfe-dev] LLVM / Clang 3.0 rc1 Binaries Available

On Thursday, October 27, 2011 10:14 CEST, Richard Frith-Macdonald rich...@tiptree.demon.co.uk wrote: On 21 Oct 2011, at 11:02, David Chisnall wrote: FYI: Please test on platforms you care about and file bugs... Using svn trunk for make/base/libobjc2 and using the 3.0 rc1 on debian

Re: [cfe-dev] LLVM / Clang 3.0 rc1 Binaries Available

. The problem is not that the exception is thrown, it is that it is not caught. This means that either: - There is a bug in libobjc2's exception handling, or - One of your stack frames does not have unwind information. One of the bug changes that LLVM 3.0 made over 2.9 was to emit .cfi

Re: [cfe-dev] LLVM / Clang 3.0 rc1 Binaries Available

handling, or - One of your stack frames does not have unwind information. One of the bug changes that LLVM 3.0 made over 2.9 was to emit .cfi* directives in the assembler, instead of emitting the unwind tables directly. Do you get any warnings from the assembler about unknown directives when you

Fwd: [cfe-dev] LLVM / Clang 3.0 rc1 Binaries Available

FYI: Please test on platforms you care about and file bugs... Begin forwarded message: From: Bill Wendling wendl...@apple.com Subject: [cfe-dev] LLVM / Clang 3.0 rc1 Binaries Available Date: 21 October 2011 09:41:34 GMT+01:00 To: llvmdev List llvm...@cs.uiuc.edu, cfe-dev cfe-...@cs.uiuc.edu

Re: [cfe-dev] LLVM / Clang 3.0 rc1 Binaries Available

Just a tiny question: Apple has already shipped Apple LLVM Compiler 3.0 or something like that in Xcode 4.2. (I have not upgraded yet on my current machine, so I cannot check the exact naming). I suppose that Clang shipped by Apple is actually a prerelease as well? On Fri, Oct 21, 2011 at 12:02

Re: [cfe-dev] LLVM / Clang 3.0 rc1 Binaries Available

On 21 Oct 2011, at 17:40, Ivan Vučica wrote: Just a tiny question: Apple has already shipped Apple LLVM Compiler 3.0 or something like that in Xcode 4.2. (I have not upgraded yet on my current machine, so I cannot check the exact naming). I suppose that Clang shipped by Apple is actually

Re: building dbuskit fails with llvm/clang

Hello Sebastian! Thanks for catching these errors, they should now be resolved in svn. On Sat, Apr 09, 2011 at 12:01:38PM +0200, Sebastian Reitenbach wrote: On 04/09/11 11:39, David Chisnall wrote: I'm not sure why this code is using GSStackTrace, since the useful functionality of this

Re: building dbuskit fails with llvm/clang

I think the correct solution is to allow something like this: @classNSObject GSStackTrace; This would forward-declare the class, and also advertise that it conforms to the NSObject protocol. It's an interesting suggestion, and has good merit. :-) I would personally not like it that much

Re: building dbuskit fails with llvm/clang

On 10 Apr 2011, at 12:30, Nicola Pero wrote: If you message an object of a class which is only declared using @class, you should get a warning. Both GCC and clang don't warn about this. I think clang does. The problem is that, in this case, it never sees that the instances are of

Re: building dbuskit fails with llvm/clang

If you message an object of a class which is only declared using @class, you should get a warning. Both GCC and clang don't warn about this. I think clang does. On my machine, all compilers (both GCC and clang from trunk, as far as I can see) compile the following testcase with no

building dbuskit fails with llvm/clang

Hi, I extended the list of libs/apps to be compiled and what I want to add to the gnustep ports a little bit, and found dbuskit from svn does compile with gcc, but not with llvm/clang. The first error is, and is easy to fix, see attached patch: clang DKArgument.m -c \ -MMD -MP

Re: building dbuskit fails with llvm/clang

On 9 Apr 2011, at 10:29, Sebastian Reitenbach wrote: DKArgument.m:495:14: error: equality comparison with extraneous parentheses [-Werror,-Wparentheses] if ((type == DKDBusTypeForObjCType([sig methodReturnType]))) ~^~~~

Re: building dbuskit fails with llvm/clang

On 04/09/11 11:39, David Chisnall wrote: On 9 Apr 2011, at 10:29, Sebastian Reitenbach wrote: DKArgument.m:495:14: error: equality comparison with extraneous parentheses [-Werror,-Wparentheses] if ((type == DKDBusTypeForObjCType([sig methodReturnType])))

Re: building dbuskit fails with llvm/clang

On 9 Apr 2011, at 11:01, Sebastian Reitenbach wrote: I think the correct solution is to allow something like this: @classNSObject GSStackTrace; with this I get the error: DKEndpointManager.m:51:8: error: expected identifier @class NSObject GSStackTrace; Sorry, I meant that the correct

fix to build projectcenter with llvm was: applications that fail to build with new gnustep from svn

___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep $OpenBSD$ try to fix build with llvm/libobc2 --- Modules/Parsers/ProjectCenter/PCParser.m.orig Wed Apr 6 19:40:19 2011 +++ Modules/Parsers

LLVM 2.7 released...

... and the release notes mention GNUstep: http://llvm.org/docs/ReleaseNotes.html#clang David -- Send from my Jacquard Loom ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: LLVM

and incorporating objc-2.0 features using LLVM though. This brings me back to the idea of using a preprocessor that translates objc-2.0 to 1.0. This would have the great benefit that it works with *any* objc-1.0 compiler that is already available. I did already create some initial work. So

Re: LLVM

we'll have to somehow try to keep support for people who need to use gcc with the current gnu runtime and that would probably be difficult. That wouldn't stop me going ahead and incorporating objc-2.0 features using LLVM though. I would not recommend using Objective-C 2.0 features in GNUstep

Re: LLVM

) in their own tree forever. :-( And yet, they are developing LLVM in the main branch of the repository, while they were always consigned to a branch (I don't intend to go into the politics behind this decision, since it is very boring). Yes, a BSD license does let them be evil. At some point

Re: LLVM

On Feb 29, 2008, at 11:15 AM, Andrew Pinski wrote: On Fri, Feb 29, 2008 at 3:00 AM, Daniel J Farrell [EMAIL PROTECTED] wrote: 1) Why did Apple not think that GCC in good for the long run in your opinion? Because they did not see a short term benefit at all and the place is run by

Re: LLVM

As usual, world isn't white or black: There was/is a proposal to integrate LLVM into gcc and this message also addresses some of the licence issues. http://gcc.gnu.org/ml/gcc/2005-11/msg00888.html He reports a LLVM based compiler that is command-line compatible to gcc. I don't know anything

Re: LLVM

This post is from Chris Lattner, LLVM lead developer and now head of Apple's LLVM team. The compiler he is talking about is gcc-llvm, which uses the scanner and parser from GCC and the code generation from LLVM. For various reasons (licensing, ability to use the code in other projects

Re: LLVM

the objective-c front-end for gcc, I would not trust anything he says about maintable code or any thing about clang or LLVM. I would in fact say he has been anti GPL since the begining and this is his way to get back at the FSF. -- Pinski ___ Discuss

Re: LLVM

Hi, actually I asked Nicola about LLVM on FOSDEM ;-) License issues aside, I also think that it sounds very promising. First, I dislike this perspective: ---snip--- but this is not a convincing alternative - the license seems designed to abuse contributors. ---snap--- This is kinda

Re: LLVM

of CGObjCRuntime) and / or CGObjCEtoile. PS: the most convincing argument against LLVM I've heard so far is the target platform issue. Thats a pretty serious one. LLVM supports x86, ARM, SPARC and PowerPC with experimental MIPS, Alpha and IA64 support. What other platforms does GNUstep support? David

Re: LLVM

around to it because I always had better things to help out with inside GCC. LLVM supports x86, ARM, SPARC and PowerPC with experimental MIPS, Alpha and IA64 support. What other platforms does GNUstep support? Let's see 68k, sh, hurd. The ppc64 support is weak at best. Debugging support

Re: LLVM

On 01.03.2008, at 14:39, Andrew Pinski wrote: If you knew the history of this code you would blame the same person who is writing clang. I guess everyone forgets that the objc front was original written by Steve. I fail to see how this is relevant, it doesn't change the situation a bit.

Re: LLVM

actually I asked Nicola about LLVM on FOSDEM ;-) License issues aside, I also think that it sounds very promising. Unfortunately the license issues are very important. ;-) The license determines the duty and rights of the various parties; because at the moment we are the weak party in any

Re: LLVM

On 1 Mar 2008, at 14:16, Helge Hess wrote: So far I didn't read the license of clang, but wouldn't it be possible to license changes we do under GPL? (pretty much in the same line what you fear Apple could do ;-) The license for clang and LLVM is BSD-style. There is nothing stopping you

Re: [Etoile-discuss] LLVM

On Fri, 29 Feb 2008 09:02:51 -0800 Andrew Pinski [EMAIL PROTECTED] wrote: On Fri, Feb 29, 2008 at 8:54 AM, David Chisnall [EMAIL PROTECTED] wrote: I composed a long reply to Nicola's email, but this makes my point far better than I did. A few things: - LLVM is Free Software

Re: [Etoile-discuss] LLVM

*Please* no discussions on this topic! Its clear that LLVM is NOT Free Software. :-) [which doesn't necessarily imply that the licensing is unacceptable] Helge -- Helge Hess http://www.helgehess.eu/ ___ Discuss-gnustep mailing list Discuss-gnustep

Re: [Etoile-discuss] LLVM

://www.fsf.org/licensing/essays/free-sw.html *Please* no discussions on this topic! Its clear that LLVM is NOT Free Software. :-) [which doesn't necessarily imply that the licensing is unacceptable] I didn't jump on this in the original post, but I should have done. The FSF defines Free

Re: LLVM

On Sat, Mar 1, 2008 at 6:20 AM, David Chisnall [EMAIL PROTECTED] wrote: On 1 Mar 2008, at 13:39, Andrew Pinski wrote: Sent from my iPhone Didn't you say on the GCC list that you'd stopped using OS X? Maybe but that is not relevant to this conversation really. Also it might be due to I

Re: LLVM

Hi, On 2008-03-01 14:25:36 +0100 David Chisnall [EMAIL PROTECTED] wrote: LLVM supports x86, ARM, SPARC and PowerPC with experimental MIPS, Alpha and IA64 support. What other platforms does GNUstep support? GNUstep runs on 68k and HP-PA too, when using linux or NetBSD

Re: LLVM

? I can't imagine a HURD port would be too hard, since it's not a CPU architecture, and LLVM works on most other POSIXy platforms. 68k/linux used to work, but honestly didn't test the past months. To be honest about HURD: 2 years ago we required a patch for threading and then we did work, my

Re: LLVM

into the GCC project? Don't they have to do this anyway under GPL? Also, in your opinion, what do Apple perceived as the advantage to LLVM and clang? Cheers, Dan. On 29 Feb 2008, at 00:55, Andrew Pinski wrote: On Thu, Feb 28, 2008 at 4:46 PM, David Chisnall [EMAIL PROTECTED] wrote: I

Re: LLVM

One of the design goals for my runtime was to provide a superset of the functionality required for Objective-C 2.0. It was also designed with the aim of future integration with LLVM (and has a compatible license) (puzzled) :-) Do you really think that the LLVM license is a good license

  1   2   >