Makefile revision 3876
0N/A# Copyright (c) 2002, 2011, Oracle and/or its affiliates. All rights reserved. 0N/A# DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. 0N/A# This code is free software; you can redistribute it and/or modify it 0N/A# under the terms of the GNU General Public License version 2 only, as 0N/A# published by the Free Software Foundation. Oracle designates this 0N/A# particular file as subject to the "Classpath" exception as provided 0N/A# by Oracle in the LICENSE file that accompanied this code. 0N/A# This code is distributed in the hope that it will be useful, but WITHOUT 0N/A# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or 0N/A# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License 0N/A# version 2 for more details (a copy is included in the LICENSE file that 0N/A# accompanied this code). 0N/A# You should have received a copy of the GNU General Public License version 0N/A# 2 along with this work; if not, write to the Free Software Foundation, 0N/A# Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. 0N/A# Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA 0N/A# For Xrender extension. 0N/A# Since this library will be living in a subdirectory below the other libraries 0N/A# we need to add an extra runpath so that libraries in the upper directory 0N/A# are found at runtime. 0N/A# Add to the ambient vpath to pick up files in subdirectories # Allows for builds on Debian GNU Linux, X11 is in a different place # This should really be handled at a higher-level so we don't have to # work-around this when cross-compiling # We have some odd logic here because some Solaris 10 updates # have a render.h file that suggests gradients are supported, but # the Xrender.h doesn't have the corresponding type definitions. # Earlier updates have neither. We'd like to know if there's a mismatch. # Whilst in the C preprocessor we can tell if the render.h define's are set # we can't tell anything about C declarations. # A grep of Xrender.h is the only way to know this. If they are absent # we will set a flag indicating this mismatch and the JDK source file # will interpret it to resolve the problem. # On sparcv9 we generate both 32 and 64-bit sizers in spite of ARCH_DATA_MODEL. # On sparcv9 CFLAGS already contain $(XARCH_OPTION/64), so to generate 32-bit sizer we need to change this option. # On amd64 we generate both 32 and 64-bit sizers in spite of ARCH_DATA_MODEL. # On amd64 CFLAGS already contain $(XARCH_OPTION/64), so to generate 32-bit sizer we need to change this option. else # !sparcv9 : includes (32-bit) sparc, i586 # XXX Hack for 6185483 - use hard-coded sizes. # Add the 64-bit platforms that need to be included into 32-bit build # and have sizes.64-$(PLATFORM)-$(LIBARCH) hardcoded in the workspace # If you define DOHACK=true for some combination of $(PLATFORM)-$(LIBARCH), # make sure you have sizes.64-$(PLATFORM)-$(LIBARCH) pre-generated in # 64 bit sizers are generated on platform-libarch (left) for use # on platform-libarch (right) and stored under the latter name. # Do compare manually stored and automatically generated pair(s) # if DOCOMPARE=true, just after the generation.
