>>> JPRT as far as I know only uses 10.7 systems for builds. The 10.8 systems
>>> can only be used for testing.
>> Since we have added the compiler and link args described earlier in this
>> thread to jdk8 makefiles, I believe we have enabled 10.8 for building jdk8
>> too now. At least we inten
On May 21, 2013, at 2:18 AM, Erik Joelsson wrote:
>> JPRT as far as I know only uses 10.7 systems for builds. The 10.8 systems
>> can only be used for testing.
> Since we have added the compiler and link args described earlier in this
> thread to jdk8 makefiles, I believe we have enabled 10.8 f
On 2013-05-16 06:18, David Holmes wrote:
On 16/05/2013 10:22 AM, David Katleman wrote:
On 5/13/2013 8:59 AM, David DeHaven wrote:
If it were my choice, Mac OS X 10.8 would be the base OS with Xcode
4.6.1 (current) with clang as the officially supported compiler and
with an option to use gcc.
On 16/05/2013 10:22 AM, David Katleman wrote:
On 5/13/2013 8:59 AM, David DeHaven wrote:
If it were my choice, Mac OS X 10.8 would be the base OS with Xcode
4.6.1 (current) with clang as the officially supported compiler and
with an option to use gcc. I don't see why that would't last at least
>> If it were my choice, Mac OS X 10.8 would be the base OS with Xcode 4.6.1
>> (current) with clang as the officially supported compiler and with an option
>> to use gcc. I don't see why that would't last at least the public lifecycle
>> of JDK8. What I would be more concerned with is the appa
On 5/13/2013 8:59 AM, David DeHaven wrote:
If it were my choice, Mac OS X 10.8 would be the base OS with Xcode 4.6.1
(current) with clang as the officially supported compiler and with an option to
use gcc. I don't see why that would't last at least the public lifecycle of
JDK8. What I would b
3) Support both (since they should both compile the same source) but
identify Clang as the official tool.
>>> We're currently using the gcc front end. I think it would take signifiant
>>> work to switch to the clang front end.
>> In my experience it takes no work at all...
>
> Anyone
>> Does this imply the underlying version of macosx doesn't matter, as long as
>> you're using Xcode 4.6.1 (or what ever we have standardized upon for JDK8)
>> with -mmacosx-version-min=10.7?
>>
>> That would solve our new machines always having the latest macosx issue,
>> that is as long as
On 14.05.2013 2:01, David Katleman wrote:
Does this imply the underlying version of macosx doesn't matter, as
long as you're using Xcode 4.6.1 (or what ever we have standardized
upon for JDK8) with -mmacosx-version-min=10.7?
That would solve our new machines always having the latest macosx
i
On 5/13/2013 1:21 PM, David DeHaven wrote:
3) Support both (since they should both compile the same source) but identify
Clang as the official tool.
We're currently using the gcc front end. I think it would take signifiant work
to switch to the clang front end.
In my experience it takes no w
>> 1) Use gcc as the build does today.
>
> Does this mean the gcc+clang provided by XCode or some random port of GCC
> (fink/macports)? I would be concerned with using "cygwin quality" (if that
> doesn't make you cringe you haven't been using cygwin long enough) GCC port
> rather than the Appl
On May 10 2013, at 15:16 , Tim Bell wrote:
> All-
>
> The question of what toolchain to use on MacOS when building JDK8 is in play.
>
> This is important because the decisions we make in the next few weeks will be
> in place for the lifetime of JDK8, including all future JDK8 update releases.
Clang emulates gcc (even so far as identifying itself as GCC for source level
compatibility), they use the same command line arguments. Internally, clang has
a somewhat better optimizer than gcc and feedback to the developer (warnings,
error, etc..) is generally more useful than gcc. They both
One reason to use gcc instead of clang would be to have one less difference
between platforms. It's always annoying when different compilers have a
different set of warnings (even if the warnings are correct and useful) and you
try to get something to compile on all platforms.
I don't know if t
A problem with gcc-4.8 as installed by MacPorts, if we ever intended to build
32-bit binaries:
gcc-mp-4.8 -O -m32 -msse -mpclmul -mavx TryLoop.c -lz
ld: warning: ignoring file /opt/local/lib/gcc48/libgcc_ext.10.5.dylib, missing
required architecture i386 in file /opt/local/lib/gcc48/libgcc_ex
Which version of MacOS? 10.8.3 is current, rumor is 10.9 is coming sometime
later this year, and we had problems obtaining boxes running 10.7 for testing
purposes. We may have a similar problem later this year; I imagine that new
Macs for testing and/or development get purchased after June, 10
All-
The question of what toolchain to use on MacOS when building JDK8 is in
play.
This is important because the decisions we make in the next few weeks
will be in place for the lifetime of JDK8, including all future JDK8
update releases.
I have a few different pieces of feedback at this p
17 matches
Mail list logo
