My latest error
kurt at intricatesoftware.com
Fri May 15 12:57:42 UTC 2015
On Thu, 2015-05-14 at 16:59 -0400, Kurt Miller wrote:
> The debug symbol logic works in several places prior to it failing. When
> it does fail it fails with:
> /usr/bin/objcopy: libinstrument.debuginfo: Invalid operation
> I can manually reproduce the 'Invalid operation' error if I attempt to
> do --add-gnu-debuglink on a binary that already has gnu-debuglink set.
> When I read the build logs I don't see two calls to set gnu-debuglink,
> however it still fails with 'Invalid operation'. Very strange. Checking
> with readelf -S I can see that libinstrument.so does have gnu-debuglink
> set after the build fails.
Hexdump of libinstrument.so at the address for gnu-debuglink shows
it imported the debuglink from libjli_static:
00076870 00 00 6c 69 62 6a 6c 69 5f 73 74 61 74 69 63 2e |..libjli_static.|
00076880 64 65 62 75 67 69 6e 66 6f 00 00 9e 91 f0 00 2e |debuginfo.......|
So it is failing because it is already set via the libjli_static.a that was
/usr/bin/gcc -shared <snip> -Xlinker --whole-archive /home/truk/jdk/jdk8/build/bsd-x86_64-normal-server-release/jdk/objs/libjli_static.a -Xlinker --no-whole-archive <snip>
The use of a static libjli.a is somewhat historical. I recall there was
some problem with it back in 1.5 or 1.6 and using a static version was
a work-around. Perhaps it was back when OpenBSD and FreeBSD didn't have
$ORIGIN support in our runtime linkers.
I see two ways to fix this. Retest building with a dynamic libjli or
modify the debuglink make rules to not put debuglink on static libs
(may be a good idea either way).
More information about the bsd-port-dev