Hi Kumar,
I know it is a long time since you wrote this, but there have been
several changes to build-infra lately that might help with your issues.
We filter out the GNU link command. We try harder to locate VS10, and if
still not found, it can be set using "sh configure
--with-tools-dir=".
On 2012-07-10 16:23, Kumar Srinivasan wrote:
It looks like autoconf has messed up.
From the config.log
HOSTCC='C:/PROGRA~1/MSVS10/VC/BIN/cl.exe'
HOSTCXX='C:/PROGRA~1/MSVS10/VC/BIN/cl.exe'
HOSTLD='C:/devtools/cygwin/bin/link.exe'
It has picked cl.exe correctly, oopsie on link.exe.
You have
Hi all,
Forgot to send this in:
Ran on 10.7.2 OS X with latest Oracle JDK 7 binary as the
bootstrapper. All ran fine, ../autoconf/configure did not have
execute permissions though, so had to chmod u+x it. Not sure if that's
a manual step you want people to take or not.
A couple of errors which
A Windows tip:
* On Windows, I use:
make BUILD_LOG_WRAPPER= VERBOSE=
The logger tricks in the new makefiles seem to give Windows/CYGWIN grief,
not all the time
-kto
On Jul 9, 2012, at 3:12 PM, Kelly O'Hair wrote:
> The jdk8/build forest has been in sync for a
This isn't supposed to happen. At least it's the intention that
configure should avoid /usr/bin/link in favour of visual studio link.
VS10 in a different location is probably the reason for it.
What is the path to visual studio on this system? Is the environment
variable VS100COMNTOOLS to poin
after modifying the spec.gmk, the build is progressing.
Kumar
It looks like autoconf has messed up.
From the config.log
HOSTCC='C:/PROGRA~1/MSVS10/VC/BIN/cl.exe'
HOSTCXX='C:/PROGRA~1/MSVS10/VC/BIN/cl.exe'
HOSTLD='C:/devtools/cygwin/bin/link.exe'
It has picked cl.exe correctly, oopsie o
It looks like autoconf has messed up.
From the config.log
HOSTCC='C:/PROGRA~1/MSVS10/VC/BIN/cl.exe'
HOSTCXX='C:/PROGRA~1/MSVS10/VC/BIN/cl.exe'
HOSTLD='C:/devtools/cygwin/bin/link.exe'
It has picked cl.exe correctly, oopsie on link.exe.
Kumar
On 10/07/2012 10:59 AM, Kumar Srinivasan wrote:
The configure script does set a few variables in the spec.gmk file that is used
but the hotspot repo.
(It does read the spec.gmk file)
We did forget about STATIC_CXX though, it should be added to spec.gmk and set
appropriately,
then the hotspot makefile that looks at it should be adjusted, beca
Hi Kelly,
The full debug symbol support seems to have issues. In the old build we
use ENABLE_FULL_DEBUG_SYMBOLS in both the JDK and Hotspot. In the new
build we have ENABLE_DEBUG_SYMBOLS instead. This name difference means
hotspot and the JDK are using different "flags" to control the same
th
On 10/07/2012 11:05 AM, Omair Majid wrote:
On 07/09/2012 07:44 PM, David Holmes wrote:
Hi Omair,
The static vs dynamic link check that you see is only in place for the
JDK libraries not hotspot. For hotspot (which has not been modified as
part of the build-infra project) you still need to pass
On 07/09/2012 07:44 PM, David Holmes wrote:
> Hi Omair,
>
> The static vs dynamic link check that you see is only in place for the
> JDK libraries not hotspot. For hotspot (which has not been modified as
> part of the build-infra project) you still need to pass STATIC_CXX=false
> as a make variabl
On 10/07/2012 10:59 AM, Kumar Srinivasan wrote:
nOn 7/9/2012 5:20 PM, David Holmes wrote:
On 10/07/2012 9:51 AM, Kumar Srinivasan wrote:
On windows, I see a failure when building hotspot, as as follows.
Kumar
link.exe /SAFESEH /manifest kernel32.lib user32.lib gdi32.lib
winspool.lib codlg32.li
nOn 7/9/2012 5:20 PM, David Holmes wrote:
On 10/07/2012 9:51 AM, Kumar Srinivasan wrote:
On windows, I see a failure when building hotspot, as as follows.
Kumar
link.exe /SAFESEH /manifest kernel32.lib user32.lib gdi32.lib
winspool.lib codlg32.lib advapi32.lib shell32.lib ole32.lib
oleaut32.li
On 7/9/2012 5:20 PM, David Holmes wrote:
On 10/07/2012 9:51 AM, Kumar Srinivasan wrote:
On windows, I see a failure when building hotspot, as as follows.
Kumar
link.exe /SAFESEH /manifest kernel32.lib user32.lib gdi32.lib
winspool.lib codlg32.lib advapi32.lib shell32.lib ole32.lib
oleaut32.lib
On 10/07/2012 9:51 AM, Kumar Srinivasan wrote:
On windows, I see a failure when building hotspot, as as follows.
Kumar
link.exe /SAFESEH /manifest kernel32.lib user32.lib gdi32.lib
winspool.lib codlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib
uuid.lib
Wsock32.lib winmm.lib /nologo /m
On windows, I see a failure when building hotspot, as as follows.
Kumar
link.exe /SAFESEH /manifest kernel32.lib user32.lib gdi32.lib
winspool.lib co
dlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib
Wsock32.lib
winmm.lib /nologo /machine:I386 /opt:REF /opt:ICF,8 /map /debu
Hi Omair,
The static vs dynamic link check that you see is only in place for the
JDK libraries not hotspot. For hotspot (which has not been modified as
part of the build-infra project) you still need to pass STATIC_CXX=false
as a make variable on the make invocation.
David
-
On 10/07/20
Hi Kelly,
On 07/09/2012 06:12 PM, Kelly O'Hair wrote:
> The jdk8/build forest has been in sync for a few days, so anyone willing to
> try the new build system with OpenJDK 8, please
> follow these instructions:
>
> hg clone http://hg.openjdk.java.net/jdk8/build jdk8-build
> cd jdk8-bui
The jdk8/build forest has been in sync for a few days, so anyone willing to try
the new build system with OpenJDK 8, please
follow these instructions:
hg clone http://hg.openjdk.java.net/jdk8/build jdk8-build
cd jdk8-build
sh ./get_source.sh
cd common/makefiles
../autocon
19 matches
Mail list logo
