Re: Crash with new-style exceptions on FreeBSD amd64
On 3/14/07, Michael Gardner <[EMAIL PROTECTED]> wrote: Thanks for the hint. I played around with my manual compile command, and found that I can duplicate the crashing behavior of the gmake build if I do *either* of the following two things: 1) Omit "-fobjc-exceptions" from the command I gave above: g++41 -I$GNUSTEP_SYSTEM_ROOT/Library/Headers -L$GNUSTEP_SYSTEM_ROOT/Library/Libraries -lobjc -lgnustep-base -o main main.m (same result if I use gcc instead of g++). You still have to compile your program with -fexceptions to get "objc" exceptions working with objective-C. Thanks, Andrew Pinski ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Crash with new-style exceptions on FreeBSD amd64
On 3/14/07, Michael Gardner <[EMAIL PROTECTED]> wrote: In any case it wouldn't seem to explain why I don't get the crash if I do the compilation and linking in a single step, or if I use g++ instead of gcc. Are you also linking with -fexceptions. The issue is most likely the shared libgcc is not being used which causes exceptions not to work accross shared library boundaries. With g++, it automatically links with the shared libgcc, likewise when linking with -fexceptions. So can you look at the output of "ldd" on the executables build by a single step and built via two steps? You will most likely see in the case of a single step, it does not link against the shared libgcc. -- Pinski ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Crash with new-style exceptions on FreeBSD amd64
On 3/15/07, Richard Frith-Macdonald <[EMAIL PROTECTED]> wrote: I thought that compiling with '-x objective-c' was supposed to have the same effect as compiling a file with a .m extension too. If that understanding is correct, I don't see how the behavior you are seeing could be anything other than a compiler bug. Oh, I know what this is now. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31089 Thanks, Andrew Pinski ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Crash with new-style exceptions on FreeBSD amd64
On 3/15/07, Michael Gardner <[EMAIL PROTECTED]> wrote: On 3/15/07, Andrew Pinski <[EMAIL PROTECTED]> wrote: > On 3/15/07, Richard Frith-Macdonald <[EMAIL PROTECTED]> wrote: > > I thought that compiling with '-x objective-c' was supposed to have > > the same effect as compiling a file with a .m extension too. > > If that understanding is correct, I don't see how the behavior you > > are seeing could be anything other than a compiler bug. > > Oh, I know what this is now. > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31089 That bug's description doesn't seem to match the symptoms I'm seeing, and it's reported against gcc 4.3 rather than 4.1. For one, it is the same symptom, in that we are not linking against the shared libgcc which the driver does automatically for objective-C files if it is sees a .m. Try adding -shared-libgcc to the link line and see if that works. Again what is the ouput of ldd because that will tell me what is really happening? Thanks, Andrew Pinski ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Crash with new-style exceptions on FreeBSD amd64
On 3/19/07, Michael Gardner <[EMAIL PROTECTED]> wrote: Also, regarding the problem configuring gnustep-make with --enable-native-objc-exceptions: I emailed the port's maintainer, and he mentioned that he got the same result on his FreeBSD system. It looks like a gcc bug to me, but can anyone confirm it on a non-FreeBSD OS? Specifically, if you look at the output of ldd for a binary compiled from a .c file using '-x objective-c', libgcc is listed after libc. But if you rename the same file with a .m extension and compile it without the -x option, libgcc is listed before libc. Again this is the same problem as listed in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31089 Yes the bug report is against 4.3 but don't let that fool you. Also the reason why libgcc is listed after libc in the case with "-x objective-c" is that shared libgcc is not used by default unless gcc sees a objective-C file, in this case it matches with .m. Adding -shared-libgcc fixes the problem by forcing the shared libgcc to link to your program (instead of indirectly from a library). The way this works for Linux is slightly different and most likely no one else sees this, the standard specs for libgcc for linux, uses the option --as-needed which forces you to link to the shared libgcc if it is needed for eh (assuming your binutils is new enough). Maybe the specs for libgcc for FreeBSD needs to be updated for this new binutils options also and FreeBSD's binutils also updated. -- Pinski ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Use of libobjc from gcc 4.1 with MinGW
On 3/21/07, Xavier Glattard <[EMAIL PROTECTED]> wrote: Hi I found out how to compile gnustep-base with the gcc4.1 objc library (not the gnustep one). I can now enable native exceptions :-) I had to change one line in objc-decls.h : - #if defined (_WIN32) || defined (__WIN32__) || defined (WIN32) + #if !defined(__MINGW32__) && defined (_WIN32) || defined (__WIN32__) || defined (WIN32) I think this change is wrong for libobjc in general. The question comes down to why is mingw is special compared to cygwin, it is not. Now what is most likely happening is something is not being exported when it should be. I have an idea of what but since I don't run windows with libobjc, I don't know for sure. Thanks, Andrew Pinski ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Use of libobjc from gcc 4.1 with MinGW
On 3/21/07, Xavier Glattard <[EMAIL PROTECTED]> wrote: Without the change i got : So these names are not exported properly. I dont know why but mingw32 seems to be special... :-\ Is libobjc being compiled as a static library? I bet that is the real issue here. -- Pinski ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Use of libobjc from gcc 4.1 with MinGW
On 3/21/07, Xavier Glattard <[EMAIL PROTECTED]> wrote: Do you mean i would get the same error with a static gnustep-libobjc ? Yes. Should I build gcc-libobjc as a dll ? libobjc should be built as a dll, now how to fix this is a different story. Since I don't have much expence in building .dll, you might want to fittle with the .def file, and then fix the other part of the makefile to always build it, libtool way of building a .dll might be the way to go. Thanks, Andrew Pinski libobjc maintainer :) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Use of libobjc from gcc 4.1 with MinGW
On 3/22/07, Helge Hess <[EMAIL PROTECTED]> wrote: And you would need to tell gcc/ld *not* to link libobjc automatically. This could be the hardest part since internal libraries of GCC have weird lookup hacks in the compiler (-L has different semantics). Actually libobjc is not linked automatically anyways. But really then you have to change 99% of the makefiles out there including GNUStep's itself which is harder than changing GCC. Thanks, Andrew Pinski ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Moving GNUstep applications to GPLv3
On 6/29/07, Yen-Ju Chen <[EMAIL PROTECTED]> wrote: Maybe it is worth to wait and see how other big projects do, like GCC and GNOME. And see how it affects some aspects where GNUstep will be used, like web services (GNUstepWeb) or embedded system (mSTEP). GCC has been requested (required) to move over by the end of July. -- Pinski ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Fwd: Announcing libffi 3.0
FYI. -- Forwarded message -- From: Anthony Green <[EMAIL PROTECTED]> Date: Fri, Feb 15, 2008 at 12:16 PM Subject: Announcing libffi 3.0 To: [EMAIL PROTECTED] I'm pleased to announce a software release 10 years in the making: libffi 3.0 libffi is a portable foreign function interface library. The last release of libffi, version 1.2, was released almost a decade ago in October, 1998. Shortly thereafter we started maintaining it within the GCC source repository along with the help of the GCC developers. Libffi's primary customer at the time was the GNU java runtime library, libgcj, and libffi benefited tremendously from the contributions of the GCC community[1]. However... Over the course of the last decade, and especially within the past couple of years, many projects have picked up the old libffi release or extracted it from the GCC sources for their own purposes[2]. There now exist a multitude of libffi forks, and for no good reason other than there not being independent stand-alone libffi releases. libffi 3.0 represents the resumption of regular, independent, stand-alone releases of libffi for all to consume. libffi 3.0 is the result of bundling the latest libffi sources from the GCC tree along with new configury, enhancements, documentation and testing. libffi will continue to be maintained in both the GCC tree as well as the original libffi cvs repository. Patches are welcome to either project, as we intend to perform two-way merges between the trees. Visit the libffi project site at http://sourceware.org/libffi for details. Download source release here: ftp://sourceware.org:/pub/libffi/libffi-3.0.0.tar.gz Enjoy... Anthony Green [EMAIL PROTECTED] [1] A special "thank you" goes out to the GCC hackers who contributed to libffi all these years. libffi is widely used (see below) entirely thanks to your continued efforts. [2] A survey of libffi users/bundlers/forkers: http://spindazzle.org/greenblog/index.php?/archives/81-libffi-users.html ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: -lpthread
On Thu, Jun 5, 2008 at 2:17 AM, David Ayers <[EMAIL PROTECTED]> wrote: > I believe the issue is that historically the libobjc runtime could be > used with different threading libraries for its threading API. But if I > remember correctly, currently only POSIX Threads are supported. I'm not > 100% sure anymore so some would have to investigate, but I think the > approach to really fix the issue is that we need No, the windows threading is also supported, so are some variants of the POSIX threads (the 95 version in fact for older Solaris's). Thanks, Andrew Pinski ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: objc native exceptions
On Fri, Jun 27, 2008 at 8:35 AM, Richard Frith-Macdonald <[EMAIL PROTECTED]> wrote: > I was wondering if there was any good reason why gnustep-make doesn't enable > native exceptions by default if the compiler supports it. > I think the answer is that we can't readily install a default handler for > uncaught exceptions or support NSSetUncaughtExceptionHandler() with the > current state of the compiler/runtime as it does not provide us with any API > to deal with an exception thrown outside of a @try block. > > Would it be OK to add that functionality to the runtime in > objc_exception_throw() with two new functions something like this: > Yes in fact it was on my list of things TODO, see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27466 :). Thanks, Andrew Pinski ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: objc native exceptions
On Fri, Jun 27, 2008 at 9:57 AM, Nicola Pero <[EMAIL PROTECTED]> wrote: > I'm not too familiar with the issue, I only know that when I added support > for native exceptions to gnustep-make and tried to make it the default, > someone > else came out and turned it off again by default claiming that the overheads > are high. The overhead be non existent if there are no exceptions thrown (when using dwarf2 unwinding based exceptions which most targets use already). The only overhead is data size increases. Thanks, Andrew Pinski ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: objc native exceptions
On Fri, Jun 27, 2008 at 10:14 AM, Richard Frith-Macdonald <[EMAIL PROTECTED]> wrote: > So this would appear to be a rather severe drawback as invocations are used > quite extensively. Maybe the stack unwinding works if you used libffi for > your invocations, but libffi doesn't work on some platforms (eg the debian > 64bit intel box I develop on). libffi works on x86_64 as far as I know. Also libffi supports unwinding as it is needed to support GCJ :). -- Pinski ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep base almost builds with clang
On Tue, Mar 31, 2009 at 4:56 PM, Pete French wrote: > All the rest of the email, however, I agree with - the lack of > ObjC maintenance on GCC worries me greatly. I depend on this > stuff for my living, and for my business to make sales. Having > somewhere else to jump to would make me give a huge sigh of relief. Well if your business depends on it, you might want to hire someone someone to do the development. Apple has moved away from GCC so you can no longer depend on them. Maybe it is just me and your business model is incorrect to depend on free things when in reality there is no such thing as a free lunch. -- Pinski ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep base almost builds with clang
On Tue, Mar 31, 2009 at 5:51 PM, Pete French wrote: >> Well if your business depends on it, you might want to hire someone >> someone to do the development. > > Well, that would be me. But I kind of have a lot of other stuff to > do. I'll reprhrase it as "I dont want to take this on myself". > >> 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. I should have said moving away but really they are so close to have moved away, it can be considered moved. -- Pinski ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep base almost builds with clang
On Tue, Mar 31, 2009 at 6:00 PM, Pete French wrote: >> I should have said moving away but really they are so close to have >> moved away, it can be considered moved. > > So what have they moved to out of interest, or can't you tell us ? > Is this just for Obj-C or the whole operating system ? > Both, they are moving over to clang (and LLVM) witness the subject line :). -- Pinski ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Interesting discussion on gcc about objc
On Sep 13, 2010, at 6:08 AM, David Chisnall wrote: On 13 Sep 2010, at 13:53, Vincent Richomme wrote: GNU ObjC has so few users that it seems hardly worth the effort In the same time do you have an idea of how many people are interested in gnustep ? I would be very curious to know it. DO you some some fugures ? I've absolutely no idea. I suspect that OS X and the iPhone have increased interest a bit, and will a bit more once we have a UIKit implementation, but I don't have any real figures. The only data point I have is that all of the talks I gave at FOSDEM this year had people standing up in the audience because there weren't enough chairs in our devroom for everyone. I'm not condemning GCC for its stance. C and C++ are definitely much more popular languages than Objective-C, and I wouldn't blame them if they decided to completely drop Objective-C support. No one's really worked on it for around 7 years and the code that they inherited from NeXT is basically unmaintainable. I just get fed up with people saying 'we have to make an effort to support GCC because we are also a GNU project' when people on the GCC side say that supporting us is too much effort. Well if apple did the work like they should have done. This would not be an issue. So I still say blame apple and not support clang for the same reason. David -- Send from my Jacquard Loom ___ 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: Interesting discussion on gcc about objc
On Mon, Sep 13, 2010 at 9:23 AM, Pete French wrote: > In practical terms that stance doesn't exactly lead to us ending up with > a good complier though does it? Clang is a v.good compiler, and is being > maintained. Not supporting it is rather biting off our nose to spite > our face, especially if GCC isn't interested in supporting ObjC anymore. Well GCC is interested in Objective-C except we don't have anyone really working on it. That is the biggest issue right now. We want to support it; trust me. If someone would step up to the plate and do the supporting work, we will keep it. The biggest issue is that Apple had stepped up to the plate and then disappeared to go do clang because of politics due to GPLv3. Since GNUStep is a GNU project I think we should support GPLv3 friendly companies/projects before we give in to ones that don't want to even want to look at GPLv3 code. Thanks, Andrew Pinski ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Native ObjC exceptions configure test broken with libobjc2
On Sep 18, 2010, at 11:31 AM, David Chisnall wrote: On 18 Sep 2010, at 19:24, Nicola Pero wrote: I'd suggest that libobjc2 could include a minimal Object implementation. Having Object is handy to perform simple configure tests and both the Apple and GNU runtime include a minimal implementation for that reason ... it would make sense for libobjc2 to do so too ;-) Actually, this test will fail with Apple's Modern Runtime too - Object no longer implements +new. If you define __OBJC2__ (which recent Apple compilers do, you only get these two methods on Object: +class; -(BOOL) isEqual:anObject; +new is no longer allowed, so there is no defined way of creating Object instances. Using Object is generally not sensible, so I don't support it in libobjc2. Except that is part of the gnu runtime abi so not defining it will break other things in general. Else, if you have a patch to get the test to work with libobjc2 as it is, I'd happily accept it. I've already fixed most of the configure scripts to define their own root class, if they need it. It should be trivial to copy one of those across into this test. David ___ 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: Cross-compiling GNUstep?
On Mon, Dec 30, 2013 at 2:26 AM, David Chisnall wrote: > On 30 Dec 2013, at 07:23, Richard Frith-Macdonald > wrote: > >> In my experience CMake is far more of a burden because it doesn't have the >> years of documentation development that autoconf has, and (more importantly >> to me) because its a monolithic C program. You need to get the source and >> figure out what it's doing, and that's just easier to do with the configure >> script and macros in autoconf. > > This is simply not true. The vast majority of the logic of cmake is in the > .cmake files. The 'monolithic C program' (which is written in C++) is just > the interpreter. Large library projects typically distribute their own > .cmake files containing specific rules for their build systems, but these > compose with other rules. For example, LLVM ships a bunch of .cmake files, > which libobjc2 uses when building the LLVM optimisation passes. Qt, KDE, and > so on all ship custom .cmake files that simplify building apps for those > platforms. I don't think I've ever looked at the source for CMake, though I > use it for a number of projects - I've always found what I needed to do by > either reading the documentation or searching their mailing list archives. > > My main attraction to CMake, however, is not CMake itself as much as Ninja, > which dramatically improves life when doing a lot of incremental builds. > LLVM has both CMake and autoconf+make build systems. After changing one > file, the Ninja files that CMake generates can do an incremental build in > less time than it takes for the GNU Make build system to determine that it > has no work to do if you don't change any files. Oh, and when it needs to > reconfigure, rerunning cmake takes about a fifth of the time that running > ./configure takes, even though it's actually doing more work (configure just > sets some flags for some hand-written Makefiles to use, cmake generates the > build system). Yes it might be faster than autoconf/automake but it is less standardized things to do in cmake. I have played around with a cmake system in the last year and found it was horrible as the options that I needed to do for cross compiling was all different and did not always do the correct thing so I had to hack the files instead. autoconfig/automake has some nice standardized way of figuring out if an API and/or a library exists. When was the last time you did a cross of a library that was not autoconf'd? cmake was not designed for cross compiling or even fits in a GNU project. Yes autoconf has its issue (slow due to being a big shell script) but being slow helps the portability of it. Try building cmake itself, it is a hard thing to do really; worse than GCC. Thanks, Andrew Pinski > > For OS X users, there's a nice CMake GUI that lets you generate XCode project > files, which I imagine would be very attractive to users wanting to run > GNUstep code on that platform. The generated XCode files aren't perfect, but > they're a lot easier for OS X developers to use than GNUstep Make. Oh, and > they already support building .app and .framework bundles on OS X, so it > should be possible to reuse some of this code, which might even give us some > existing OS X applications running on GNUstep for free... > > That said, I completely agree with Fred, that there's no point discussing a > change of build system without at least a proof of concept demonstration that > another one would work. I would, however, suggest that this would be much > easier to do if we had some documentation describing things like the various > filesystem / bundle layouts. > > David > > -- Sent from my Cray X1 > > > ___ > Gnustep-dev mailing list > Gnustep-dev@gnu.org > https://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Problem implementing faults in Objective-C
On Jun 21, 2005, at 1:20 PM, Frederic Stark wrote: Timothy J. Wood wrote: [crunch] The code works correctly under Mac OS X. I just checked under linux/gcc 3.4 and the code works fine there. Maybe this is a gcc 3.2 specific problem. I'll check gcc 3.4 windows one of those days. It is a 3.2 specific bug. This was fixed in 3.4.0 at least for sure with: 2003-09-24 Ziemowit Laski <[EMAIL PROTECTED]> MERGE OF objc-improvements-branch into MAINLINE. See 'gcc/ChangeLog' and 'gcc/testsuite/ChangeLog' for the gory details. mainly: Fix PR objc/11754 When cascading message together under GNU runtime, GCC was sending the inner message twice, this patch fixes that. Also adds a testcase for that case. And the patch: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/objc/objc-act.c.diff? r1=1.179.2.4&r2=1.179.2.2 Thanks, Andrew Pinski ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make readiness for gcc 4.1
On Oct 5, 2005, at 10:52 PM, Nicola Pero wrote: I automatically added in the internal/system ObjC flags (eg, -fconstant-string-class=NSConstantString) though, I assume that's required to compile ObjC++. ;-) Yes those should be required to compile obj-c++. Thanks, Andrew Pinski ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Threads - does the @synchronized Directive work?
On Dec 20, 2005, at 6:34 PM, David Wetzel wrote: hi folks, I just red that @synchronized does not work with the GNU runtime yet. There is a bug in gcc's bugzilla to record that fact. I just have not got around to fixing it yet. -- Pinski ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Undefined symbol "__Unwind_Resume"
On May 13, 2006, at 2:59 PM, Oliver Langer wrote: Hi, i got stock on an linker problem and maybe someone can help me...: On my OS X 10.4 box using gcc-4.0.1 my linker tells me "ld: Undefined symbols: __Unwind_Resume" I am using the following gcc-params: "-prebind -dynamiclib - lpthread -lstdc++" and i am compiling c++ sources. You should be linking with g++ or add -fexceptions. -- Pinski ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Debug as default...
On Wed, 2006-09-20 at 06:33 +0200, Nicola Pero wrote: > >> Anyway, let me know if '-g -O2' causes problems, I presume if the '-O2' > >> seriously confuse the debugger let me know and we can revert that change, > >> or maybe use '-g -O' ? > > > > Use of -O2 makes debugging almost impossible ... with that > > combination, in gdb, you can (mostly) follow program flow, but you > > can hardly ever examine variables. > > Ok ... makes sense, I'll take the -O% out again then ;-) Actually that is not 100% acturate. It makes it impossible on stabs targets but with dwarf2/3 (which is default for GNU/Linux), GCC 4.0 and above do a better job at outputting debug info for -O2. -- Pinski ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
