Re: Changes to graphic context handling
Fred,
I tried the new svn 24903 with your changes. It looks like printing
works now, when using the art backend. Cairo does not generate good
EPS, but at least it tries.
On the related subject of Cairo, I just submitted 3 bug reports,
including the printing problem. I submitted the TestApp that I used
for debugging NSBitmapImageRep that you might find useful.
Cheers,
Mark Tracy
On Mar 19, 2007, at 6:29 AM, Fred Kiefer wrote:
Mark Tracy wrote:
The change you made has broken one of my programs. I am printing
from a
windowless custom view because I want to lay out the report for paper
not the screen. Maybe not a wise strategy, but certainly not an
illegal
one. This works fine for Cocoa and for previous editions of GNUstep.
In svn 24892, NSView.m line 1900, there is:
- (void) lockFocusInRect: (NSRect)rect
{
[self _lockFocusInContext: [_window graphicsContext] inRrect:
rect]
}
In my program, since the view is not associated with a window, nil is
passed, and I get a segfault trying to read the context.
I changed it to read:
- (void) lockFocusInRect: (NSRect)rect
{
NSGraphicsContext *ctxt =
(_window ? [_window graphicsContext] : GSCurrentContext() );
[self _lockFocusInContext: ctxt inRect: rect];
}
This appears to solve my problem, but it should be reviewed by
someone
who has a deeper knowledge.
Hi Mark,
thank you very much for this bug report. It shows that somebody is
using
the print functionality in GNUstep. What you are doing is quite
legitimate and GNUstep has to support it.
I have tried to correct the problem you found in a slightly different
way. Could you please have a go with current SVN source and report
back,
if it still fails? There will be a couple of further changes to the
graphics context handling in the next weeks. I try to do this big
change
rather smoothly, but you already discovered the first error here. So
please test this from time to time for new errors.
Cheers,
Fred
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
-draggedImageLocation giving incorrect results?
I've got some code in an NSImageView subclass that looks like this:
-(void) mouseDown: (NSEvent*)event
{
...
[self dragImage: [self image] at: NSZeroPoint offset:
NSZeroSize event: event pasteboard: pboard source: self slideBack:
YES];
...
}
and in the dragging destination, I position the dropped object at
[sender draggedImageLocation]. This worked in the latest release
version of GNUstep, but in trunk the value that I get from
-draggedImageLocation is offset by 1 pixel horizontally and 9 pixels
vertically from where it should be. I believe those dimensions are
exactly the width and height of the decorations on the left and bottom
edges of the enclosing window, respectively.
-Michael
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Byte swapping for doubles
This has been hanging around in my Inbox for a while. I found this about how the ARM ABI deals with doubles: VFP is a newer floating point architecture for ARM. With respect to endianess, the word endianess of doubles is always the same as the byte endianess of words. This contrast with the older and more common FPA architecture, which always uses big endian for doubles. In both architectures, the word endianness of 64-bit ints matches the word endianess of doubles. After looking at NSByteOrder.h, it appears we do it correctly, as far as I can tell, swapping doubles the same ways as 64-bit int. Does Nikolaus (or anyone) have an actual bug report which shows the problem? I'm not sure I want to change anything without at least some one to verify it. On Feb 6, 2007, at 9:00 AM, Fred Kiefer wrote: I had an email discussion with Nikolaus Schaller about the code in NSByteOrder.h which does the byte swapping for GNUstep and he convinced me that we may not handle the case of swapping doubles correctly for certain ARM processors. Here the word order in doubles seems to differ from the general byte order. I had a quick search on the web and found ax_cv_c_float_words_bigendian (See http://autoconf-archive.cryp.to/ax_c_float_words_bigendian.html). Is there anybody out there, who understands word/byte order a bit better and is able to fix this? ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Please digg this, we want GNUstep's Summer of Code participation's place in the limelight!
On 3/19/07, Yen-Ju Chen <[EMAIL PROTECTED]> wrote: dzone.com may be more focus on developers. Let me see whether I can put it on the blog. That's a good idea! I have no idea how digg works, it seems like some articles make it to the front page with 40 diggs, yet when we got 40 it didn't do anything. We're up to 44, so let's at least see if we can get to 50! (Just read Lars' response, but still, lets get it as high as we can) Like I said on the other conversation though, it would be a good idea to start digging any interesting news on your GNUstep blog. Lars (I think that's his name) started digging the WebKit story. Stefan ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Please digg this, we want GNUstep's Summer of Code participation's place in the limelight!
Am 19.03.2007 um 20:18 schrieb Stefan Bidigaray: It seems like the votes have stagnated! I'd like to see this go to the front page, yet we only have 39 diggs so far, I can't believe there are only 39 people that read these mailing lists who are interested in GNUstep. I'm not sure how many diggs we need to get to the front page, but I think it's 40, which means we only need 1 more vote, come on people! Thats seems to be no fixed number, according to [1] several other "secret" factors are considered. I've seen stories with only 35 diggs on the frontpage and stories with more than 60 diggs gone unpublished. Blogging about it is also said to be helpful. But then again: new game, new luck: http://gnustep.blogspot.com/ 2007/03/help-port-webkit-to-gnustep.html Just do it! Stefan [1] http://computer.howstuffworks.com/digg.htm regards, Lars ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Please digg this, we want GNUstep's Summer of Code participation's place in the limelight!
On 3/19/07, Stefan Bidigaray <[EMAIL PROTECTED]> wrote: It seems like the votes have stagnated! I'd like to see this go to the front page, yet we only have 39 diggs so far, I can't believe there are only 39 people that read these mailing lists who are interested in GNUstep. I'm not sure how many diggs we need to get to the front page, but I think it's 40, which means we only need 1 more vote, come on people! dzone.com may be more focus on developers. Let me see whether I can put it on the blog. Yen-Ju Just do it! Stefan ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: FILE* interface to NSString or NSData?
The class you are asking for is NSStream plus its subclasses NSInputStream and NSOutputStream. Michael Hopkins wrote: > > Hi all > > We want to convert a C library that reads from and writes to binary FILE* > descriptors using fread() & fwrite() to do the same thing but accessing e.g. > NSString or NSData objects instead. > > Is there some accepted (cross-platform safe) way of doing this using > Foundation/GNUstep-base? We have the whole compatible subset of Cocoa > Foundation and GNUstep-base available if a solution needs other classes to > be involved. > > Thx - links appreciated and feel free to CC me > > Michael > > _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ > > _/_/ _/_/_/ Hopkins Research Ltd >_/_/ _/_/ > _/_/_/_/ _/_/_/ http://www.hopkins-research.com/ > _/_/ _/ _/ > _/_/ _/ _/ 'touch the future' > > _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ > > > > > > ___ > 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: Please digg this, we want GNUstep's Summer of Code participation's place in the limelight!
It seems like the votes have stagnated! I'd like to see this go to the front page, yet we only have 39 diggs so far, I can't believe there are only 39 people that read these mailing lists who are interested in GNUstep. I'm not sure how many diggs we need to get to the front page, but I think it's 40, which means we only need 1 more vote, come on people! Just do it! Stefan ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
RE: Problem building gnustep-base tools with MinGW
>> Mine is: >> >> gcc -Wl,--enable-auto-import -fgnu-runtime -o obj/autogsdoc.exe >> ./obj/autogsdoc.o ./obj/AGSParser.o ./obj/AGSOutput.o ./obj/AGSIndex.o >> ./obj/AGSHtml.o >>-L../Source/./obj -L/home/Nico/GNUstep/Library/Libraries >> -L/usr/local/lib -L/usr/local/lib -L/usr/local/lib/gnu-gnu-gnu >> -L/usr/local/lib -lgnustep-base-lobjc -L/usr/local/lib -lxml2 -lz >> -liconv -lws2_32 -liconv -lcallback -lavcall -liberty -lz -lws2_32 >> -ladvapi32 -lcomctl32 -luser32 -lcomdlg32 -lmpr -lnetapi32 -lm -I. > > With layout=fhs mine is : > >gcc -Wl,--enable-auto-import -fgnu-runtime -o obj/autogsdoc.exe > ./obj/autogsdoc.o ./obj/AGSParser.o ./obj/AGSOutput.o ./obj/AGSIndex.o >./obj/AGSHtml.o > -L../Source/./obj -L/home/Xavier/GNUstep/Library/Libraries > -L/usr/local/lib -L/usr/local/lib -L/usr/local/lib/gnu-gnu-gnu > -L/usr/local/lib -L/usr/local/lib -lgnustep-base-lobjc -lxslt >-L/usr/local/lib -lxml2 -L/usr/local/lib -lz -lws2_32 > -liconv -lcallback -lavcall -lbfd -liberty -lz -lws2_32 > -ladvapi32 -lcomctl32 -luser32 -lcomdlg32 -lmpr -lnetapi32 -lm -I. The only difference that I can see if that you have -lxslt ... could it be anything to do with the problem ? Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
FILE* interface to NSString or NSData?
Hi all We want to convert a C library that reads from and writes to binary FILE* descriptors using fread() & fwrite() to do the same thing but accessing e.g. NSString or NSData objects instead. Is there some accepted (cross-platform safe) way of doing this using Foundation/GNUstep-base? We have the whole compatible subset of Cocoa Foundation and GNUstep-base available if a solution needs other classes to be involved. Thx - links appreciated and feel free to CC me Michael _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _/_/ _/_/_/ Hopkins Research Ltd _/_/ _/_/ _/_/_/_/ _/_/_/ http://www.hopkins-research.com/ _/_/ _/ _/ _/_/ _/ _/ 'touch the future' _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
RE: Problem building gnustep-base tools with MinGW
Selon Nicola Pero <[EMAIL PROTECTED]>: > I rebooted under Windows XP and I can't reproduce your problem at all - it > links fine for me (I removed the installed gnustep-base before trying). :-( > > So I'm not sure why it doesn't work for you. Neither do i :-( I looks like the libgnustep-base that has just been built is incomplete... Anyway : thanks for the time you spent on this problem > The only differences between my case and you case are ... my GCC is 3.4.2 > while you mention that you're using 4.1.2. I tried with gcc 3.4.2 from MinGW and it fails too. I re-installed mingw, msys and all libs... nothing changed... I cant even build the old release version !! I really dont understand anything. I give up for today :-\ > My GCC link command is also slightly different (...) > Mine is: > > gcc -Wl,--enable-auto-import -fgnu-runtime -o obj/autogsdoc.exe > ./obj/autogsdoc.o ./obj/AGSParser.o ./obj/AGSOutput.o ./obj/AGSIndex.o > ./obj/AGSHtml.o > -L../Source/./obj -L/home/Nico/GNUstep/Library/Libraries > -L/usr/local/lib -L/usr/local/lib -L/usr/local/lib/gnu-gnu-gnu > -L/usr/local/lib -lgnustep-base-lobjc -L/usr/local/lib -lxml2 -lz > -liconv -lws2_32 -liconv -lcallback -lavcall -liberty -lz -lws2_32 > -ladvapi32 -lcomctl32 -luser32 -lcomdlg32 -lmpr -lnetapi32 -lm -I. With layout=fhs mine is : gcc -Wl,--enable-auto-import -fgnu-runtime -o obj/autogsdoc.exe ./obj/autogsdoc.o ./obj/AGSParser.o ./obj/AGSOutput.o ./obj/AGSIndex.o ./obj/AGSHtml.o -L../Source/./obj -L/home/Xavier/GNUstep/Library/Libraries -L/usr/local/lib -L/usr/local/lib -L/usr/local/lib/gnu-gnu-gnu -L/usr/local/lib -L/usr/local/lib -lgnustep-base-lobjc -lxslt -L/usr/local/lib -lxml2 -L/usr/local/lib -lz -lws2_32 -liconv -lcallback -lavcall -lbfd -liberty -lz -lws2_32 -ladvapi32 -lcomctl32 -luser32 -lcomdlg32 -lmpr -lnetapi32 -lm -I. > You also mention using --enable-native-objc-exceptions ... I can't use it > because > gnustep-make detects that my 3.4.2 GCC compiler doesn't support them. I tried but i cant. As i said --enable-native-objc-exceptions is only accepted by gnustep-make configure script when i dont install gnustep-libobjc (use gcc one instead) but then i can't build gnustep-base (i may send you more detail). With gnustep-libobjc at least the library is built, i only cant build tools. > If you are using --enable-native-objc-exceptions you may want to try again > with gnustep-make from trunk where we fixed the compile/link flags required > to use them. ;-) > > Anyway, if you're using GCC 4.1.2 + native-objc-exceptions, that might be > the cause why the link stage is failing. You can either figure out how to > make native ObjC exceptions to work on GCC 4.1.2, or you could fall back > to the tried-and-tested GCC 3.4.2 with no native ObjC exceptions ;-) > > Hope this helps somehow > > Thanks > > > > > -Original Message- > From: [EMAIL PROTECTED] > Sent: Fri, March 16, 2007 4:59 pm > To: gnustep-dev@gnu.org > Subject: Problem building gnustep-base tools with MinGW > > Hi > > I'm trying to rebuild my GNUstep system from svn. > > 0) WinXP/MinGW/MSYS, GCC412 > 1) gnustep-make is installed in C:/GNUstep > 2) gnustep-libobjc is installed >*Note* : gnustep-libobjc dont work with native_objc_exceptions >and base can be linked against gcc-libobjc (is that correct?) > 3) ffcall, etc.. are installed > 4) gnustep-base fails in linking autogsdoc : it can't find any GS class >that have just been built (see log) > > Thanks for your help > > Xavier ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSMutableDictionary requires NSCopying?
On 2007-03-19 02:43:36 -0800 Richard Frith-Macdonald <[EMAIL PROTECTED]> wrote: On 19 Mar 2007, at 10:24, Michael Gardner wrote: To use a custom key type with NSMutableDictionary, I defined -hash and -isEqual: but not -copyWithZone:, since the NSDictionary docs say that keys are retained rather than copied. But when I try to insert a key of that type, I get an NSInvalidArgumentException saying that my class does not recognize -copyWithZone:. If I add that method, the exception goes away and everything works fine. I've tried this on both the latest GNUstep release and on trunk. Are the docs just out-of-date? Yes, the documentation is just wrong. Dictionary keys do need to be copied. I've fixed the documentation (at least, all the errors I spotted) in svn trunk to say that keys are copied. possibly worthwile to explain why things are copied and not retained, if you add a mutable object to a dictionary and subsequently modify the object in a way which modifies the objects -hash value, it would become inconsistent with the hash value stored in the dictionary. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes to graphic context handling
Mark Tracy wrote:
> The change you made has broken one of my programs. I am printing from a
> windowless custom view because I want to lay out the report for paper
> not the screen. Maybe not a wise strategy, but certainly not an illegal
> one. This works fine for Cocoa and for previous editions of GNUstep.
>
> In svn 24892, NSView.m line 1900, there is:
> - (void) lockFocusInRect: (NSRect)rect
> {
> [self _lockFocusInContext: [_window graphicsContext] inRrect: rect]
> }
>
> In my program, since the view is not associated with a window, nil is
> passed, and I get a segfault trying to read the context.
>
> I changed it to read:
> - (void) lockFocusInRect: (NSRect)rect
> {
> NSGraphicsContext *ctxt =
> (_window ? [_window graphicsContext] : GSCurrentContext() );
> [self _lockFocusInContext: ctxt inRect: rect];
> }
>
> This appears to solve my problem, but it should be reviewed by someone
> who has a deeper knowledge.
>
Hi Mark,
thank you very much for this bug report. It shows that somebody is using
the print functionality in GNUstep. What you are doing is quite
legitimate and GNUstep has to support it.
I have tried to correct the problem you found in a slightly different
way. Could you please have a go with current SVN source and report back,
if it still fails? There will be a couple of further changes to the
graphics context handling in the next weeks. I try to do this big change
rather smoothly, but you already discovered the first error here. So
please test this from time to time for new errors.
Cheers,
Fred
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSMutableDictionary requires NSCopying?
On 19 Mar 2007, at 10:24, Michael Gardner wrote: To use a custom key type with NSMutableDictionary, I defined -hash and -isEqual: but not -copyWithZone:, since the NSDictionary docs say that keys are retained rather than copied. But when I try to insert a key of that type, I get an NSInvalidArgumentException saying that my class does not recognize -copyWithZone:. If I add that method, the exception goes away and everything works fine. I've tried this on both the latest GNUstep release and on trunk. Are the docs just out-of-date? Yes, the documentation is just wrong. Dictionary keys do need to be copied. I've fixed the documentation (at least, all the errors I spotted) in svn trunk to say that keys are copied. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
NSMutableDictionary requires NSCopying?
To use a custom key type with NSMutableDictionary, I defined -hash and -isEqual: but not -copyWithZone:, since the NSDictionary docs say that keys are retained rather than copied. But when I try to insert a key of that type, I get an NSInvalidArgumentException saying that my class does not recognize -copyWithZone:. If I add that method, the exception goes away and everything works fine. I've tried this on both the latest GNUstep release and on trunk. Are the docs just out-of-date? Also, cross-module links in the GNUstep API docs seem to be broken. For example, links for NSRect from the GUI API docs point to: http://www.gnustep.org/Users/fedor/gnustep-Eldorado/System/Library/Documentation/Developer/Base/Reference/TypesAndConstants.html#type$NSRect which, of course, leads nowhere. This doesn't really affect me now, but it was rather confusing when I was first looking through the documentation. -Michael ___ 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
Thanks for the tips. I just installed GNUstep from trunk, and can confirm that the problem is fixed. :) -Michael On 3/19/07, Nicola Pero <[EMAIL PROTECTED]> wrote: >> That's brilliant ... I added --shared-libgcc (on all platforms) to the >> linking stage when native ObjC exceptions are enabled. :-) >> >> Hopefully that fixes it ... Michael, any chances you could try it out with >> gnustep-make from trunk to see if it's fixed now ? :-) > > That might be difficult since my GNUstep installation is managed by > the ports system, which tracks releases rather than the trunk. Is > there a way to get two versions of GNUstep to coexist peacefully on > the same system? Yes. I do it all the time. It needs a bit of manual stuff, but here is how you do it: 1. check out GNUstep core in some place you like svn co http://svn.gna.org/svn/gnustep/modules/core 2. make sure your GNUstep environment is clean; if you have another GNUstep environment, clean it up by using . /usr/GNUstep/System/Library/Makefiles/GNUstep-reset.sh (only works with sh). You should have no GNUSTEP_* variables in your environment. 3. configure make telling it to install completely in some directory you like, for example /home/nicola/my-own-gnustep (so you don't need to be root to install your hacked gnustep and you have no chance of overwriting something in your system installation!) cd core/make ./configure --prefix=/home/nicola/my-own-gnustep --with-config-file=/home/nicola/my-own-gnustep/GNUstep.conf 4. install gnustep-make make install 5. to use the newly installed gnustep-make instead of the real one, make sure to: * clean up your environment as explained above . /usr/GNUstep/System/Library/Makefiles/GNUstep.sh * set the variable GNUSTEP_CONFIG_FILE to point to the GNUstep config file of your alternative GNUstep environment: export GNUSTEP_CONFIG_FILE=/home/nicola/my-own-gnustep/GNUstep.conf * run GNUstep.sh . /home/nicola/my-own-gnustep/System/Library/Makefiles/GNUstep.sh Hope that helps :-) Thanks ___ 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
>> That's brilliant ... I added --shared-libgcc (on all platforms) to the >> linking stage when native ObjC exceptions are enabled. :-) >> >> Hopefully that fixes it ... Michael, any chances you could try it out with >> gnustep-make from trunk to see if it's fixed now ? :-) > > That might be difficult since my GNUstep installation is managed by > the ports system, which tracks releases rather than the trunk. Is > there a way to get two versions of GNUstep to coexist peacefully on > the same system? Yes. I do it all the time. It needs a bit of manual stuff, but here is how you do it: 1. check out GNUstep core in some place you like svn co http://svn.gna.org/svn/gnustep/modules/core 2. make sure your GNUstep environment is clean; if you have another GNUstep environment, clean it up by using . /usr/GNUstep/System/Library/Makefiles/GNUstep-reset.sh (only works with sh). You should have no GNUSTEP_* variables in your environment. 3. configure make telling it to install completely in some directory you like, for example /home/nicola/my-own-gnustep (so you don't need to be root to install your hacked gnustep and you have no chance of overwriting something in your system installation!) cd core/make ./configure --prefix=/home/nicola/my-own-gnustep --with-config-file=/home/nicola/my-own-gnustep/GNUstep.conf 4. install gnustep-make make install 5. to use the newly installed gnustep-make instead of the real one, make sure to: * clean up your environment as explained above . /usr/GNUstep/System/Library/Makefiles/GNUstep.sh * set the variable GNUSTEP_CONFIG_FILE to point to the GNUstep config file of your alternative GNUstep environment: export GNUSTEP_CONFIG_FILE=/home/nicola/my-own-gnustep/GNUstep.conf * run GNUstep.sh . /home/nicola/my-own-gnustep/System/Library/Makefiles/GNUstep.sh Hope that helps :-) Thanks ___ 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: Crash with new-style exceptions on FreeBSD amd64
Thanks to everybody for your help. On 3/17/07, Nicola Pero <[EMAIL PROTECTED]> wrote: That's brilliant ... I added --shared-libgcc (on all platforms) to the linking stage when native ObjC exceptions are enabled. :-) Hopefully that fixes it ... Michael, any chances you could try it out with gnustep-make from trunk to see if it's fixed now ? :-) That might be difficult since my GNUstep installation is managed by the ports system, which tracks releases rather than the trunk. Is there a way to get two versions of GNUstep to coexist peacefully on the same system? 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. -Michael ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
