no stacktrace available

Tue Dec 14 13:33:00 GMT 2004

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
>>