Re: no stacktrace available

[Bart Locanthi <bart at sabl dot com>]

wups, heh, my bad..

i'd forgotten about this, but one of the clever things i do in my 
largish application was to paw through stack trace output at high 
logging levels to get the procedure:line-no of the calling entity.

which is highly dependent on the output format of stack traces. i 
remember doing something 18 months ago to avoid this when i was last 
trying to port to gcj/netbsd.

so anyway, i reduced the logging level and the app works fine. woo hoo!!

i haven't looked at what log4j does here, but i imagine the rhug folk 
had to hack it in a similar way for it to work under gcj.

Michael Koch wrote:

> Am Dienstag, 14. Dezember 2004 08:10 schrieb Bart Locanthi:
>  
>
> > % gcj -v
> > Reading specs from
> > /usr/pkg/gcc3/lib/gcc-lib/i386--netbsdelf2.0/3.3.4/specs Reading
> > specs from
> > /usr/pkg/gcc3/lib/gcc-lib/i386--netbsdelf2.0/3.3.4/../../../libgcj.
> > spec rename spec lib to liborig
> > Configured with: ./configure --prefix=/usr/pkg/gcc3
> > --host=i386--netbsdelf2.0 --enable-shared --enable-languages=java
> > --with-system-zlib
> > Thread model: posix
> > gcc version 3.3.4
> >    
>
> Hmm, NetBSD 2.0 uses ELF. Thats good. I wonder if it uses DWARF-2 
> too ?
>
>  
>
> > regarding building a new one, i'm not sure how magic the pkgsrc
> > scripting is. i'll see what i can find out.
> >
> > if i can use the existing toolchain and just rebuild gcc's
> > c/c++/java, it will be a lot more possible.
> >    
>
> I meant only GCC and not the whole toolchain.
>
>
> Michael
>