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