Date: Fri, 14 Mar 2008 09:11:33 -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: <47DA7985.3040706@intricatesoftware.com> In-Reply-To: <Pine.GSO.4.64.0803132336140.5829@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> <47D5FAEF.3080900@intricatesoftware.com> <Pine.GSO.4.64.0803132336140.5829@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: > >> Daniel Eischen wrote: >> >>> On Mon, 10 Mar 2008, Kurt Miller wrote: >>> >>>> 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? > > I was able to get jdk16 built on 7.0. Previously (unsuccessfully), > I was trying to use jdk-1.5.0.11p5,1 to build jdk16. When that > didn't work, I installed jdk-1.5.0.13p7_4,1 from a package that > I had built on another box. So using jdk-1.5.0.13p7_4,1, I was > able to build jdk-1.6.0.3p4. I also used the same package > (jdk-1.5.0.13p7_4,1) to update jdk15 to the latest patchset > (jdk-1.5.0.14p8,1). So now the latest patchset of both jdk15 > and jdk16 have been built using jdk-1.5.0.13p7_4,1. I have > not tried to rebuild either jdk15 or jdk16 using either of > the up-to-date jdks. > > BTW, this was all done manually (cd /usr/ports/java/jdk1X; > make; make install). portupgrade wanted to install compat6x > and diablo for no apparent reason, when there was already > a perfectly good native jdk installed. Ok so you and others can build the jdks fine on 7.0R. I guess I'm out of ideas as to why Scott and Nicolas's systems don't record the dependency on libthr.so. > BTW2, the build of jdk16 was a lot faster than that of jdk15, > which surprised me. In 1.6 the debug portion of the build can be optionally turned off using SKIP_FASTDEBUG_BUILD="true" which is the default. In 1.5 the hotspot debug binaries are always built (although only installed if the port DEBUG option is on). -Kurt
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47DA7985.3040706>