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 <[email protected]>: >> 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 ? >>
