On 2015-12-14 02:58, David Holmes wrote:
On 13/12/2015 7:53 PM, Erik Joelsson wrote:
On Macosx, the utility to use is dsymutil. On Windows, debugsymbols are
controlled with flags to the compiler and linker. On Linux and Solaris,
we use objcopy. Each platform is different.
Okay so for some reason (that I probably should know) we give objcopy
special handling in ensuring it exists. Make sense then to only do it
on the expected platforms.
For consistency, we should probably check that dsymutil exists as well,
if creating external debug symbols on macosx. My guess is that not
having objcopy have been a historical problem (at least has having a
non-broken objcopy on Solaris been a problem), but not so for dsymutil.
As I've said before, we don't really have a coherent story for debug
symbols. :-( I think Yasumasa's change was good in that it introduced a
nice interface towards the user, and it solved the problems, but I'd
really like to redesign the debug symbol handling "under the hood".
/Magnus
Thanks,
David
/Erik
On 2015-12-12 13:48, Yasumasa Suenaga wrote:
I agree to David.
If your environment does not have objcopy, you should set
--with-native-debug-symbols
to internal or none.
Thanks,
Yasumasa
On 2015/12/12 21:40, David Holmes wrote:
On 12/12/2015 1:52 AM, Erik Joelsson wrote:
JDK-8036003 broke configure on Macosx:
checking what type of native debug symbols to use... zipped
configure: error: Unable to find objcopy, cannot enable native debug
symbols
We can only fail for missing objcopy on platforms that actually
use it.
Silly question but how do we do the zipped debuginfo on platforms
without an objcopy ??
Thanks,
David
Bug: https://bugs.openjdk.java.net/browse/JDK-8145206
Webrev: http://cr.openjdk.java.net/~erikj/8145206/webrev.01/
/Erik
