this help you? In those cases where you want an open Makefile to refer
> to code in Twitter's internal src/closed directory aren't you still
> going to have to create and maintain your own patches to the open
> Makefile?
>
> Just trying to understand the problem here ...
>
> - Mark
>
--
[image: twitter-icon-large.png]
Keith McGuigan
@kamggg
kmcgui...@twitter.com
On Wed, Apr 23, 2014 at 8:51 PM, David Holmes wrote:
> On 23/04/2014 9:23 PM, Keith McGuigan wrote:
>
>> Yes, I did consider using some ifeq tricks like that -- but they are
>> rather ugly and unreadable and have the same problem that you want to
>> avoid: adding distrib
ORACLE_JDK, so
>> introducing a third variation doesn't really fit.
>>
>> Can you give a concrete example of something that highlights this
>> problem for you and how your proposal addresses it? I may get a
>> better sense of things with specifi
e of
> things with specifics rather than trying to generalize - because I don't
> see a general solution without a lot of refactoring.
>
> Thanks,
> David
>
>
> On 22/04/2014 2:42 PM, Keith McGuigan wrote:
>
>> Hi Mark, et al.,
>>
>> The sad realit
Hi Mark, et al.,
The sad reality of the situation is that there is indeed Oracle-specific
code in the OpenJDK makefiles, and this code interferes with our
customization of the JDK. Adding temporary signposts to allow us (and
others) to avoid this code will not make things worse. It doesn't have
On Thu, Apr 17, 2014 at 12:52 AM, David Holmes wrote:
> Hi Keith,
>
> src/closed is Oracle's "custom source" location (hotspot calls it
> alt_src). If we never saw src/closed in the makefiles, only CUSTOM_SRC_DIR,
> and guarded with an existence test for a specific directory/file, then that
> shou
thing
>> currently flagged for OPENJDK really means !ORACLE_JDK - or does it? It
>> actually depends on what sources a given licensee has. Even for your custom
>> build you might want some OPENJDK items and not others. I'm not sure there
>> is a general solution, bu
o VS2012 format by the IDE.
>
> Tests:
>
> I built X64 and X86 VMs inside VS2012 and ran Eclipse.
> JPRT
>
> Thanks
> - Ioi
>
>
--
- Keith McGuigan
behavior
for -MD vs -M. The only reason behind -MD and -MMD is that it "..can
be used to generate a dependency output file as a side-effect of the
compilation process" (from the GCC man page) - but that doesn't seem
to work..
Does anybody has an explanation for this behavior?
Regards,
I don't understand why gcc doesn't put frame_x86.inline.hpp into the
generated/dependencies/frame.o.d file. Isn't the point of -MMD to
calculate the full closer of header files used for listing as a
dependency? Is this a bug in gcc or are we using it wrong?
I notice that Sun Studio compile
Hi Dan,
I think it looks good. The new form of the 'find' commands in Release.gmk could
use a comment, though. It took me a few minutes to realize that EXE_SUFFIX was
empty for linux/solaris -- it looks like there's a redundancy in the logic (both
NOT name *.debuginfo AND name *.exe). I s
On 2/2/2012 9:01 PM, David Holmes wrote:
On 3/02/2012 9:56 AM, Keith McGuigan wrote:
Here's a webrev for changing the default JPRT release value for hotspot
to jdk8. It can still be overridden by the -release jdk7 during JPRT
submission. I also removed references to pre-7 releases and
Hello,
Here's a webrev for changing the default JPRT release value for hotspot
to jdk8. It can still be overridden by the -release jdk7 during JPRT
submission. I also removed references to pre-7 releases and other
unused value (jdk7b107, jdk7temp).
The targets and parameters for jdk7 & jdk
Didn't Dan Dougherty review this too? Is he a "reviewer" for this
project? If it helps you can put me down as a reviewer (kamg).
On Nov 2, 2011, at 2:54 PM, Neil Richards wrote:
On Wed, 2011-11-02 at 14:07 -0400, Zhengyu Gu wrote:
Hi Neil,
My understanding is that you need to have at le
8 Jul , Keith McGuigan wrote:
Ok, thanks. Code looks good to me then.
Ok, can I push this or do you still need to do this via JPRT?
Either way, I need a bug ID please.
--
- Keith
On Jul 28, 2011, at 9:02 AM, Mark Wielaard wrote:
On Thu, 2011-07-28 at 08:32 -0400, Keith McGuigan wrote:
This ap
On Jul 28, 2011, at 9:54 AM, Dr Andrew John Hughes wrote:
On 09:17 Thu 28 Jul , Keith McGuigan wrote:
Ok, thanks. Code looks good to me then.
Ok, can I push this or do you still need to do this via JPRT?
Either way, I need a bug ID please.
Yes, this will need to be pushed via JPRT
Ok, thanks. Code looks good to me then.
--
- Keith
On Jul 28, 2011, at 9:02 AM, Mark Wielaard wrote:
On Thu, 2011-07-28 at 08:32 -0400, Keith McGuigan wrote:
This appears to remove support for version 2.7. Is that intentional?
There has never been a 2.7 kernel.
2.6.39.3 is the last
This appears to remove support for version 2.7. Is that intentional?
--
- Keith
On Jul 27, 2011, at 9:57 PM, Dr Andrew John Hughes wrote:
Linux 3.0 was released last week:
https://lwn.net/Articles/452531/
This webrev:
http://cr.openjdk.java.net/~andrew/pr748/
fixes the check in the HotSp
While the code is fine and I won't complain if you push it as is, I
don't like the idea that we "disable" the altsrc mechanism when
building OPENJDK. The idea of alternate sources is that distributions
ought to be able to define their own distribution-specific code.
OPENJDK could well h
On May 3, 2011, at 4:26 PM, Fredrik Öhrström wrote:
No doubt it's been useful, but seriously, you just built a hotspot
for jdk7, with a completely
different
C++ compiler, and a different C++ runtime dependency, and you plop
it down into a jdk6 image (that
was built with a different C++ comp
On May 3, 2011, at 12:05 PM, Kelly O'Hair wrote:
I was going to say that building hotspot does NOT require a Boot JDK
to build, but I would be wrong, it does,
but I agree, it probably should not. As I recall, there is some XML
processing, the stupid gamma launcher Queens use,
Whoops... lit
On Apr 29, 2011, at 1:47 PM, John Coomes wrote:
David Holmes (david.hol...@oracle.com) wrote:
http://cr.openjdk.java.net/~dholmes/7036525/webrev/
Simple but crude. If OPENJDK is defined then the Hotspot "alternative
source" mechanism is effectively disabled by checking for a non-
existent
p
Changeset: 176586cd040e
Author:kamg
Date: 2010-09-13 13:10 -0400
URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/176586cd040e
6983225: libjvm_db.so is not imported into solaris-x86 builds, and
libjvm_dtrace.so not imported at all.
Summary: Removed sparc-only libjvm_db code and a
Hello,
I'd like a code review for this change which imports the libjvm_db.so
and libjvm_dtrace.so files from Hotspot into the solaris JDK images
(libjvm_dtrace was missing, and libjvm_db was missing for x86).
http://cr.openjdk.java.net/~kamg/6983225/webrev.00/
Thanks!
--
- Keith
Kelly O'Hair wrote:
For Linux and Solaris I could see such a thing, even with all the
different Linux variations. But Windows... :^(
You could restrict it to Windows&CYGWIN and starting from a cygwin shell,
but I suspect that would not be satisfying all the Windows users.
There are Windows&MKS an
How about a 'configure' step, which can perform a lot of the
system-specific probing. Not sure we need to jump all the way into
automake or autoconf (but if we did, there's a lot of existing code out
there we could use). But a 'configure; make; make install' sequence is
a very familiar conc
Feng-
As others have said, make sure you have the right sources. If this
happens again, though, you may have to do some debugging in the build.
The referenced symbol ought to be defined in the verifier.o file.
Either it's not defined in there, or that file is not getting linked
into libjvm
27 matches
Mail list logo
