New build, gobjcopy failure, any clues?

[Volker Simonis]

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/gnu-binutils at 2.19-0.175.0.0.0.2.537 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 <david.r.chase at oracle.com>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 <david.holmes at oracle.com> 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)
> >>
> >>
>
>