Hi David, I found a Solaris 11 box today and it seems that this is really a problem of binutils 2.19 on Solaris 11.
Initially there was no gobjcopy on my Solaris machine at all so I did the following: - downloaded gnu-binutils.p5i from http://pkg.oracle.com/solaris/release/en/index.shtml - installed developer/[email protected] by doing '/usr/lib/pm-launch packagemanager gnu-binutils.p5i' Now I had /usr/ccs/bin/gobjcopy (version 2.19) but it miserably failed even on an libjvm.so from a jdk7u build that was done on Solaris 10 (and worked there): gobjcopy --only-keep-debug /usr/work/openjdk/nb/sun_64/nightly/output-jdk7u/j2sdk-image/jre/lib/sparcv9/server/libjvm.so /tmp/libjvm.debuginfo gobjcopy:/usr/work/openjdk/nb/sun_64/nightly/output-jdk7u/j2sdk-image/jre/lib/sparcv9/server/libjvm.so: File format not recognized You could try to compile binutils yourself and/or open a bug report against the binutils 2.19 package on Solaris 11 Regards, Volker On Wed, Mar 27, 2013 at 2:26 PM, David Chase <[email protected]>wrote: > It's not "my" version, it's whatever someone else installed on one of the > ghostboxes (terminus). > > I was perhaps misled into using a 5.11 box by > (1) seeing it listed as a box for our use; > (2) my success building with Solaris 11 on Intel; > (3) the fact that the exact OS version is not mentioned in the summary > output of configure (so, probably not that important); > (4) it does not whine about my choice (for example, if you use the latest > Solaris compilers, it complains bitterly throughout the build, which is > nonetheless successful). > > gobjcopy: supported targets: elf32-sparc elf64-sparc a.out-sunos-big > elf64-little elf64-big elf32-little elf32-big srec symbolsrec tekhex binary > ihex > > Isn't this information redundant with the output of "gobjcopy -info" > (which appears earlier in this discussion)? > > It would have saved me a little time if you had mentioned that the output > you desire > was the result of typing "gobjcopy -v", because this is not implied by > TFM, which I did in fact R > yesterday. I've wasted quite a bit of time trying to do a detailed test > of a code generation change > and have been thwarted at every step by flaky tests, underdocumented test > harnesses, and > inexplicably buggy builds. It took some additional poking to discover the > undocumented > behavior of the "-v" flag: > > -v > --verbose > Verbose output: list all object files modified. In the > case of archives, objcopy -V [sic] lists all members of the > archive. > > David > > On 2013-03-26, at 10:40 PM, David Holmes <[email protected]> wrote: > > > On 27/03/2013 2:33 AM, David Chase wrote: > >> I think I'm doing a vanilla new-build, but obviously I'm not, because > it fails. > >> What should I be looking for? > > > > Official build platform is Solaris 10 and we use gobjcopy version "GNU > objcopy 2.15". > > > > Your 2.19 version may not have the right support built-in. What > supported platforms does it report? > > > > 2.15 reports: > > > > gobjcopy: supported targets: elf32-sparc elf64-sparc a.out-sunos-big > elf64-little elf64-big elf32-little elf32-big srec symbolsrec tekhex binary > ihex > > > > David > > > >> * OpenJDK target: OS: solaris, CPU architecture: sparc, address length: > 64 > >> > >> Tools summary: > >> * Boot JDK: java version "1.8.0-ea" Java(TM) SE Runtime > Environment (build 1.8.0-ea-b82) Java HotSpot(TM) Server VM (build > 25.0-b23, mixed mode) (at /export/drchase/jdk8) > >> * C Compiler: Sun Studio version 5.10 (at > /java/devtools/sparc/SUNWspro/SS12u1/prod/bin/cc) > >> * C++ Compiler: Sun Studio version 5.10 (at > /java/devtools/sparc/SUNWspro/SS12u1/prod/bin/CC) > >> > >> > >
