Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 10 Mar 2008 23:22:23 -0400
From:      Kurt Miller <kurt@intricatesoftware.com>
To:        Daniel Eischen <deischen@freebsd.org>
Cc:        Scott Mitchell <scott+lists.freebsd@fishballoon.org>, freebsd-java@freebsd.org
Subject:   Re: jdk16 build failure on 7.0R/i386
Message-ID:  <47D5FAEF.3080900@intricatesoftware.com>
In-Reply-To: <Pine.GSO.4.64.0803102142200.18214@sea.ntplx.net>
References:  <20080309220029.GB93340@llama.fishballoon.org> <200803100932.37017.lists@intricatesoftware.com> <20080310231803.GC22200@tuatara.fishballoon.org> <200803102130.02371.kurt@intricatesoftware.com> <Pine.GSO.4.64.0803102142200.18214@sea.ntplx.net>

next in thread | previous in thread | raw e-mail | index | archive | help
Daniel Eischen wrote:
> 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 gcc(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).
> 

Hi Daniel,

Hmm, well I'm perplexed then. I can't see why
work/control/build/bsd-i586/bin/java isn't recording the NEEDED on
libthr.so. Perhaps the -Wl,-soname=lib.so argument or the double
-pthread is the culprit. Can you experiment on 7.0 to see if they are
involved at all?

-Kurt



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47D5FAEF.3080900>