OpenJDK 8 and fastdebug

[Chris Dennis]

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 ?
>>