I already fixed and integrated this bug: 6567018: Hotspot build fails
with gcc4
so you should see it in the next push.
Nikolay.
Peter B. Kessler wrote:
Can you tell where the reference to ParScanClosure::do_oop_work is
coming from? That method is declared in
hotspot/share/vm/memory/genOopClosures.hpp
(hmm, but it's not declared "inline"), and is then defined inline
in
hotspot/share/vm/memory/genOopClosures.inline.hpp
Maybe we are missing an entry in the includeDB's to tell someone
that they depend on genOopClosures.inline.hpp?
... peter
Petteri Räty wrote:
Linking vm...
/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/../../../../i686-pc-linux-gnu/bin/ld:
warning: creating a DT_TEXTREL in object.
{ \
echo Linking launcher...; \
\
gcc -m32 -march=i586 -Xlinker -O1 -m32 -march=i586
-export-dynamic -L `pwd` -o gamma launcher.o -ljvm -lm -ldl
-lpthread; \
\
}
Linking launcher...
/home/betelgeuse/btdown/openjdk/control/build/linux-i586/hotspot/outputdir/linux_i486_compiler2/product/libjvm.so:
undefined reference to `ParScanClosure::do_oop_work(oopDesc**, bool,
bool)'
collect2: ld returned 1 exit status
My gcc version is:
[EMAIL PROTECTED] ~/btdown/openjdk/control/make $ gcc --version
gcc (GCC) 4.1.2 (Gentoo 4.1.2)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There
is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
It doesn't make a difference whether I use the huge patch pile we have
or not.
Regards,
Petteri
