Glad to hear you got it working. Windows is the most difficult to
deal with.
Hopefully we can just get rid of these binary plugs soon, should make
life easier when that happens.
-kto
Scott Marlow wrote:
Yes, I have "set ALT_BINARY_PLUGS_PATH=c:/openjdk7_plugin"
My c:/openjdk7_plugin folder c
Yes, I have "set ALT_BINARY_PLUGS_PATH=c:/openjdk7_plugin"
My c:/openjdk7_plugin folder contains a subfolder called
"openjdk-binary-plugs". I'll try to set
ALT_BINARY_PLUGS_PATH=c:/openjdk7_plugin/openjdk-binary-plugs and build
again.
The build has been running for a while now, that definit
I assume you set this:
ALT_BINARY_PLUGS_PATH = c:/openjdk7_plugin
And that you got the binary plugs from:
http://download.java.net/openjdk/jdk7/
These binary plugs are the pieces that we haven't or can't open source yet.
In particular this *sound*dll file is a sound library you need.
-k
I switched to a new code drop and get the error below. Any suggestions?
/usr/bin/cp ../../../src/share/javavm/export/classfile_constants.h
c:/tmp/openjdk-build/include/classfile_constants.h
make[4]: Leaving directory `/openjdk7/openjdk/jdk/make/java/jvm'
Timing: 2 seconds or 2s for make-
If you are building with Visual Studio, it needs to be in your PATH
and it needs to pretty much be first in your PATH.
The Visual Studio tools expect to find their components via the PATH,
they won't look in their installed HOME location, they use PATH.
Most compilers figure out where HOME is and
It seems that this is mainly a problem in the hotspot part of the build. Other parts call link and cl with absolut
paths. To me this looks like the right solution also for the hotspot part.
Fiddling with PATH might lead to other problems and conflicts.
Ingo
Kelly O'Hair wrote:
Max is correct.
Max is correct.
Normally you should put the compiler paths before /usr/bin in your PATH
variable.
I'm not sure how safe it is to modify the cygwin installation.
I have bug 6724787, and I will clarify this cygwin link.exe PATH issue in the
OpenJDK Build readme soon.
http://hg.openjdk.java.net/jd
Thanks. That works for me too.
Ingo
Max (Weijun) Wang wrote:
This is a conflict between link.exe of CYGWIN and MSVC.
The formal process seems to suggest that you define environment
variables to inform make to locate the correct find.exe (the MSVC one).
I haven't tried it. I simply rename the
This is a conflict between link.exe of CYGWIN and MSVC.
The formal process seems to suggest that you define environment
variables to inform make to locate the correct find.exe (the MSVC
one). I haven't tried it. I simply rename the link.exe in CYGWIN to
something else.
-Max
On Jul 22, 20
Thanks that helped.
Until I got here:
link.exe bufferoverflowU.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib
ole32.lib oleaut32.lib uuid.lib Wsock32.lib winmm.lib /nologo /machine:I386 /opt:REF /opt:ICF,8 /map /debug
/subsystem:console /out:adlc.e
The file is moved to somewhere else. Please apply this patch:
diff --git a/make/windows/makefiles/defs.make b/make/windows/
makefiles/defs.make
--- a/make/windows/makefiles/defs.make
+++ b/make/windows/makefiles/defs.make
@@ -107,7 +107,7 @@
ABS_OUTPUTDIR := $(subst /,\\,$(shell /bin/cygpa
11 matches
Mail list logo
