NSBitmap+Icns.m on Sparc
Riccardo is having trouble with the new icns loading code on sparc architecture. I think this is caused by pointers into the data structure not being properly aligned for this processor, but as I am no expert in this area it would be great if somebody could have a look before I start experimenting around. The problem he gets is: Program received signal SIGBUS, Bus error. 0x0fec17e4 in icns_import_family_data (size=33658, bytes=0x9a6e000 icns, iconFamily=0xf7fca660) at NSBitmapImageRep+ICNS.m:270 270 while ((data end) element-elementSize) (gdb) p data $1 = (icns_byte_t *) 0xdce6372 t8mk (gdb) p end $2 = (icns_byte_t *) 0xdcea37a (gdb) p element-elementSize $3 = 16392 As it works fine for him when using the libicns library I would not rank it as a very urgent problem. Still it is interesting to understand how they are doing it. (OK, we could just have a look at the code, now that we know it is LGPL) Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: ./test-gnustep: i686-pc-linux-gnu-logs.tar.gz: No such file or directory
It is sort of dumb script. First it removes any old logs that might be there, then if (and only if) there is a new log, it moves it to the proper location. If ftp complains that there is no log file, that means that nothing bad happenned during the compile. On Nov 4, 2008, at 4:37 PM, T.J. Yang wrote: Trying to add my fedora 9 box to be a gnustep test box. But why the script delete the i686-pc-linux-gnu-logs.tar.gz and then complain the file is not found ? tj snip openapp MyApplication.app + gsexitstatus=0 + echo '--- Archive Results ---' --- Archive Results --- + rm -f i686-pc-linux-gnu-results.txt + rm -f i686-pc-linux-gnu-logs.tar.gz ++ date + GSDATE='Tue Nov 4 17:08:45 CST 2008' + gs_success=no + '[' 0 '!=' 0 ']' + echo 'Success Compile i686-pc-linux-gnu Tue Nov 4 17:08:45 CST 2008' + gs_success=yes + echo '--- Upload Results ---' --- Upload Results --- + ftp -n ftp.gnustep.org local: i686-pc-linux-gnu-logs.tar.gz: No such file or directory + DIRS='make base gui back' + '[' no = yes -a -d /home/tjyang/gnustep-ibm ']' [EMAIL PROTECTED] scripts]$ [ ___ 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: NSBitmap+Icns.m on Sparc
Am Mittwoch, den 05.11.2008, 08:45 +0100 schrieb Fred Kiefer:
Riccardo is having trouble with the new icns loading code on sparc
architecture. I think this is caused by pointers into the data structure
not being properly aligned for this processor, but as I am no expert in
this area it would be great if somebody could have a look before I start
experimenting around.
The problem he gets is:
Program received signal SIGBUS, Bus error.
0x0fec17e4 in icns_import_family_data (size=33658, bytes=0x9a6e000 icns,
iconFamily=0xf7fca660) at NSBitmapImageRep+ICNS.m:270
270 while ((data end) element-elementSize)
(gdb) p data
$1 = (icns_byte_t *) 0xdce6372 t8mk
(gdb) p end
$2 = (icns_byte_t *) 0xdcea37a
(gdb) p element-elementSize
$3 = 16392
Given the definitions of the types:
typedef unsigned char icns_byte_t;
typedef unsigned long icns_size_t;
typedef struct _icns_type_t {
char c[4];
} icns_type_t;
typedef struct _icns_element_t {
icns_type_t elementType;
icns_size_t elementSize;
} icns_element_t;
typedef struct _icns_family_t {
icns_type_t resourceType;
icns_size_t resourceSize;
icns_element_t elements[1];
} icns_family_t;
I would assume the straight forward fix (if indeed it is an alignment
issue is to add padding to icns_element_t to the sizeof(long) boundry
which is 8 byte on most 64 bit archs. I.e.
typedef struct _icns_element_t {
icns_type_t elementType;
char padding[4];
icns_size_t elementSize;
} icns_element_t;
But yeah... maybe we should just look at their code...
Cheers,
David
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
