OpenJDK 8 and fastdebug
Chris Dennis
cdennis at terracottatech.com
Sun Apr 22 05:58:06 PDT 2012
No I haven't signed an OCA - although I'm happy to do so (or someone with an OCA can independently create the same changeset - it's not exactly complex).
WIth regards to binutils - I think you're misunderstanding things here - hsdis is statically linked against a privately compiled copy of the binutils source that is built as part of the hsdis build process - it's not dynamically linked. It's this private copy of the source that must be patched - have a look at the build instructions in the README file for hsdis for more details
Chris
On Apr 22, 2012, at 5:11 AM, Henri Gomez wrote:
> Thanks for this.
>
> I hope this patch (Makefile) will be applied soon to jdk8 (did you
> have an OCA ?)
>
> BTW, for binutils, installing it could raise problems with MacPorts :
>
> http://stackoverflow.com/questions/9260504/macports-installing-binutils.
>
> May be binutils should be installed to a dedicated location and PATH
> adjustment should be done before make
>
> 2012/4/22 Chris Dennis <cdennis at terracottatech.com>:
>> That's weird the attachments are on the email in my sent mail folder - looks like the maillist server may have stripped them - are they attached to the copy you directly received? If someone with commit rights on the relevant OpenJDK repositories wishes to commit the Makefile changes then that's cool with me - of course it still won't build without manually patching the associated binutils sources anyway so how much value there is in that at the moment I don't know.
>>
>> Patches inline below to avoid any more weirdness with attachments.
>>
>> Chris
>>
>> diff -r bca9e76ea254 src/share/tools/hsdis/Makefile
>> --- a/src/share/tools/hsdis/Makefile Tue Mar 20 10:17:41 2012 -0700
>> +++ b/src/share/tools/hsdis/Makefile Sat Apr 21 21:12:29 2012 -0400
>> @@ -84,6 +84,25 @@
>> DLDFLAGS += -shared
>> LDFLAGS += -ldl
>> OUTFLAGS += -o $@
>> +else
>> +## OS = Darwin ##
>> +ifeq ($(OS),Darwin)
>> +ifdef LP64
>> +ARCH = amd64
>> +else
>> +ARCH = i386
>> +endif
>> +CFLAGS/i386 += -m32
>> +CFLAGS/amd64 += -m64
>> +CFLAGS += $(CFLAGS/$(ARCH))
>> +CFLAGS += -fPIC
>> +OS = darwin
>> +LIB_EXT = .dylib
>> +CC = gcc
>> +CFLAGS += -O
>> +DLDFLAGS += -shared -lz
>> +LDFLAGS += -ldl
>> +OUTFLAGS += -o $@
>> ## OS = Windows ##
>> else # !SunOS, !Linux => Windows
>> OS = windows
>> @@ -95,6 +114,7 @@
>> /export:decode_instruction
>> OUTFLAGS += /link /out:$@
>> LIB_EXT = .dll
>> +endif # Darwin
>> endif # Linux
>> endif # SunOS
>>
>> @@ -118,7 +138,7 @@
>> BINUTILSDIR = $(shell cd $(BINUTILS);pwd)
>> endif
>>
>> -CPPFLAGS += -I$(BINUTILSDIR)/include -I$(BINUTILS)/bfd -I$(TARGET_DIR)/bfd
>> +CPPFLAGS += -I$(BINUTILSDIR)/include -I$(BINUTILSDIR)/bfd -I$(TARGET_DIR)/bfd
>> CPPFLAGS += -DLIBARCH_$(LIBARCH) -DLIBARCH=\"$(LIBARCH)\" -DLIB_EXT=\"$(LIB_EXT)\"
>>
>> TARGET_DIR = build/$(OS)-$(JDKARCH)
>>
>> diff -ru binutils-2.22/libiberty/xmalloc.c binutils/libiberty/xmalloc.c
>> --- binutils-2.22/libiberty/xmalloc.c 2005-05-24 17:01:33.000000000 -0400
>> +++ binutils/libiberty/xmalloc.c 2012-04-21 18:22:02.000000000 -0400
>> @@ -93,6 +93,11 @@
>> # endif /* HAVE_STDLIB_H ... */
>> #endif /* VMS */
>>
>> +#ifdef __APPLE__
>> +#include <crt_externs.h>
>> +#define environ (*_NSGetEnviron())
>> +#endif /* __APPLE__ */
>> +
>> /* The program name if set. */
>> static const char *name = "";
>>
>> On Apr 21, 2012, at 7:26 PM, Henri Gomez wrote:
>>
>>>> If my understanding is correct (and I may well be wrong!) contributing the patch back in to binutils is most likely a no go - binutils itself builds fine on Mac OS because all the targets are executables, but hsdis is a dynamic library:
>>>
>>> I was thinking contributing patch to OpenJDK (ie: makefile) not to binutils :)
>>>
>>>> Quote from 'man environ':
>>>> Shared libraries and bundles don't have direct access to environ, which is only available to the loader
>>>> ld(1) when a complete program is being linked. The environment routines can still be used, but if
>>>> direct access to environ is needed, the _NSGetEnviron() routine, defined in <crt_externs.h>, can be
>>>> used to retrieve the address of environ at runtime.
>>>>
>>>> Here are the changes I made to solve this in patch form in any case:
>>>
>>> Which one ?
>>
More information about the jdk8-dev
mailing list