And according to rpm, the version is:
$ rpm -q glibc
glibc-2.8-3.x86_64
/Erik
On 2014-06-03 03:01, Tim Bell wrote:
Hi - catching up on my email backlog:
Not sure what glibc version that is, though.
For Linux builds, others on build-dev@openjdk.java.net are more
knowledgeable about glibc u
On 2014-06-02 23:27, David DeHaven wrote:
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([$
On 2014-06-02 18:23, David DeHaven wrote:
* 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 p
That's puzzling - how does rpm square with what ldd is reporting? Is
glibc loaded dynamically, in which case my experiments are missing the
point...
hostname
sc11137352
/opt/jprt/products/P1/jdk8-latest/jdk1.8.0/bin/java -version
java version "1.8.0"
Java(TM) SE Runtime Environment (build 1.
I don't think they are conflicting. /lib/libc.so.6 is part of the
package glibc-2.8-3.
/Erik
On 2014-06-03 16:52, Tim Bell wrote:
That's puzzling - how does rpm square with what ldd is reporting? Is
glibc loaded dynamically, in which case my experiments are missing the
point...
hostname
s
Ah, I see. Thanks. So RPM (or equivalent) is the authority to consult
on Linux, at least until we get to JDK 9 and start using your devkits to
build.
Tim
On 06/03/14 14:58, Erik Joelsson wrote:
I don't think they are conflicting. /lib/libc.so.6 is part of the
package glibc-2.8-3.
/Erik
O
>>> * 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,
I've started looking at clearing the javac "finally" lint category from
the JDK sources. Once that is done, please review the corresponding
makefile change to enable the warning the build:
diff -r cb15bc14c26a make/Setup.gmk
--- a/make/Setup.gmkMon Jun 02 19:49:57 2014 +0400
+++ b/
+1. Not a "R"eviewer.
Cheers,
Henry
On 06/03/2014 11:07 AM, Joe Darcy wrote:
Hello,
I've started looking at clearing the javac "finally" lint category from
the JDK sources. Once that is done, please review the corresponding
makefile change to enable the warning the build:
diff -r cb15bc14c26a
Looks good to me as well-
Tim
On 06/03/14 18:14, Henry Jen wrote:
+1. Not a "R"eviewer.
Cheers,
Henry
On 06/03/2014 11:07 AM, Joe Darcy wrote:
Hello,
I've started looking at clearing the javac "finally" lint category from
the JDK sources. Once that is done, please review the corresponding
m
* 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
All,
On linux/SPARC the platform string returned from config.guess is
"sparc64-unknown-linux-gnu", but the build system doesn't currently
recognize "sparc64" as a valid cpu name. I'd like some feedback on how
to address this. I can see two ways:
1. Add it to the list of recognized cpu names
Hello all;
This is a small changeset to fix a problem where on some platforms (Solaris and
possibly others) the configure script doesn't properly detect the absence of
autoconf or mercurial because which returns a string for the failure condition.
The recipe used was previously in hgforest.sh f
13 matches
Mail list logo
