[rfc][icedtea7] patch for macosx build

[Andrew Hughes]

----- Original Message -----
> On 08/28/2013 09:27 PM, Andrew Hughes wrote:
> > ----- Original Message -----
> >> Hi,
> >>
> >> I've built icedtea7 head (hg:0a8108854365) for macosx x86_64 and want to
> >> publish patch for possible upstreaming.
> >>
> >> I've used the same sources, as in windows build - obtained from
> >> "icedtea7/openjdk" directory by running:
> >>
> >>       ./configure \
> >>       --disable-system-zlib \
> >>       --disable-system-jpeg \
> >>       --disable-system-png \
> >>       --disable-system-gif \
> >>       --disable-system-lcms \
> >>       --disable-compile-against-syscalls \
> >>       --disable-nss
> >>
> >> and "make" on debian wheezy.
> >>
> >> Then built these sources on macosx 10.7.5 with xcode 4.3.2 (gcc 4.2.1)
> >> as a separate openjdk build (without icedtea infrastructure) using
> >> additional environment
> >> variables:
> >>
> >>       export FT2_CFLAGS='-I$(FREETYPE_HEADERS_PATH)
> >> -I$(FREETYPE_HEADERS_PATH)/freetype2'
> >>       export DISABLE_INTREE_EC=true
> >>
> >> Patch was created against icedtea7-forest/jdk (hg:afaedb56b499):
> >>
> >> 2013-08-11  Alex Kasko  <alex.kasko.mail at gmail.com>
> >>
> >> 	*make/java/nio/Makefile:
> >> 	add "syscalls_fp.c" to compilation list in macosx specific section
> >> 	*make/sun/lwawt/FILES_c_macosx.gmk:
> >> 	add "cups_fp.c" to compilation list
> >> 	*make/sun/lwawt/Makefile:
> >> 	add "solaris/native/common/deps" directory to headers search list, and
> >> to vpath (not sure whether vpath is necessary here)
> >>
> >>
> >> --
> >> Regards,
> >> Alex Kasko
> >>
> >
> > Why didn't you just use IcedTea in full?  I can understand the problems on
> > Windows
> > but OS X is UNIX-like.
> I tried to configure IcedTea on mac, but gave up.
> 
> With configure script generated by autotools from macports (automake
> 1.14) I've got:
> 
>      ./configure: line 8675: syntax error near unexpected token `NSS,'
>      ./configure: line 8675: `PKG_CHECK_MODULES(NSS, nss, NSS_FOUND=yes,
> NSS_FOUND=no)'
> 

This means it can't find the definition of the PKG_CHECK_MODULES macro
which is in /usr/share/aclocal/pkg.m4 on GNU/Linux boxes and is part
of pkgconfig.

You shouldn't need to generate configure at all if you use a release
tarball.  What exactly are you building?

> With configure script generated in linux (automake 1.11.6) I've got:
> 
>      checking for XPROTO... no
>      configure: error: Could not find Xproto headers -   Try installing
> xorg-x11-proto-devel
> 
> I have Xproto.h and other headers in /usr/include/X11 . I tried to
> install x11-xproto from macports with the same results. I have a shallow
> knowledge in autotools, any suggestions about these issues are appreciated.
> 

I feel the message may be sending you on a wild goose chase.  The first thing
with configure scripts is always to check config.log to see the actual failing
output (at least for good autoconf macros which log the output).  I suspect this
is related to pkgconfig again, and it's not a lack of the header but an inability
to query pkgconfig for whether or not Xproto is installed.

configure:12966: checking for XPROTO
configure:12973: $PKG_CONFIG --exists --print-errors "xproto"
configure:12976: $? = 0
configure:12990: $PKG_CONFIG --exists --print-errors "xproto"
configure:12993: $? = 0
configure:13031: result: yes

> >
> > I haven't looked at the changes in full but I have a feeling they are more
> > due to
> > misconfiguration arising from this than something that would be generally
> > useful.
> I think it's better to compare patched sources configured on linux and
> mac, but haven't succeeded in this yet.
> 
> BTW, changes in a patch are similar to this change -
> http://hg.openjdk.java.net/icedtea/jdk7/jdk/diff/005c45393f0d/make/sun/xawt/FILES_c_unix.gmk
> 
> only for mac specific makefiles.
> 

Yeah I should have read the patch :)

The two changes to Mac OS X makefiles are obvious and the changes don't exist there
simply because those makefiles didn't exist when the original CUPS changes were made.

Likewise, the java/nio/Makefile code is needed because the same code, while already present,
is in a Linux-specific block.  Again, the Mac OS X block wouldn't have been present when this
was added and it's hard to determine if it's needed without testing on that platform.

Looking at this again, UnixDispatcher requires it so it should actually be moved to the !windows block.

Thanks a lot for all this testing.  It is much appreciated.

> 
> --
> Regards,
> Alex Kasko
> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07