I am trying to compile an OpenMP code, on Windows. The linker options /stack:10000000 and /largeaddressaware are meant to be added, to avoid stack overflow errors. They are not recognised.
I think /largeaddressaware might be unnecessary as I am using a 64 bit compiler. But I do need to make /stack work.
I am using the "Intel oneAPI command prompt for Intel 64 for Visual Studio 2022" and Intel Fortran to compile. It's not clear to me how the /stack flag is meant to be added, but here is what I tried:
ifort -c modules.f90
ifort -c MainCode.f90 /openmp /STACK:10000000 /LARGEADDRESSAWARE
ifort modules.obj MainCode.obj -o Code.exe /openmp /STACK:10000000 /LARGEADDRESSAWARE
What I get is,
C:\Users\e\Desktop\code>ifort -c modules.f90
Intel(R) Fortran Intel(R) 64 Compiler Classic for applications running on Intel(R) 64, Version 2021.6.0 Build 20220226_000000
Copyright (C) 1985-2022 Intel Corporation. All rights reserved.
C:\Users\e\Desktop\code>ifort -c MainCode.f90 /openmp /STACK:10000000 /LARGEADDRESSAWARE
Intel(R) Fortran Intel(R) 64 Compiler Classic for applications running on Intel(R) 64, Version 2021.6.0 Build 20220226_000000
Copyright (C) 1985-2022 Intel Corporation. All rights reserved.
ifort: command line warning #10006: ignoring unknown option '/STACK:10000000'
ifort: command line warning #10006: ignoring unknown option '/LARGEADDRESSAWARE'
C:\Users\e\Desktop\code>ifort modules.obj MainCode.obj -o Code.exe /openmp /STACK:10000000 /LARGEADDRESSAWARE
Intel(R) Fortran Intel(R) 64 Compiler Classic for applications running on Intel(R) 64, Version 2021.6.0 Build 20220226_000000
Copyright (C) 1985-2022 Intel Corporation. All rights reserved.
ifort: command line warning #10006: ignoring unknown option '/STACK:10000000'
ifort: command line warning #10006: ignoring unknown option '/LARGEADDRESSAWARE'
Microsoft (R) Incremental Linker Version 14.33.31629.0
Copyright (C) Microsoft Corporation. All rights reserved.
-out:Code.exe
-subsystem:console
-defaultlib:libiomp5md.lib
-nodefaultlib:vcomp.lib
-nodefaultlib:vcompd.lib
modules.obj
MainCode.obj
Is there another command I could be using instead? Or am I using /stack wrong?
I tried both capital /STACK and lower case /stack. Neither worked. I also tried -large-address-aware as I had found that somewhere, but that didn't work either. I tried /stack 10000000 too with no luck.
You must put /link (lowercase) on the line before linker options such as /stack and /largeaddressaware. This tells the compiler driver to pass them on to the linker.
There is a downside to setting a very large stack reserve value in that this reduces the 2GB Windows allocates for static code and data, plus some that Windows itself uses. This limit also applies to 64-bit Windows! Rather than start with an insanely large value, start at something like 1000000 and go up from there.
Related
I installed Rust on a Windows 10 machine with rustup-init.exe - the method recommended in the Rust Book. The installer told me that Rust needs C-runtime of VS2013 or newer. I have VS2017 installed, I assumed Rust doesn't support VS2017 yet and so agreed to install C-runtime. Installation finished successfully.
main.rs:
fn main() {
println!("Hello, world!");
}
Compiling:
> rustc main.rs
error: linking with `link.exe` failed: exit code: 1
|
= note: "link.exe" "/NOLOGO" "/NXCOMPAT" "/LIBPATH:C:\\Users\\***\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib" "main.0.o" "/OUT:main.exe" "/OPT:REF,NOICF" "/DEBUG" "/LIBPATH:C:\\Users\\***\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib" "C:\\Users\\***\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libstd-0a78323911070f99.rlib" "C:\\Users\\***\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\librand-c279a51d66700350.rlib" "C:\\Users\\***\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libcollections-d7bf31a4ca1ea637.rlib" "C:\\Users\\***\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libstd_unicode-d367c3ba0db49600.rlib" "C:\\Users\\***\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libpanic_unwind-2d4bf02140c11dcb.rlib" "C:\\Users\\***\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libunwind-add7a84d7e82d084.rlib" "C:\\Users\\***\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\liblibc-84688accbc86d6b7.rlib" "C:\\Users\\***\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\liballoc-fe2e68b21f0bdd7a.rlib" "C:\\Users\\***\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\liballoc_system-7fc0381594c93f56.rlib" "C:\\Users\\***\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libcore-ea9d77e7c23fe65c.rlib" "C:\\Users\\***\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libcompiler_builtins-91b619d34dd1f5aa.rlib" "advapi32.lib" "ws2_32.lib" "userenv.lib" "shell32.lib" "msvcrt.lib"
= note: /usr/bin/link: extra operand '/LIBPATH:C:\\Users\\***\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib'
Try '/usr/bin/link --help' for more information.
error: aborting due to previous error
link.exe LIBPATH arg is specified twice.
What's going on?
> rustc --version
rustc 1.17.0 (56124baa9 2017-04-24)
As the rustup documentation says:
As mentioned on the Rust download page, there are two ABIs in use on Windows: the native (MSVC) ABI used by Visual Studio, and the GNU ABI used by the GCC toolchain. Which version of Rust you need depends largely on what C/C++ libraries you want to interoperate with: for interop with software produced by Visual Studio use the MSVC build of Rust; for interop with GNU software built using the MinGW/MSYS2 toolchain use the GNU build.
You have installed the MSVC toolchain. However, you are running the the compiler in a command shell where link.exe does not point to the MSVC linker, but instead to a GNU toolchain — MSVC does not call its linker /usr/bin/link or use options like --help!
You should configure your shell so the MSVC linker is foremost in the PATH or switch to the GNU ABI if that's your goal.
Compare the help output of the two:
$ link --help
Usage: link FILE1 FILE2
or: link OPTION
Call the link function to create a link named FILE2 to an existing FILE1.
--help display this help and exit
--version output version information and exit
GNU coreutils online help: <http://www.gnu.org/software/coreutils/>
Full documentation at: <http://www.gnu.org/software/coreutils/link>
or available locally via: info '(coreutils) link invocation'
> link /help
Microsoft (R) Incremental Linker Version 14.10.25017.0
Copyright (C) Microsoft Corporation. All rights reserved.
For help on Linker, type `link /link' or `link'
For help on Library Manager, type `link /lib' or `lib'
For help on Dumper, type `link /dump' or `dumpbin'
For help on Editor, type `link /edit' or `editbin'
For help on CvtCIL, type `link /cvtcil'
I assumed Rust doesn't support VS2017 yet
It supports VS2017 just fine; as described in the 1.17 release notes, the problem is that it cannot automatically find the MSVC installation due to changes in where MSVC installs. Running the Rust compiler from inside a shell that has the proper environment works fine.
I'm using Visual Studio C++ Preprocessor to preprocess some files which are not C or C++ files (I find it very convenient).
Recently I upgraded from Visual Studio 2010 to 2015 and found out that the preprocessor behavior slightly changed. Some text that works on VS2010 gives an error on VS2015 and vice versa.
To illustrate the difference, here are two one liner files, ok2010.c and ok2015.c, and the preprocessing command line running with VS2010 and VS2015:
ok2010.c:
#define X `0'`'
ok2015.c:
#define X `0'`'`'
Preprocessing on VS2010:
c:\>cl -E ok2010.c
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.40219.01 for 80x86
Copyright (C) Microsoft Corporation. All rights reserved.
ok2010.c
#line 1 "ok2010.c"
c:\>cl -E ok2015.c
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.40219.01 for 80x86
Copyright (C) Microsoft Corporation. All rights reserved.
ok2015.c
#line 1 "ok2015.c"
ok2015.c(1) : error C2001: newline in constant
Preprocessing on VS2015:
c:\>cl -E ok2010.c
Microsoft (R) C/C++ Optimizing Compiler Version 19.00.23506 for x86
Copyright (C) Microsoft Corporation. All rights reserved.
ok2010.c
#line 1 "ok2010.c"
ok2010.c(1): error C2001: newline in constant
c:\>cl -E ok2015.c
Microsoft (R) C/C++ Optimizing Compiler Version 19.00.23506 for x86
Copyright (C) Microsoft Corporation. All rights reserved.
ok2015.c
#line 1 "ok2015.c"
I guess that the preprocessor handles differently tick (') and backtick (`), and expects them to be balanced. When they are not balanced it reports a newline in a quoted constant expression.
VS2010 ignores backtick entirely and expects only the ticks to be balanced, so this behavior makes sense.
However, I can't make sense of VS2015 behavior since it works only when both ticks and backticks are not balanced...
Any idea?
I have a host system and a virtual machine and i am trying to setup similar environment in both.
I installed cygwin and visual studio 10 also.
I faced issues in my build and I finally managed to find one difference between my host and vm.
in my host when in cygwin shell when i enter cl I get the following:
$ cl
Microsoft (R) C/C++ Optimizing Compiler Version 16.00.40219.01 for x64
Copyright (C) Microsoft Corporation. All rights reserved.
usage: cl [ option... ] filename... [ /link linkoption... ]
But in my vm I am getting no output.
$ cl
(VM is 32 bit and host is 64 bit)
Can someone tell me what setting I might have missed out on?
First thing you should do is to find out what cl is within the CygWin where it's not working. Execute the commands:
typeset -f cl
which cl
alias cl
and find out what it comes back with. If it's anything other than the MS compiler, that's your problem.
Beyond that, find out what the erroneous environment does when you try to run cl from a cmd window rather than CygWin bash.
Based on your comment:
On my VM, it is: $ which cl /cygdrive/c/Program Files/Microsoft Visual Studio 10.0/VC/bin/x86_amd64/cl
This is definitely wrong for a 32-bit VM. You are attempting to use the 64-bit AMD compiler on a system that doesn't support it.
You should change the path to use a 32-bit compiler. However, I'm not sure you have one since all of amd64, ia64, x86_amd64 and x86_ia64 seem to indicate 64-bit compilers.
The one directly under bin may be okay, you would have to test it to be certain (possibly with dumpbin which should be able to tell you the file format of the executable).
since one week I'm trying to compile a demo Version of the JVMTI demo set. In this case I tried to compile the HeapViewer Source Code (I just renamed the file HeapViewer.c to HeapViewerByMG). I tried different compiler and used mainly the following code that I found on stackOverflow,too:
// compile with Microsoft Windows C++ compiler
set JAVA_HOME="C:\Program Files\Java\jdk1.6.0_26"
set JVMTI_DEMO=%JAVA_HOME%\demo\jvmti
set AGENT_SRC=%JVMTI_DEMO%\agent_util\src
set CRW_SRC=%JVMTI_DEMO%\java_crw_demo\src
set CFLAGS=/MD /Zi /Ox /Os /Gy /c
cl %CFLAGS% /I%AGENT_SRC% %AGENT_SRC%\agent_util.c /I%CRW_SRC% /I%JAVA_HOME%\include /I%JAVA_HOME%\include\win32
cl %CFLAGS% /I%CRW_SRC% /I%JAVA_HOME%\include /I%JAVA_HOME%\include\win32 %CRW_SRC%\java_crw_demo.c
cl %CFLAGS% /I%AGENT_UTIL% /I%CRW_SRC% /I%JAVA_HOME%\include /I%AGENT_SRC% /I%JAVA_HOME%\include\win32 heapViewerByMG.c
link -dll -out:heapViewerByMG.dll heapViewerByMG.obj java_crw_demo.obj agent_util.obj
// compile with g++ compiler von MINGW
set JAVA_HOME="C:\Program Files\Java\jdk1.6.0_26"
set JVMTI_DEMO=%JAVA_HOME%\demo\jvmti
set AGENT_SRC=%JVMTI_DEMO%\agent_util\src
set CRW_SRC=%JVMTI_DEMO%\java_crw_demo\src
gcc -c -I%AGENT_SRC% %AGENT_SRC%\agent_util.c -I%CRW_SRC% -I%JAVA_HOME%\include -I%JAVA_HOME%\include\win32
gcc -c -I%CRW_SRC% -I%JAVA_HOME%\include -I%JAVA_HOME%\include\win32 %CRW_SRC%\java_crw_demo.c
gcc -c -o heapViewerByMG.dll -I%AGENT_UTIL% -I%AGENT_SRC% -I%CRW_SRC% -I%JAVA_HOME%\include -I%JAVA_HOME%\include\win32 heapViewerByMG.c
My code compiles successful in both cases, but when I try to use the dll files, I will get following error:
"The application or DLL
(...)\heapViewerByMG.dll is not a valid
Windows image. Please check this
against your installation diskette."
I also looked up what this message means. The research told me, that this is then a corrupt file, but I can rule this out since I compiled a given source code by the JVM. Anyhow I believe it is just another option command that I need to let run the file successful. Does anyone of you have an idea?
Here are some details of my system:
C:\>java -version
java version "1.6.0_26"
Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
Java HotSpot(TM) Client VM (build 20.1-b02, mixed mode, sharing)
C:\>gcc --version gcc (GCC) 4.5.2 Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
C:\>cl -version
Microsoft (R) C/C++ Optimizing Compiler Version 14.00.50727.762 for x64
Copyright (C) Microsoft Corporation. All rights reserved.
Or after I changed the Microsoft Compiler from 64bit to 32bit (because this was one of the older error messages, when I started the agent)
C:\>VCVARS32
C:\>"C:\Program Files\Microsoft Visual Studio 8\Common7\Tools\vsvars32.bat"
Setting environment for using Microsoft Visual Studio 2005 x86 tools.
C:\>cl -version
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.762 for 80x86
Copyright (C) Microsoft Corporation. All rights reserved.
And I'm running a Microsoft Windows XP Professional Version 2002 Service Pack 3 on a Intel(R) 4 CPU 2.80GHz with 2.00 GB of RAM
Sorry for that system. Usually I'm using a MacBook Pro 2010 (2.8GHz Intel Core i7), but I figured out that MacOS doesn't have included the support of the JVMTI demo-version :(
I hope somebody can help me.
Greetings
Markus G.
I don't know where the difference to upper version is, but this command-lines creates an agent that runs well (on upper mentioned system), if you copy the dll-file into the library (..JAVA_HOME\JRE\BIN):
VCVARS32
cd C:\Program Files\Java\jdk1.6.0_26\demo\jvmti\heapViewerByMG\src
set JAVA_HOME="C:\Program Files\Java\jdk1.6.0_26"
set JVMTI_DEMO=%JAVA_HOME%\demo\jvmti
set AGENT_SRC=%JVMTI_DEMO%\agent_util\src
set CRW_SRC=%JVMTI_DEMO%\java_crw_demo\src
set CFLAGS= /Op /Ox /Zi /Gy -DWIN32 /WX
cl %CFLAGS% /I%AGENT_SRC% %AGENT_SRC%\agent_util.c /I%CRW_SRC% /I%JAVA_HOME%\include /I%JAVA_HOME%\include\win32
cl %CFLAGS% /I%CRW_SRC% /I%JAVA_HOME%\include /I%JAVA_HOME%\include\win32 %CRW_SRC%\java_crw_demo.c
cl %CFLAGS% /I%AGENT_UTIL% /I%CRW_SRC% /I%JAVA_HOME%\include /I%AGENT_SRC% /I%JAVA_HOME%\include\win32 heapViewerByMG.c
link -dll -out:heapViewerByMG.dll heapViewerByMG.obj java_crw_demo.obj agent_util.obj
Now,copy the DLL File into upper mentioned directory and use following command line to run the test:
C:\Program Files\Java\jdk1.6.0_26\demo\jvmti\heapViewerByMG\src>java -agentlib:h
eapViewerByMG -version
Compile Time JVMTI Version: 1.1.102 (0x30010166)
Run Time JVMTI Version: 1.2.1 (0x30010201)
java version "1.6.0_26"
Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
Java HotSpot(TM) Client VM (build 20.1-b02, mixed mode, sharing)
Anyhow, I still don't know, why this didn't work earlier ...
Markus G.
From this link: http://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html
-dH Produce a core dump whenever an error occurs.
So, I compiled a program with a syntax error and the core file was generated. How can that core file be used now? GDB can't be invoked since any executable has not been generated, yet.
[11:11:12 Wed Apr 27]
~/junk1 $ls
core hell.c
[11:11:15 Wed Apr 27]
~/junk1 $gcc -g hell.c -dH
hell.c: In function ‘main’:
hell.c:4: error: expected ‘;’ before ‘}’ token
gcc: Internal error: Aborted (program cc1)
Please submit a full bug report.
See <http://bugs.opensuse.org/> for instructions.
[11:11:36 Wed Apr 27]
~/junk1 $ls
core hell.c
[11:12:09 Wed Apr 27]
~/junk1 $gdb cc1 core
GNU gdb (GDB) SUSE (6.8.91.20090930-2.4)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-suse-linux".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
***cc1: No such file or directory.***
Missing separate debuginfo for the main executable file
Try: zypper install -C "debuginfo(build-id)=41f1efcceccfa5fa0b3476021c731c489547f86e"
Core was generated by `/usr/lib64/gcc/x86_64-suse-linux/4.4/cc1 -quiet hell.c -quiet -dumpbase hell.c'.
Program terminated with signal 6, Aborted.
#0 0x00007fb1b01654e5 in ?? ()
(gdb)
The GDB says: cc1: No such file or directory, in the above output.
How I am supposed to use that core file?
I think that switch is to help debug gcc, not your program. The page you link to starts like this:
3.9 Options for Debugging Your Program or GCC
GCC has various special options that are used for debugging either your program or GCC:
Emphasis mine.
The cc1 program is an internal part of GCC, it is probably somewhere under /usr/lib/ or /usr/libexec/.
gdb -c corefile should work. I haven't had to use the -dH option, so not sure how useful it is in helping with debugging.