[Prev][Next][Index][Thread]
Re: oskit-990722 and kaffe-1.0.5
I just wanted to update the public OSKit list about this problem.
After a good bit of mail and some more testing here at Utah, we've got
a fix. The linking problem Hannu describes (some of his message is
attached below) only affects building 'kaffeh' in the Kaffe
distrubution. Since you don't need a cross-compiled version of
kaffeh, a simple "fix" is to 'touch kaffe/kaffeh/kaffeh' and
re-compile. :)
This is reproducible on Redhat 5.2 systems, but not on our FreeBSD 3.0
development boxes. The root of the problem is probably the order of
libraries listed in the config/i386/oskit/ld-oskit.sh script. When
linking 'kaffeh', pthread symbols are pulled in later than when
building 'kaffe' itself. We'll publish a fix to the link line when we
find the real cause of the problem. In the meantime, 'touch
kaffe/kaffeh/kaffeh' seems like a pretty simple fix... :)
Please let us know if you have any other problems with Kaffe/OSKit.
-Pat
----- ----- ---- --- --- -- - - - - -
Pat Tullmann tullmann@cs.utah.edu
Not many people realize just how well known I am -- Anonymous
Hannu Mallat wrote:
>
> On Wed, 20 Oct 1999, Godmar Back wrote:
>
> > First, make sure you don't build the OSKit in the source directory. I
> > believe that this necessity is the only thing Pat didn't fix when he
> > upgraded to 1.0b5. (I think)
>
> Ok, I corrected that; interestingly enough, the linking errors I saw
> before disappeard -- unfortunately, some new ones appeared. Below are
> the ugly details (beware of long lines); gcc version 2.7.2.3 and binutils
> version 2.9.1 were used, on a Redhat Linux x86 box, with kernel 2.0.34.
>
> By the way, what I'm attempting to do is to trace the delays imposed
> by different software layers when using oskit and kaffe to communicate
> with the outside world using UDP-based protocols (eventually multimedia
> streaming). Basically I'd just allocate a chunk of memory as a buffer and
> stuff timestamped events like network device interrupt received, packet
> read at the Linux driver, etc. to it, push different loads to the machine
> and record the statistics into a file for analysis after a run. Anyone
> already done something like this? (would save my work :)
>
> [ ... making all has progressed finely until here ... ]
> Making all in kaffe
> make[1]: Entering directory `/root/go/kaffe-1.0.5-oskit/kaffe'
> Making all in kaffeh
> make[2]: Entering directory `/root/go/kaffe-1.0.5-oskit/kaffe/kaffeh'
> /bin/sh ../../libtool --mode=link /root/go/kaffe-1.0.5-oskit/config/i386/oskit/ld-oskit.sh --oskit=/usr/local/oskit/ -g -O2 -Wall -Wstrict-prototypes -o kaffeh inflate.o jar.o utf8const.o readClass.o constants.o sigs.o support.o main.o -L/usr/local/lib -R/usr/local/lib
> /root/go/kaffe-1.0.5-oskit/config/i386/oskit/ld-oskit.sh --oskit=/usr/local/oskit/ -g -O2 -Wall -Wstrict-prototypes -o kaffeh inflate.o jar.o utf8const.o readClass.o constants.o sigs.o support.o main.o -L/usr/local/lib
> Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.7.2.3/specs
> gcc version 2.7.2.3
> ld -m elf_i386 -static -o kaffeh -L/usr/local/lib -L/usr/local/oskit//lib -L/usr/lib/gcc-lib/i386-redhat-linux/2.7.2.3 -L/usr/i386-redhat-linux/lib -Ttext 100000 /usr/local/oskit//lib/oskit/multiboot.o inflate.o jar.o utf8const.o readClass.o constants.o sigs.o support.o main.o -loskit_startup -loskit_clientos -loskit_threads -loskit_svm -loskit_amm -loskit_bootp -loskit_freebsd_net -loskit_linux_dev -loskit_dev -loskit_netbsd_fs -loskit_kern -loskit_lmm -loskit_diskpart -loskit_memfs -loskit_freebsd_c_r -loskit_fsnamespace_r -loskit_com -loskit_freebsd_m -loskit_freebsd_c_r -loskit_threads /usr/local/oskit//lib/oskit/crtn.o
> /usr/local/oskit//lib/liboskit_threads.a(pthread_init.o): In function `base_irq_softint_handler':
> pthread_init.o(.text+0x19c): multiple definition of `base_irq_softint_handler'
> [ ... many more duplicate symbols deleted ...]
References: