On 3/18/14 12:22 PM, Andrew Hughes wrote:
- Original Message -
On 3/17/14 7:19 PM, Andrew Hughes wrote:
- Original Message -
On 3/3/14 2:49 PM, Omair Majid wrote:
* David Holmes [2014-02-28 18:48]:
There are three pieces to all of this:
1. Generating debug symbols in the bi
Looks good.
Brad
On 3/18/2014 8:04 AM, Tim Bell wrote:
Hi Erik:
On 2014-03-18 11:42, Erik Joelsson wrote:
Please review this very simple fix to unzipping pre built security
classes. When building incrementally, unzip will go into interactive
mode and ask if it should overwrite files. The fi
- Original Message -
> On 3/17/14 7:19 PM, Andrew Hughes wrote:
> > - Original Message -
> >> On 3/3/14 2:49 PM, Omair Majid wrote:
> >>> * David Holmes [2014-02-28 18:48]:
> There are three pieces to all of this:
>
> 1. Generating debug symbols in the binaries (via
On 3/17/14 7:19 PM, Andrew Hughes wrote:
- Original Message -
On 3/3/14 2:49 PM, Omair Majid wrote:
* David Holmes [2014-02-28 18:48]:
There are three pieces to all of this:
1. Generating debug symbols in the binaries (via gcc -g or whatever)
2. Generating debuginfo files (zipped or
- Original Message -
> On 2014-03-18 02:19, Andrew Hughes wrote:
> > Do we need more than just the following three alternatives?
> >
> > #1. No debugging information at all.
> > #2. Debugging information left in the original binaries.
> > #3. Debugging information stripped from the binaries
On Tue, Mar 18, 2014 at 11:37 AM, Magnus Ihse Bursie
wrote:
> On 2014-03-14 17:55, Volker Simonis wrote:
>>
>> Hi Magnus,
>>
>> thanks for your detailed comments.
>>
>> I generally agree with your analysis of the problem.
>>
>> However, as you correctly noticed, the 'optimized' configuration is
>>
Erik,
We will need this fix backported to all 8uX releases as well as 9.. Thanks for
getting this done so quickly.
Thanks,
Gary
On Mar 18, 2014, at 4:29 AM, Erik Joelsson wrote:
> Hello,
>
> The file jdk/make/closed/javax/crypto/doc/README.txt is not available to
> licensees. The makefiles
Looks good.. This was one of our other possible fixes as well.
Gary
On Mar 18, 2014, at 4:29 AM, Erik Joelsson wrote:
> Hello,
>
> The file jdk/make/closed/javax/crypto/doc/README.txt is not available to
> licensees. The makefiles currently assumes it's always there as long as we
> build cryp
Hi Erik:
On 2014-03-18 12:29, Erik Joelsson wrote:
Hello,
The file jdk/make/closed/javax/crypto/doc/README.txt is not available
to licensees. The makefiles currently assumes it's always there as
long as we build crypto and it's not an OpenJDK build. This change
also checks that the file is
Hi Erik:
On 2014-03-18 11:42, Erik Joelsson wrote:
Please review this very simple fix to unzipping pre built security
classes. When building incrementally, unzip will go into interactive
mode and ask if it should overwrite files. The fix is to add -q -o to
the unzip line as is done on all oth
On 2014-03-18 12:29, Erik Joelsson wrote:
Hello,
The file jdk/make/closed/javax/crypto/doc/README.txt is not available
to licensees. The makefiles currently assumes it's always there as
long as we build crypto and it's not an OpenJDK build. This change
also checks that the file is actually in
Hello,
The file jdk/make/closed/javax/crypto/doc/README.txt is not available to
licensees. The makefiles currently assumes it's always there as long as
we build crypto and it's not an OpenJDK build. This change also checks
that the file is actually in the source too.
Bug: https://bugs.openjd
On 2014-03-18 11:42, Erik Joelsson wrote:
Please review this very simple fix to unzipping pre built security
classes. When building incrementally, unzip will go into interactive
mode and ask if it should overwrite files. The fix is to add -q -o to
the unzip line as is done on all other invocati
Please review this very simple fix to unzipping pre built security
classes. When building incrementally, unzip will go into interactive
mode and ask if it should overwrite files. The fix is to add -q -o to
the unzip line as is done on all other invocations of unzip.
Bug: https://bugs.openjdk.j
On 2014-03-14 17:55, Volker Simonis wrote:
Hi Magnus,
thanks for your detailed comments.
I generally agree with your analysis of the problem.
However, as you correctly noticed, the 'optimized' configuration is
actually a "HotSpot only" concept. It is used to enable extra
options/functionality
On 2014-03-18 10:58, Lindenmaier, Goetz wrote:
Hi,
it could be done with PPC64_ENDIANNESS check
Yes, that's fine. I would further propose to choose a neutral name ENDIANESS
and set it for all architectures. Platform specific variables should be
avoided in
shared files. And it's used in ppc
Hi,
> it could be done with PPC64_ENDIANNESS check
Yes, that's fine. I would further propose to choose a neutral name ENDIANESS
and set it for all architectures. Platform specific variables should be
avoided in
shared files. And it's used in ppc64.make, so that should be fine.
Also -DLITTLE_E
On 2014-03-18 02:19, Andrew Hughes wrote:
Do we need more than just the following three alternatives?
#1. No debugging information at all.
#2. Debugging information left in the original binaries.
#3. Debugging information stripped from the binaries and zipped in separate
files.
It sounds to me
18 matches
Mail list logo
