jdk16 build failure on 7.0R/i386

Daniel Eischen deischen at freebsd.org
Tue Mar 11 02:10:15 UTC 2008


On Mon, 10 Mar 2008, Kurt Miller wrote:

> On Monday 10 March 2008 7:18:03 pm Scott Mitchell wrote:
>> On Mon, Mar 10, 2008 at 08:32:36AM -0500, Kurt Miller wrote:
>>> This look like another case of the jvm not being linked to a thread library.
>>> At least the 'Dynamic libraries:' section of the crash report doesn't list a
>>> thread library. What does ldd show?
>>>
>>> ldd /var/tmp/usr/ports/java/jdk16/work/control/build/bsd-i586/bin/java
>>>
>>> Can you extract the portion of the build log that shows the link command
>>> for the 'java' executable? It should look something like this:
>>
>> Hi Kurt,
>>
>> Here you go - I saved the entire log so just let me know if you need to see
>> any more of it:
>>
>> Rebuilding /var/tmp/usr/ports/java/jdk16/work/control/build/bsd-i586/bin/java because of /var/tmp/usr/ports/java/jdk16/work/control/build/bsd-i586/tmp/java/java/obj/java.o /var/tmp/usr/ports/java/jdk16/work/control/build/bsd-i586/tmp/java/java/obj/java_md.o /var/tmp/usr/ports/java/jdk16/work/control/build/bsd-i586/tmp/java/java/obj/splashscreen_stubs.o
>> /usr/bin/gcc  -o /var/tmp/usr/ports/java/jdk16/work/control/build/bsd-i586/bin/java  -L/var/tmp/usr/ports/java/jdk16/work/control/build/bsd-i586/lib/i386 -Wl,-soname=lib.so  -Wl,--whole-archive /var/tmp/usr/ports/java/jdk16/work/control/build/bsd-i586/tmp/java/jli/obj/static/libjli.a -Wl,--no-whole-archive \
>> 	    /var/tmp/usr/ports/java/jdk16/work/control/build/bsd-i586/tmp/java/java/obj/java.o /var/tmp/usr/ports/java/jdk16/work/control/build/bsd-i586/tmp/java/java/obj/java_md.o /var/tmp/usr/ports/java/jdk16/work/control/build/bsd-i586/tmp/java/java/obj/splashscreen_stubs.o -pthread   -pthread
>> gmake[4]: Leaving directory `/var/tmp/usr/ports/java/jdk16/work/j2se/make/java/main/java'
>>
>
> Hi,
>
> Weird. It seems like gc(1)/ld(1) has changed the way -pthread is handled. In 6.X
> and below it will record a NEEDED entry for libpthread even if the executable
> doesn't reference any pthread symbols. I suspect that in 7.X if the executable
> doesn't reference any pthread symbols it wont record the NEEDED entry.

No, for binaries it works the same way on 7.x as 6.x.

$ gcc -o k k.c -pthread
$ ldd k
k:
         libthr.so.3 => /lib/libthr.so.3 (0x2807c000)
         libc.so.7 => /lib/libc.so.7 (0x2808f000)

I believe that -pthread does now act differently in 7.0+ when used
to build shared libraries.  Prior to 7.0, using -pthread to build
shared libraries would not record a dependency on libpthread,
whereas in 7.0+ it will record a dependency.

Other than that, the only change in 7.0 is that libthr is now the
default instead of libkse (nee libpthread).

-- 
DE


More information about the freebsd-java mailing list