On 22/05/2013 05:20, David Holmes wrote:
On 21/05/2013 9:50 PM, Erik Joelsson wrote:
Looks good to me.
So has a bug been filed yet? :)
I think some further investigation is still needed because
gensrc_jobjc is being used in some places and not others and I'd want
to verify they are all supp
On 2013-05-22 06:20, David Holmes wrote:
On 21/05/2013 9:50 PM, Erik Joelsson wrote:
Looks good to me.
So has a bug been filed yet? :)
I think some further investigation is still needed because
gensrc_jobjc is being used in some places and not others and I'd want
to verify they are all su
On 21/05/2013 9:50 PM, Erik Joelsson wrote:
Looks good to me.
So has a bug been filed yet? :)
I think some further investigation is still needed because gensrc_jobjc
is being used in some places and not others and I'd want to verify they
are all supposed to be the same thing.
David
/Erik
Looks good to me.
/Erik
On 2013-05-21 13:30, Alan Bateman wrote:
On 21/05/2013 10:53, Erik Joelsson wrote:
In the old build, JObjC.jar was built completely differently from all
other java classes, by an ant script. We kept the source/target 1.5
when converting to the new build to keep the bui
On 21/05/2013 10:53, Erik Joelsson wrote:
In the old build, JObjC.jar was built completely differently from all
other java classes, by an ant script. We kept the source/target 1.5
when converting to the new build to keep the builds equal. I very much
doubt there is a reason for it now though. I
On 21/05/2013 7:53 PM, Erik Joelsson wrote:
In the old build, JObjC.jar was built completely differently from all
other java classes, by an ant script. We kept the source/target 1.5 when
converting to the new build to keep the builds equal. I very much doubt
there is a reason for it now though. I
In the old build, JObjC.jar was built completely differently from all
other java classes, by an ant script. We kept the source/target 1.5 when
converting to the new build to keep the builds equal. I very much doubt
there is a reason for it now though. It looks like left over legacy to me.
The
On 21/05/2013 08:36, David Holmes wrote:
While that is probably true, it seems to me that the cause of the
problem here is that the javac source path includes
/u/alanb/ws/tl/build/macosx-x86_64-normal-server-release/jdk/gensrc -
and that seems wrong to me. It comes from CompileJavaClasses.gm
On 21/05/2013 5:15 PM, Alan Bateman wrote:
On 21/05/2013 06:00, David Holmes wrote:
Hi Alan,
That log looks correct to me. can you verify if the missing types are
indeed within:
/u/alanb/ws/jdk7u-dev/build/macosx-x86_64/j2sdk-image/jre/lib/rt.jar
?
David
That's the boot JDK so it isn't goi
On 21/05/2013 06:00, David Holmes wrote:
Hi Alan,
That log looks correct to me. can you verify if the missing types are
indeed within:
/u/alanb/ws/jdk7u-dev/build/macosx-x86_64/j2sdk-image/jre/lib/rt.jar
?
David
That's the boot JDK so it isn't going to have types that are new in
jdk8. So
Hi Alan,
That log looks correct to me. can you verify if the missing types are
indeed within:
/u/alanb/ws/jdk7u-dev/build/macosx-x86_64/j2sdk-image/jre/lib/rt.jar
?
David
On 20/05/2013 12:32 AM, Alan Bateman wrote:
I've have an up-to-date clone of jdk8/tl + a patch to code in the jdk
repo
I've have an up-to-date clone of jdk8/tl + a patch to code in the jdk
repository that makes use of APIs that are new in jdk8. It builds/run
happily on all platforms except Mac where it needs to build JObjC.jar.
Attached is the tail of "make LOG=trace" where it looks like JObjC.jar
involves c
12 matches
Mail list logo
