> Please review this fairly trivial one line fix, the proposed patch is in the
> comments of the JBS issue, duplicated here for consistency:
>
> diff --git a/common/autoconf/flags.m4 b/common/autoconf/flags.m4
> --- a/common/autoconf/flags.m4
> +++ b/common/autoconf/flags.m4
> @@ -355,7 +355,
Please review this fairly trivial one line fix, the proposed patch is in the
comments of the JBS issue, duplicated here for consistency:
diff --git a/common/autoconf/flags.m4 b/common/autoconf/flags.m4
--- a/common/autoconf/flags.m4
+++ b/common/autoconf/flags.m4
@@ -355,7 +355,7 @@
>> I'm trying to build OpenJDK 8 on macOS 10.12, and having some trouble
>> getting it to accept the path to Xcode.
>>
>> $ ./configure
>> "--with-xcode-path=$HOME/DevEnv/Applications/Xcode4/Xcode.app"
>>
>> checking Determining if we need to set DEVELOPER_DIR... yes
>> (/Users/tester/DevEn
> I'm trying to build OpenJDK 8 on macOS 10.12, and having some trouble
> getting it to accept the path to Xcode.
>
>$ ./configure
> "--with-xcode-path=$HOME/DevEnv/Applications/Xcode4/Xcode.app"
>
>checking Determining if we need to set DEVELOPER_DIR... yes
> (/Users/tester/DevEnv/Appl
> JLI_Launch is an *internal* entry point, this is primarily used in main.c,
>> and this is called by JDK's tool launchers which sets
>> "NEVER_ACT_AS_SERVER",
>> also this entry point is used by the java packager and deployment, I
>> have cc'ed
>> C
Please review these fairly trivial patches for:
https://bugs.openjdk.java.net/browse/JDK-8167187
It was decided that since getWindow is deprecated and likely to be removed in a
future release that it's not worth changing the signature which would
potentially break other uses of jdk.jsobject in
After having some internal discussions we've decided to set forRemoval to false
as we're not certain which release it will be removed in and it's likely to be
needed in at least 10.
-DrD-
It can't find the SDK.
After installing command line tools, did you run "sudo xcode-select -switch
/path/to/Xcode.app"?
-DrD-
> On Jun 22, 2016, at 10:09 PM, Pete Brunet wrote:
>
> Installed 6.3.2. Refreshed source. Ran configure. make clean. make
> images. Build failed with
>
> === Out
> David had said,
>
>> it seems safer to leave it false for now and revisit marking for removal in
>> 10
>
> I think this means, "set forRemoval=false in 9, set forRemoval=true in 10,
> and actually remove it in 11".
I said that in reference to Applet, not JSObject.
I now think JSObject shou
true" is added to @Deprecated annotation for
>>>> JSObject.getWindow(Applet) method.
>>>> 2. A new doc bundle for JSObject documentation is added in the docs build.
>>>>
>>>> Webrev: http://cr.openjdk.java.net/~dtitov/8156960/jdk/webrev.01
&
http://cr.openjdk.java.net/~dtitov/8156960/webrev.01
>>
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8156960
>>
>> Thank you!
>>
>> Best regards,
>> Daniil
>>
>> -Original Message-
>> From: Mandy Chung
Sorry, we had LIVECONNECT_PKGS previously...
-DrD-
> How about NON_CORE_PKGS.gmk for javadoc?
>
> Something like:
>
> diff --git a/make/common/NON_CORE_PKGS.gmk b/make/common/NON_CORE_PKGS.gmk
> --- a/make/common/NON_CORE_PKGS.gmk
> +++ b/make/common/NON_CORE_PKGS.gmk
> @@ -44,6 +44,8 @@
>
How about NON_CORE_PKGS.gmk for javadoc?
Something like:
diff --git a/make/common/NON_CORE_PKGS.gmk b/make/common/NON_CORE_PKGS.gmk
--- a/make/common/NON_CORE_PKGS.gmk
+++ b/make/common/NON_CORE_PKGS.gmk
@@ -44,6 +44,8 @@
org.w3c.dom.events \
org.w3c.dom.views
+JSOBJECT_PKGS = netsca
Clarification: in a future *as of yet unspecified* release :)
-DrD-
> On Jun 8, 2016, at 1:13 PM, Kevin Rushforth
> wrote:
>
> Yes, the plan is to deprecate it in 9 and remove it in a future release.
>
> -- Kevin
>
>
> Mandy Chung wrote:
>> The client team owns jdk.jsobject module and so I
Why is this still an issue???
The fix is stupid simple:
diff --git a/src/java.desktop/macosx/native/libosxapp/NSApplicationAWT.m
b/src/java.desktop/macosx/native/libosxapp/NSApplicationAWT.m
--- a/src/java.desktop/macosx/native/libosxapp/NSApplicationAWT.m
+++ b/src/java.desktop/macosx/native/l
>> I've updated the webrev, hopefully one last time with feedback from Joe
>> Darcy.
>> http://cr.openjdk.java.net/~ddehaven/8132743/webrev.2/
>>
>> - Relocated package Javadoc to above the package declaration in
>> package-info.java
>> - Reworded the Javadoc on the default JSObject ctor
>>
>>
d to me.
>
> -- Kevin
>
>
> David DeHaven wrote:
>> Updated webrev:
>>
>> http://cr.openjdk.java.net/~ddehaven/8132743/webrev.1/
>>
>>
>> Added jdk.jsobject to MAIN_MODULES
>> Made suggested Javadoc changes
>> Gave JSException a real
>>> Updated webrev:
>>> http://cr.openjdk.java.net/~ddehaven/8132743/webrev.1/
>>>
>> Looks fine to me. Thanks for the update.
>>
> Just reading the javadoc again and I wonder about this statement in the
> package description:
>
> "The classes in this package were initially specified by Netsc
Updated webrev:
http://cr.openjdk.java.net/~ddehaven/8132743/webrev.1/
Added jdk.jsobject to MAIN_MODULES
Made suggested Javadoc changes
Gave JSException a real serialVersionUID
-DrD-
> On Mar 3, 2016, at 5:06 PM, David DeHaven wrote:
>
>
> Adding it to MAIN_MODULES, I n
ick test build and I can see the new package in
>> the exploded JDK, but not in the images. Maybe I did something wrong?
>>
>
> Good catch.
>
> jdk.jsobject needs to be added in MAIN_MODULES list in make/Images.gmk
>
> Mandy
>
>> -- Kevin
>>
>&g
> jdk9-dev is not the right mailing list. I bcc’ed it and add jigsaw-dev
> instead.
>
>
>> On Mar 3, 2016, at 3:57 PM, Kevin Rushforth
>> wrote:
>>
>> Looks OK to me. I did a quick test build and I can see the new package in
>> the exploded JDK, but not in the images. Maybe I did something
>> JBS Issue:
>> https://bugs.openjdk.java.net/browse/JDK-8132743
>>
>> Code review:
>> http://cr.openjdk.java.net/~ddehaven/8132743/webrev.0/
>
> Looks okay. There is no @since - I guess it’s okay because
> netscape.javascript has been shipped with plugin for long time.
I can't track down wh
JBS Issue:
https://bugs.openjdk.java.net/browse/JDK-8132743
Code review:
http://cr.openjdk.java.net/~ddehaven/8132743/webrev.0/
Summary:
- Moved netscape.javascript.{JSObject,JSException} from closed source plugin to
jdk
- Convert package.html to package-info.java
- Cleaned up Javadoc somewhat
JBS link:
https://bugs.openjdk.java.net/browse/JDK-8147754
Please review this small fix for locating Freetype with the updated version of
XQuartz (for OSX 10.11):
--- cut here ---
diff --git a/common/autoconf/lib-freetype.m4 b/common/autoconf/lib-freetype.m4
--- a/common/autoconf/lib-freetype.m
> What is the latest version of XCode we can use to build? I need to
> reinstall and am currently at 6.2.
You can copy Xcode to a different location and use "sudo xcode-select -switch
/path/to/old/Xcode.app" if you ever need to go back. Just keep older copies of
Xcode.app out of /Applications
This came up a while back, probably on another list...
XQuartz had to change the install location due to 10.11 not allowing
installation to /usr/X11, so our configure script should be updated to
also check in /opt/X11 now. I don't know if a bug was ever filed for this
>>> Thanks, looks like this does the trick:
>>>
>>> ./configure --with-freetype=/opt/X11
>>
>> This came up a while back, probably on another list...
>>
>> XQuartz had to change the install location due to 10.11 not allowing
>> installation to /usr/X11, so our configure script should be update
>> Thanks, looks like this does the trick:
>>
>> ./configure --with-freetype=/opt/X11
>
> This came up a while back, probably on another list...
>
> XQuartz had to change the install location due to 10.11 not allowing
> installation to /usr/X11, so our configure script should be updated to als
>> Once you know where you installed freetype, the short-term workaround is
>> to provide this path to configure using --with-freetype. The long-term is
>> that we can add some additional "well known" paths to look at by default in
>> configure to save some typing.
>
>
> Thanks, looks like this
> Could be, but I don't care at all about running X11. I just want "make
> images" to work.
>
> I'm a little fuzzy on the details here -- who created /usr/X11R6 (it seems to
> be present on all vanilla Yosemite Macs around my house, but without
> headers), who created /usr/X11, what the XQuar
To determine the number of physical cores:
On Mac:
sysctl -n hw.physicalcpu_max
Or, if that's not available:
sysctl -n hw.ncpu
On Linux, you could parse /proc/cpuinfo (look at "physical id" and "cpu cores")
using awk/grep/sed/sort/whatever
Or:
for cpudir in /sys/devices/system/cpu/cpu[0-9]*;
> A common need when working with complex configure argument lists is to figure
> out what configuration that's currently being used.
>
> This patch introduces a new make target "print-configuration" which will just
> print the arguments used to run configure.
Thank you! Now I don't have to ch
>> and now get the warnings:
>>
>> -
>> Compiling 13 files for jdk.policytool
>> clang: error: unknown warning option
>> '-Wno-tautological-constant-out-of-range-compare'; did you mean
>> '-Wno-tautological-compare'?
>> make[3]: ***
>> [/Users/ljanders/Documents/hg-workspaces/openjdk9/mo
JBS Issue:
https://bugs.openjdk.java.net/browse/JDK-8130929
I need a small change to top level test/Makefile. If closed/test/Makefile is
not present it is simply ignored so this should have no impact on OpenJDK
builds. This change will allow (any) closed source components to be supported
with
> I believe this is a problem of string comparisons of file paths and character
> case. The file system on Macosx is case insensitive, but we aren't treating
> it as such properly.
Filesystem is not (it's optional in HFS+ actually, defaulting to insensitive),
but tools might be, specifically t
t;>> Hi David
>>>
>>> —with-code-path is an unrecognised option; it’s not there in the configure
>>> script as well.
>>>
>>> Manas
>>>
>>>
>>>> On 10-Jun-2015, at 2:41 am, David DeHaven wrote:
>>>>
/Frameworks"
>> --with-extra-cxxflags="-isysroot
>> /Applications/Xcode4.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk
>>
>> -F/Applications/Xcode4.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sd
> Hi all
>
> I had posted about problems with building openjdk8 on Mac OS X Yosemite last
> year. I am still unable to do the same. I did the following based on some
> posts tot he list in January:
>
> 1. bash configure
> —with-tools-dir=“/Applications/Xcode4/Xcode.app/Contents/Developer/usr/
sx-maverick.html
>>> say to install XQuartz, but that didn't help. BTW, My OS is Mavericks.
>>>
>>> If it matters I have not yet moved Xcode out of /Applications.
>>>
>>> Pete
>>>
>>> On 5/6/15 11:11 AM, David DeHaven wrot
Correct, --with-xcode-path is for jdk8u only as it requires building with Xcode
4. For jdk9 use the Xcode 5.1 or later.
The Xcode 6.3 patch is in hotspot, it will be integrated to dev hopefully in
the near future. In the meantime you can apply the patch to your local
workspace.
Or, if you hav
hough (at least works for me).
>
> Thanks,
> Vadim
>
> On 16.04.2015 23:18, David DeHaven wrote:
>> Sorry, I've had my blinders on for a few weeks. What's the original goal
>> here? Are you just trying to build OpenJDK 9 on Mac OS X? If you're using
>&g
gt; Hi David,
>
> Thanks for your response! I was using GCC as I had a host of other errors
> when using clang :-|. I'll post those in a separate mail for comparison.
>
> Cheers,
> Martijn
>
> On 15 April 2015 at 18:22, David DeHaven wrote:
>
> > Mac OS X 1
> Mac OS X 10.10.3, latest Xcode (6.3), using GCC 4.8
>
>
>
> After getting past the defined(__OPENBSD__) bug I'm running into a host of
> new errors starting with:
>
> /Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk9/hotspot/agent/src/os/bsd/MacosxDebuggerLocal.m:26:
> /
Be careful placing older versions of Xcode in /Applications. I've had MAS
auto-update Xcode deleting old versions in the process.
-DrD-
> Pete, have you tried
> sh configure --with-xcode-path=/Applications/Xcode\ 4.6.3.app/
> ?
> It seems that the configure doesn't pick the correct path from th
Cool, glad it helped!
-DrD-
> Thanks for the suggestion David. Interestingly enough it did build without
> ccache.
>
> - Sandeep
>
>
>> On Apr 1, 2015, at 1:53 PM, David DeHaven wrote:
>>
>>
>>> On Apr 1, 2015, at 1:34 PM, Sandeep Koncha
> On Apr 1, 2015, at 1:34 PM, Sandeep Konchady
> wrote:
>
> I am trying to build OpenJDK only on my MBP with OS X 10.10.2 and Xcode 5.1.
> Log from configure and build error attached. Any help would be much
> appreciated.
>
> Darwin Kernel Version 14.1.0
>
> using configure arguments '--ena
>>>>> Hi David
>>>>>
>>>>> On 18/03/2015 8:54 AM, David DeHaven wrote:
>>>>>> Fairly minor build system bug fix on Mac. In short, the
>>>>>> -mmacosx-version-min argument is never being passed to the linker,
>>
>>> Hi David
>>>
>>> On 18/03/2015 8:54 AM, David DeHaven wrote:
>>>> Fairly minor build system bug fix on Mac. In short, the
>>>> -mmacosx-version-min argument is never being passed to the linker,
>>>> where it's actually n
Fairly minor build system bug fix on Mac. In short, the -mmacosx-version-min
argument is never being passed to the linker, where it's actually needed to
assert the minimum OS version requirement in the final Mach-O binary. This was
causing ld to fail when building on 10.10. I've no idea why it's
Previously, things were too .. "jiggly" to just remove everything listed lest
the whole structure collapsed. Nice to see more effort on this front.
Yes, OSX is still a cross-breed between "solaris" source and it's own source,
hence the overly complicated exclusion patterns. Or was, maybe things
>> Open question: Should we do the same for toolchain-type=gcc? I'm not quite
>> sure what we're getting from calling the AC_PROG_OBJC macro, except perhaps
>> a loss of transparency on how our tools are picked up. :-/ In fact, maybe we
>> should just skip the OBJC variable completely. In fact,
Can someone from hotspot-dev please look at the hotspot changes?
-DrD-
> Hello,
>
> This looks good to me. Thanks for the detailed table!
>
> /Erik
>
> On 2015-01-14 04:09, David DeHaven wrote:
>>>> The --with-xcode-path argument is optional, you should also
>> The --with-xcode-path argument is optional, you should also be able to build
>> with Xcode 4 selected via "sudo xcode-select -switch /path/to/Xcode4.app". I
>> leave MAS managed Xcode (currently 6) active as I'm constantly bouncing
>> between projects and it's a hassle to have to remember to
I don't know why Hotspot is packaged as a universal binary. In the jdk,
only libJObjC was built as a universal binary and that lib was removed
before JDK 8 shipped. What part of Macosx would need to interact
directly with libjvm.dylib in a way that required a (fake) universal
>
> The --with-xcode-path argument is optional, you should also be able to build
> with Xcode 4 selected via "sudo xcode-select -switch /path/to/Xcode4.app". I
> leave MAS managed Xcode (currently 6) active as I'm constantly bouncing
> between projects and it's a hassle to have to remember to res
gt; With these changes, configure will unconditionally fail if trying to use
>> XCode 5. I know we don't officially support using XCode 5 for JDK 8, but
>> aren't people working around it with some patches? How hard would it be to
>> make it at least build?
>>
7;t officially support using XCode 5 for JDK 8, but
> aren't people working around it with some patches? How hard would it be to
> make it at least build?
>
> /Erik
>
> On 2015-01-10 05:45, David DeHaven wrote:
>> Please review the open source changes for 8043340. Th
We have this nice little comment in common/autoconf/jdk-options.m4:
# On Macosx universal binaries are produced, but they only contain
# 64 bit intel. This invalidates control of which jvms are built
# from configure, but only server is valid anyway. Fix this
# whe
Please review the open source changes for 8043340. The goal here is to get
jdk8u to build on Mac OS X 10.9+ systems where Xcode 5+ and Xcode 4 are
co-installed, a configuration which is becoming more and more commonplace as
more developers are focusing on JDK 9 now (which needs Xcode 5 installe
We have this nice little comment in common/autoconf/jdk-options.m4:
# On Macosx universal binaries are produced, but they only contain
# 64 bit intel. This invalidates control of which jvms are built
# from configure, but only server is valid anyway. Fix this
# when hotspot makefiles are r
>> Yes, I just found this out the hard way yesterday (and many other patches
>> are required too).
>>
>> Is there any chance OS X fixes can make it upstream?
>
> This basically requires backporting JDK-8043340 to jdk8u, which I've been
> poking at here and there but have not had the time to re
> MacPorts lipo (it works, put it earlier on your path because hotspot build
> references "lipo" with no fancy variables)
The lipo problem is freaking annoying. The issue is Xcode 4 doesn't have it in
the OSX toolchain, it installed the actual binary to /usr/bin/lipo. In Xcode 5
that was repla
You should direct FX related issues to openjfx-dev instead.
-DrD-
> I am trying to build JavaFX with native media enabled. For background, read
> *The initial problem* below.
>
> So I am stuck in build.gradle ( line 2392 for me) in def buildGlib{ I
> have progressed somewhat since the
>> You need to patch /hotspot/make/bsd/makefiles/saproc.make to make it use
>> 10.8sdk instead of system library in Yosemite.
>>
>> - SALIBS = -g -framework Foundation
>> -F/System/Library/Frameworks/JavaVM.framework/Frameworks
>> -framework JavaNativeFoundation -framework Security -framework Co
Not 8, 9...
-DrD-
> Hi Wang
>
> You were able to compile openjdk8 on Yosemite!! Can you please look into the
> error faced by me (first post in the thread; posted below as well) and figure
> out the problem(s)?
>
> Regards,
> Manas
>
>
>
>> Yes, I can compile the whole mess on Yosemite/Xc
>> A longer answer is that we're currently working on getting jdk9 to compile
>> on Yosemite.
>
> Isn't it already compiling? I am on Yosemite and I can compile both openjdk
> and closedjdk successfully.
Yes, I can compile the whole mess on Yosemite/Xcode 6.1. There was an issue
with FreeType
Technically even Mavericks, but really it's Xcode 5/6... I never backported my
Xcode 5 changes to 8u. It was on my list for a while but never accomplished due
to lack of time.
Is there interest in doing so? If so, I can try to find the time to scrape up a
backport.
The final webrevs for JDK9
>>> I suspect it'll be easier to just install gcc on your mac. The last time I
>>> checked openjdk 8 didn't compile correctly with clang, so you might also
>>> have to patch the source code as well as the autoconf scripts.
>> So Apple are now shipping a compiler by default, but it's clang, which
>
Ping? Can a build-dev Reviewer approve this?
-DrD-
>> Please review my trivial backport of JDK-8038027. The actual change is
>> identical to 9, the difference is the surrounding $(JAVA) is $(JAVA_SMALL)
>> in JDK 9.
>>
>> JBS Issue:
>> https://bugs.openjdk.java.net/browse/JDK-8038027
>>
>> J
There's some changes in 9 that should be backported to 8u so developers on 10.9
will be able to build. JDK-8043340 (that I just pushed to 9) is one, but it's
dependent on at least one other change.
-DrD-
> Attempting to build JDK 8 on Mavericks I found the same problem:
>
> $ sh configure --w
th the ARCH setting. If none of the existing
>> variables are suitable perhaps just add SA_CFLAGS?
>>
>> If SDKROOT is not set is the path one that would normally exist? In
>> particular does it exist on all our JPRT clients?
>>
>> Thanks,
>> Dav
And now actually including build-dev...
Please review this slightly different backport of JDK-8038027 to 8u.
-DrD-
>
> Please review my trivial backport of JDK-8038027. The actual change is
> identical to 9, the difference is the surrounding $(JAVA) is $(JAVA_SMALL) in
> JDK 9.
>
> JBS Issu
And just FYI, I got a mostly clean JPRT run:
Four failures, a couple already tracked by the following issues:
https://bugs.openjdk.java.net/browse/INTJDK-7609054
https://bugs.openjdk.java.net/browse/JDK-8043951 (reported to jprt_admin)
This might be related to the latter as it happened only on t
>>> $ sudo xcode-select -switch /Applications/old/Xcode4.app
>>> $ make clean; sh ./configure; make images
>>> Broken! The current Xcode command line tools don't run gcc as gcc even if
>>> Xcode 4 is active
>>> Nothing we can do about this, anyone needing to use Xcode 4 will need to
>>> use --wi
Can I get another Review on this?
Also, since I don't think the servers have been updated to allow me to push
yet, I may need someone to push for me.
-DrD-
> Next (hopefully last??) update:
> http://cr.openjdk.java.net/~ddehaven/8043340/v3
>
> (ignore changes to jdk/src/macosx/native/sun/osxa
Ok, thanks.
-DrD-
> At some point I mean. It's ok to not do it as part of this change.
>
> /Erik
>
> On 2014-06-09 10:06, Erik Joelsson wrote:
>> It certainly should be updated.
>>
>> /Erik
>>
>> On 2014-06-05 23:51, David DeHaven wrote:
>
Will README-builds.html be updated as part of the compiler update? It (will be)
outdated.
I don't think it needs to be part of this patch since I'd like to backport this
(and the other patches I've contributed recently) to 8u after it incubates for
a while.
-DrD-
>> Only thing I can think of
> Only thing I can think of now is that some of the error/warning messages do
> not start with a capital letter. Looks good and nice work!
I'll fix those before pushing.
>> I also removed using SDKROOT from the env, since we ignore the environment.
>> Only two args affect SYSROOT now, --with-
Next (hopefully last??) update:
http://cr.openjdk.java.net/~ddehaven/8043340/v3
(ignore changes to jdk/src/macosx/native/sun/osxapp/ThreadUtilities.m, that's a
separate patch)
I also removed generated_configure.sh since those will be automatically
generated before pushing anyways and it just k
* Why remove MACOSX_VERSION_MIN=@MACOSX_VERSION_MIN@? I believe we still
use this in some closed makefiles. Or is the idea that we instead will
force the sdk name to 10.7? If so, then we need to still leave this in
until every user (RE) has switched properly.
>>> I moved all
>>> * Why remove MACOSX_VERSION_MIN=@MACOSX_VERSION_MIN@? I believe we still
>>> use this in some closed makefiles. Or is the idea that we instead will
>>> force the sdk name to 10.7? If so, then we need to still leave this in
>>> until every user (RE) has switched properly.
>> I moved all that
> Looks pretty good. A couple of questions still:
>
> * Where is the AC_SUBST for SDKROOT?
>
> * Could we get the "Checking for Xcode sdk name" output to only print on
> macosx?
Would this be OK instead?
AC_MSG_CHECKING([for sdk name])
AC_MSG_RESULT([$SDKNAME])
Otherwise it might mak
>> * Why remove MACOSX_VERSION_MIN=@MACOSX_VERSION_MIN@? I believe we still use
>> this in some closed makefiles. Or is the idea that we instead will force the
>> sdk name to 10.7? If so, then we need to still leave this in until every
>> user (RE) has switched properly.
>>
>> I moved all that
> Hello David,
>
> Looks pretty good. A couple of questions still:
>
> * Where is the AC_SUBST for SDKROOT?
Oops, that should've been after SDKROOT="$SYSROOT" in basics.m4.
> * Could we get the "Checking for Xcode sdk name" output to only print on
> macosx?
Can do.
> * Why remove MACOSX_V
>>
>> run this:
>> $ find /Library/Developer/CommandLineTools -name '*.sdk'
>
> Nothing.
>
I tried this again. The command line installation creates:
1. /Library/Developer/CommandLineTools
2. /usr/include
3. Many many /System/Library/Frame
run this:
$ find /Library/Developer/CommandLineTools -name '*.sdk'
>>>
>>> Nothing.
>>>
>>
>> I tried this again. The command line installation creates:
>>
>> 1. /Library/Developer/CommandLineTools
>> 2. /usr/include
>> 3. Many many /System/Library/Frameworks/.../Headers
>> 4. Some e
>>> run this:
>>> $ find /Library/Developer/CommandLineTools -name '*.sdk'
>>
>> Nothing.
>>
>
> I tried this again. The command line installation creates:
>
> 1. /Library/Developer/CommandLineTools
> 2. /usr/include
> 3. Many many /System/Library/Frameworks/.../Headers
> 4. Some examples and
> Here's the latest patch set:
> http://cr.openjdk.java.net/~ddehaven/8043340/v2/
Just FYI, I ran a build only job on JPRT and it passed:
Build Stats:14 pass, 0 fail, 0 killed, 0 working, 0 initializing, 0 not
started
-DrD-
>> I'm curious if only installing the CL tools also installs at least one OS X
>> SDK. If it doesn't then it's not terribly useful, except for maybe
>> porting/building Unix command line tools.
>
> Well, I guess it did. At least jdk9 builds successfully. My new Mavericks is
> installed on the
> closer to the sysroot setting, which is setup in BASIC_SETUP_DEVKIT. I
> realize you then need to find xcodebuild there already, using the
> TOOLCHAIN_PATH, but I think that's ok, since that tools is used specifically
> for finding a sysroot on mac.
>
> Overall, I like where this is go
>> On the other hand, it looks like xcodebuild is not always installed.
>>
>
> IIRC, this is what trigger the dialog ask what do you want to install. Can
> you find out where is your xcodebuild located and what does it return with
> xcodebuild -version?
Apple installs stub binaries in /usr/bi
>>> On the other hand, it looks like xcodebuild is not always installed.
>>>
>>
>> IIRC, this is what trigger the dialog ask what do you want to install. Can
>> you find out where is your xcodebuild located and what does it return with
>> xcodebuild -version?
>
> It is a clean install of Mave
> I just installed a brand new Mavericks and go straight to 'bash configure'
> for jdk9/dev. A dialog pops out asking me to choose between installing Xcode
> and downloading command line tools. I choose the latter and after they are
> installed I run configure again, and it shows
>
> Failed t
t looks cleaner from one way, but also increases
> confusion I think. I prefer a special parameter, which helps setting sysroot
> as suggested.
>
> If you need a synonym for SYSROOT in macosx, that seems fine to me.
>
> /Erik
>
> On 2014-05-23 18:38, David DeHaven wrote
> fi
>>
>> This will eliminate any added configure arguments.
>>
>> (14 hours of build system hacking makes for a very muddled mind...)
>>
>> -DrD-
>>
>>
>>> Hello David,
>>>
>>> I like that you incorporate the
ld system hacking makes for a very muddled mind...)
>
> -DrD-
>
>
>> Hello David,
>>
>> I like that you incorporate the existing sysroot settings for this. I wonder
>> though, what is the difference between --with-macosx-sdk-path and
>> --with-sysroot?
existing sysroot settings for this. I wonder
> though, what is the difference between --with-macosx-sdk-path and
> --with-sysroot? Do we really need two parameters for this? If it's actually a
> sysroot, couldn't we replace all uses of this variable with just SYSROOT and
Build systems take such a long time work on...
I've changed the logic, I think for the better. I hijacked --with-sysroot,
SYSROOT is set to the SDK path and I stuffed the -iframework argument alongside
the -isysroot arg in SYSROOT_CFLAGS and it works very nicely. Now the only
change that's pep
>> That will cause the -isysroot argument to be invalid. I can either make an
>> undefined MACOSX_SDK_PATH a hard error (in configure)
>
> Earlier failure is better.
>
>> or I can wrap all uses of -isysroot/-iframework with ifneq blocks.
>
> Yuck.
Agreed. I already don't like that I have to u
-DrD-
> We have several platform specific tools defined that way already (CYGPATH,
> MT, RC to name a few), so no worries. The error would be trying to use them
> on the wrong platform, but protecting the assignment won't help with that.
>
> /Erik
>
> On 2014-05-21 1
1 - 100 of 165 matches
Mail list logo
