discuss-gnustep
[Top][All Lists]
Advanced

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

Re: problem with gnustep on OpenBSD sparc64


From: Sebastian Reitenbach
Subject: Re: problem with gnustep on OpenBSD sparc64
Date: Tue, 05 Jul 2011 13:30:15 +0200
User-agent: SOGoMail 1.3.7

Hi,

attached output from gnustep-tests on gnustep-base.

Sebastian

 
On Tuesday, July 5, 2011 12:46 CEST, "Sebastian Reitenbach" 
<sebastia@l00-bugdead-prods.de> wrote: 
 
> 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: gstests-base.tar.gz
Description: GNU Zip compressed data


reply via email to

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