Changes to fdlibm code should be review on core-libs-dev rather than
build-dev.
However, given the nature of the code, I am not inclined to approach
changes to fdlibm to work around new C compiler warnings.
-Joe
On 10/16/2014 6:08 PM, David Chase wrote:
I am more competent at modifying FP s
I am more competent at modifying FP source code than I am at tinkering with
flags in our build system.
If someone else is solving the problem, they might choose what works best for
them, I am glad if that happens.
But till something happens, I am (very) build-impaired, or I can just make all
my
David,
I think it is more appropriate to look to compile fdlibm with a
different set of flags, as has been done in at least previous iterations
of the build system.
Thanks,
-Joe
On 10/16/2014 2:37 PM, David Chase wrote:
Rhetorical question, actually — someone clearly did.
Someone also did
Rhetorical question, actually — someone clearly did.
Someone also did not test it with gcc 4.8.recent on Ubuntu 14 or Clang.current
on Mavericks.
One of the offending directories is fdlibm, and I have experience with that, so
since I can’t
get anything else done, I will see about cleaning up tha
On 10/16/14 3:20 AM, shanliang wrote:
Hi,
Here is the new version:
http://cr.openjdk.java.net/~sjiang/JDK-8060692/02/
Looks fine to me.
thanks
Mandy
On 16 Oct 2014, at 15:58, Erik Joelsson wrote:
> Hello,
>
> The main problem is that we now will have Gensrc-$m.gmk for the same module
> in multiple repos. Now, that just happened again with my patch to split
> GensrcProperties.gmk (jdk.dev has gensrc in both langtools and jdk), so I
> took
Hi Erik,
On Thu, 2014-10-16 at 16:52 +0200, Erik Joelsson wrote:
> Hello Severin,
>
> Thank you for the bugfix. It does indeed look like a typo. I can sponsor
> the change for you. However, to satisfy legal requirements, you will
> need to send the patch directly to us. Since it's small, you ca
Hello,
The main problem is that we now will have Gensrc-$m.gmk for the same
module in multiple repos. Now, that just happened again with my patch to
split GensrcProperties.gmk (jdk.dev has gensrc in both langtools and
jdk), so I took the time to solve it in M2. What I mean by this is that
M2
Hello Severin,
Thank you for the bugfix. It does indeed look like a typo. I can sponsor
the change for you. However, to satisfy legal requirements, you will
need to send the patch directly to us. Since it's small, you can just
paste it in a mail to the mailing list and it will be fine.
/Erik
Erik,
Pavel has already pushed the JNDI changes, and will follow up with the service
configuration files later, so this issue is less pressing. If you like lets
defer addressing the general problem of concatenating service configuration
files until jigsaw/m2 is in the JDK 9 mainline. There is n
Looks good now.
/Erik
On 2014-10-16 12:20, shanliang wrote:
Hi,
Here is the new version:
http://cr.openjdk.java.net/~sjiang/JDK-8060692/02/
./02/jdk9-open/ has 2 more deleted files than in ./01/jdk9-jdk-src/
test/com/sun/jmx/snmp/
SnmpOidHashCode.java, TimeTicksWrapping.java
./
Hi,
I've noticed that when I do a build of OpenJDK 9 hs-comp forest then the
generated build ID eats the "w" from my local username. Reproducer bash
snippet:
(USER=xwwwx; a=$(echo $USER | tr -d -c
'abcdefghijklmnopqrstuvqxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789'); if [ "$a" ==
"xx" ]; then echo
Hi,
Here is the new version:
http://cr.openjdk.java.net/~sjiang/JDK-8060692/02/
./02/jdk9-open/ has 2 more deleted files than in ./01/jdk9-jdk-src/
test/com/sun/jmx/snmp/
SnmpOidHashCode.java, TimeTicksWrapping.java
./02/jdk9-make/ has one more modified:
make/common/Modules.gmk
Hello Valierie,
In Copy-java.base.gmk, you could change the findstring construct to a
simple "ifeq ($(OPENJDK_TARGET_OS), windows)", perhaps even fold the
whole ifndef OPENJDK into the previous ifeq since they are now the same.
Otherwise it looks good to me.
/Erik
On 2014-10-15 20:46, Valer
14 matches
Mail list logo