discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

problem with gnustep on OpenBSD sparc64


From: Sebastian Reitenbach
Subject: problem with gnustep on OpenBSD sparc64
Date: Tue, 05 Jul 2011 12:46:32 +0200
User-agent: SOGoMail 1.3.7

Hi,

since I had the question regarding the thread without answer: "problem with 
libobc1 on OpenBSD amd64 cannot find tconfig.h when compiling", I thought about 
trying it on sparc64. There I ended up with the same problem, no tconfig.h in 
config/sparc64/generic...

I copied the tconfig.h file from sparc, which is essentially the same as in the 
i386 into config/sparc64/generic, and it was compiling. However, I found that 
more or less all applications I tried are aborting with a core dump. I then 
tried to change the BITS_PER_WORD to 64, and reinstalled the old libobjc, but 
the abort stayed as is. I then uninstalled libobjc1, and just linked against 
the system libobjc from gcc-4.2.1.
Both with gnustep libobjc1 and gcc libobjc works well on i386. and also with 
the gnustep libobjc1, everything works well on sparc 32 bits.

in contrast to mips64, libffi seems to be fine on sparc64:

===>  Regression check for libffi-3.0.9
Making check in include
Making check in testsuite
make  check-DEJAGNU
Making a new site.exp file...
srcdir=`CDPATH="${ZSH_VERSION+.}:" && cd . && pwd`; export srcdir;  EXPECT=`if 
[ -f ../../expect/expect ] ; then  echo ../../expect/expect ;  else echo expect 
; fi`; export EXPECT;  runtest=`if [ -f ../../dejagnu/runtest ] ; then  echo 
../../dejagnu/runtest ;  else echo runtest; fi`;  if /bin/sh -c "$runtest 
--version" > /dev/null 2>&1; then  exit_status=0; l='libffi'; for tool in $l; 
do  if $runtest  --tool $tool --srcdir $srcdir ;  then :; else exit_status=1; 
fi;  done;  else echo "WARNING: could not find \`runtest'" 1>&2; :; fi;  exit 
$exit_status
WARNING: Couldn't find the global config file.
WARNING: Couldn't find tool init file
Test Run By sebastia on Tue Jul  5 11:56:14 2011
Native configuration is sparc64-unknown-openbsd4.9

                === libffi tests ===

Schedule of variations:
    unix

Running target unix
Using /usr/local/share/dejagnu/baseboards/unix.exp as board description file 
for target.
Using /usr/local/share/dejagnu/config/unix.exp as generic interface file for 
target.
Using /home/ports/pobj/libffi-3.0.9/libffi-3.0.9/testsuite/config/default.exp 
as tool-and-target-specific interface file.
Running 
/home/ports/pobj/libffi-3.0.9/libffi-3.0.9/testsuite/libffi.call/call.exp ...
Running 
/home/ports/pobj/libffi-3.0.9/libffi-3.0.9/testsuite/libffi.special/special.exp 
...

                === libffi Summary ===

# of expected passes            1624
# of expected failures          10
# of unsupported tests          15
Making check in man


libffi-3.0.9, gnustep-make-2.6.1, gnustep-base-1.22.1, gnustep-gui-0.20.0, 
gnustep-back-0.20.1.

running for example AddressManager in gdb, leads to the attached backtrace. 
There I see the __smash_stack_handler is thrown:
(gdb) bt
#0  __stack_smash_handler (func=0x20be18858 "-[GSTimeZone initWithName:data:]", 
damaged=201031256) at /usr/src/lib/libc/sys/stack_protector.c:91
#1  0x000000020bbab57c in -[GSTimeZone initWithName:data:] (self=0x208f3f110, 
_cmd=0xe, name=0x208f3dd50, data=0xfffffffffffe2310) at NSTimeZone.m:3110
#2  0x000000020bba7930 in -[GSPlaceholderTimeZone initWithName:data:] 
(self=0x20a663010, _cmd=0x20bfb7f18, name=0x208f3dd50, data=0x208f3c250) at 
NSTimeZone.m:556
#3  0x000000020bba5cc4 in -[NSTimeZone initWithName:] (self=Variable "self" is 
not available.
...

more information in the attached backtrace and gdb output.


but I actually cannot see why? Does anybody has a clue?

gnustep-tests on gnustep-base is running right now.
BTW: does gnustep-tests has a parameter, where I can prevent it from cleaning 
up the binaries after the test? Its because I'd to have them around, when there 
are tests leaving a core file, so that I can easily examine the core file...


Sebastian

Attachment: gdb_output.txt
Description: Text document


reply via email to

[Prev in Thread] Current Thread [Next in Thread]