Tue 17 Feb 2009 07:48:23 AM UTC, comment #16:
I close this bug report as the basic issue was fixed by changing to ffi. It never was a gui bug in the first place and if we want to change something in the configuration of base, this should be discussed in a separate report.
|
Tue 10 Feb 2009 09:57:54 PM UTC, comment #15:
Well one option would simply be to modify configure.ac to set ffcall to be known not to work on your hardware/os, so that people will have to use libffi.
That means setting do_broken_ffcall=yes etc, as already done for sparc64 solaris.
However, if ffcall works on older versions of the operating system, it would need to be disabled only for the specific version where it doesn't work.
|
Tue 10 Feb 2009 09:10:02 PM UTC, comment #14:
This appears to be the issue. The images are present when using libffi instead of ffcall. I'm wondering, since ffcall is deprecated, if it's even worth looking into this problem.
The issue doesn't seem to be present on older systems where libffcall is used and libffi works for newer systems. GC
|
Tue 10 Feb 2009 08:41:52 PM UTC, comment #13:
I am using ffcall and not libffi. Should this make a difference?
|
Tue 10 Feb 2009 02:04:05 PM UTC, comment #12:
okay... one thing I have noticed is that I am using GNUstep's Window decorations. The close and miniaturize icons are missing.
Also on the save panel the disk and other images near the buttons are missing including the return symbol on the "OK" button.
|
Tue 10 Feb 2009 01:56:19 PM UTC, comment #11:
For comparison, my machine where things are working fine is debian unstable (though not updated or a while) with the 2.6.26-1-amd64 kernel.
Since suspicion about proxies falls on the invocation system ...
things are compiled with gcc-4.3.3 (20090119) prerelease, and I'm using libffi-dev-3.0.7-1
I guess this could be an ffcall problem ... the configure script uses libffi if it's available, but will still fall back and use ffcall unless it's on a system where ffcall is known not to work.
|
Tue 10 Feb 2009 01:18:46 PM UTC, comment #10:
I'm not sure what's going on then because all I'm doing is a clean build and starting applications on my debian-etch box and seeing the issue straight away. There are no steps to reproduce it. I will try to do another clean build to see if it's still happening.
GC
|
Tue 10 Feb 2009 01:06:14 PM UTC, comment #9:
OK, I really, really, really need to know how to reproduce this. I dug out my old 64bit debian system, installed and built core+gorm from subversion ... and ran it and can't see anything wrong.
I don't think some of my earlier questions about how to reproduce the problem ever got answered... What application do I need to run, and what images do I need to look at?
What I tried was running gorm and dropping all the items from the pallettes into a new application window ... everything looked normal as far as i could see,
|
Tue 10 Feb 2009 12:31:11 PM UTC, comment #8:
Great news ... if it's a 64bit problem then it's almost certainly not in the code I added to NSImage.m, but rather in the invocation code ... and tracking it down/fixing it is likely to cure other subtle bugs.
|
Mon 09 Feb 2009 11:53:21 PM UTC, comment #7:
Actually I just tested again on my 32 bit system. it's working there, but not on my 64 bit system. It appears that this is a 64 bit issue.
|
Mon 09 Feb 2009 08:57:57 PM UTC, comment #6:
They don't appear. Please see the attached jpg.
|
Mon 09 Feb 2009 05:58:53 PM UTC, comment #5:
PS. what does 'not showing up properly' mean? Does it mean the images don't appear, or does it mean they appear but look wrong in some way (if so, in what way)?
|
Mon 09 Feb 2009 05:57:32 PM UTC, comment #4:
The screenshot unfortunately doesn't tell me anything as I don't know what the app is or what it should look like normally.
I think it would help to know ..
what images the problem occurs with (even just one specific example)
what application these images are in ... in order to reproduce the problem
whether the images are loaded from Gorm/NIB or not
does the problem occur all the time, or is there a particular sequence of operations to reproduce it.
I don't normally use the art backend, so I'd like to first see if the problem can be reproduced on my system, and if not I can try building with art and trying that.
|
Mon 09 Feb 2009 05:04:55 PM UTC, comment #3:
This is happening in all applications I start and I'm using the art backend.
|
Mon 09 Feb 2009 05:03:10 PM UTC, comment #2:
Sorry, it's not an application bug. THis is definitely a problem with gui.
It's happening on both x86_64 and x86 for all applications I'm starting.
This issue appears to be related to the recent changes in NSImage.
|
Mon 09 Feb 2009 04:42:53 PM UTC, comment #1:
Could you please be a bit more specific. On which platform is this happening and which backend are you using?
Does this problem go away when you disable the new image proxy code?
Why do you think it is an application bug, if so which application?
If you just did add this bug report as a reminder for yourself and don't want to provide more information, could you please set yourself as the assignee. That way I and others could ignore this bug report.
|
Mon 09 Feb 2009 04:16:52 PM UTC, original submission:
Please see the attached image.
|