May I ask a question about the CC compiler in Solaris environment.
I try to compile a Solaris release library with "-O" using Solaris CC compiler. I can compile the debug library previously using "-g".
However, when I change the "-g" to "-O", after some time, the compilation stop without any error. There is no output however.
I am thinking it is related to memory. So I try to compile a very simple cpp using -O flag. This time, the output is there.
May I know if any one has any idea on it? If it is a memory issue, can we use some commend or compile flag to solve it? Maybe increase the virtual memory assigned to CC?
Thanks,
You could increase virtual memory by making a swapfile:
mkswap 4096M /where/you/want/your/swapfile
swap -a /where/you/want/your/swapfile
Alternatively, you can run your truss your compilation to see exactly what's going on:
truss -f <build command>
Related
Most of my team uses a .bat file to set paths and then run a build. The .bat file allows selection of multiple different compiler/target platforms, but all use some version of GCC/G++ or similar compiler.
I created an Eclipse project that simply uses the .bat file rather than re-inventing the wheel and tracking down all the paths needed for each build (which I'd need to update if anyone ever updated the .bat file anyway).
This works great for building, and I can even see compiler errors/warnings, but there are some extra errors always present:
Program "gcc" not found in PATH
Program "g++" not found in PATH
I've seen many questions about these and similar errors, but in those case the user couldn't build, and the solution was to install the tools and/or update their PATH or Eclipse environment settings. I don't want to do that; all the tools I need are installed, and the .bat file works just fine to set the PATH for building. Is there a way to suppress these errors, or have Eclipse not try to find the compiler executable, since the build succeeds anyway?
Edit: As suggested in the answer I've received so far, here is output on the console after putting a full path to a compiler in the global discovery settings, which isn't exactly my favorite solution even if it worked, but I'll probably deal with it. Regardless the errors don't go away:
15:27:24 **** Running scanner discovery: CDT GCC Built-in Compiler Settings MinGW ****
"C:\\redacted\\localapps\\MinGW5\\bin\\g++.exe" -E -P -v -dD C:/Project_Files/redacted/code_workspaces/redacted/.metadata/.plugins/org.eclipse.cdt.managedbuilder.core/spec.C
Reading specs from C:/redacted/localapps/MinGW5/bin/../lib/gcc/mingw32/3.4.2/specs
Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as --host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls --enable-languages=c,c++,f77,ada,objc,java --disable-win32-registry --disable-shared --enable-sjlj-exceptions --enable-libgcj --disable-java-awt --without-x --enable-java-gc=boehm --disable-libgcj-debug --enable-interpreter --enable-hash-synchronization --enable-libstdcxx-debug
Thread model: win32
gcc version 3.4.2 (mingw-special)
C:/redacted/localapps/MinGW5/bin/../libexec/gcc/mingw32/3.4.2/cc1plus.exe -E -quiet -v -P -iprefix C:\redacted\localapps\MinGW5\bin\../lib/gcc/mingw32/3.4.2/ C:/Project_Files/redacted/code_workspaces/redacted/.metadata/.plugins/org.eclipse.cdt.managedbuilder.core/spec.C -dD
ignoring nonexistent directory "C:/redacted/localapps/MinGW5/bin/../lib/gcc/mingw32/3.4.2/../../../../mingw32/include"
#define __cplusplus 1
ignoring nonexistent directory "/mingw/lib/gcc/mingw32/../../../include/c++/3.4.2"
#define __STDC_HOSTED__ 1
ignoring nonexistent directory "/mingw/lib/gcc/mingw32/../../../include/c++/3.4.2/mingw32"
#define __GNUC__ 3
ignoring nonexistent directory "/mingw/lib/gcc/mingw32/../../../include/c++/3.4.2/backward"
...
And then a bunch of #defines
The command string I used in the discovery options for this output was C:\redacted\localapps\MinGW5\bin\${COMMAND}.exe ${FLAGS} -E -P -v -dD "${INPUTS}".
Based on the information provided, these errors are coming from the scanner discovery part of CDT.
On my machine the full error looks like this:
Description Location Type
Program "g++" not found in PATH Preferences, C++/Build/Settings/Discovery, [CDT GCC Built-in Compiler Settings MinGW] options C/C++ Scanner Discovery Problem
Program "gcc" not found in PATH Preferences, C++/Build/Settings/Discovery, [CDT GCC Built-in Compiler Settings MinGW] options C/C++ Scanner Discovery Problem
Or as a screenshot
What is going on here is Eclipse CDT is (attempting to) launch GCC and G++ to find out what the global settings are for things like include paths, etc.
To fix the problem, go to the Location specified in the error message and adjust the scanner settings. Here is the matching setting to go with the specific error I received.
Your error might be in the project or in the global settings.
To update the MinGW setting, you can provide the path to a batch file that looks like GCC/G++ but sets up your environment correctly first, or you can point directly at the GCC that Eclipse CDT did not find on its own.
For example you can have:
D:\path\to\my\compilers\${COMMAND}.exe ${FLAGS} -E -P -v -dD "${INPUTS}"
As the setting instead of the default.
To aid the debugging, check the Allocate console in the Console View to see exactly what is being run and what output is being generated.
And here is what you might see when it does not work. Hopefully the error messages in the console are sufficient to resolve the problem on your machine.
21:12:54 **** Running scanner discovery: CDT GCC Built-in Compiler Settings MinGW ****
"D:\\path\\to\\my\\compilers\\g++.exe" -E -P -v -dD C:/Temp/workspace/.metadata/.plugins/org.eclipse.cdt.managedbuilder.core/spec.C
Cannot run program "D:\path\to\my\compilers\g++.exe": Launching failed
Error: Program "D:\path\to\my\compilers\g++.exe" not found in PATH
PATH=[\bin;\bin; -- snip --]
21:12:54 Build Finished (took 37ms)
Here is a screenshot to match:
If it does work, you should see lots of #defines and the like showing the global state of your compiler.
If I run the below script (saved as jarAccessTest.sh, which is an executable file) in a command line, nothing happens:
#!/bin/sh
# exec scala -classpath "/usr/local/google/home/vvasuki/sanskritnlpjava/target/sanskritnlp-1.0-SNAPSHOT.jar " "$0" "$#"
exec scala "$0" "$#"
!#
# import sanskritnlp.transliteration._;
print "hello"
I just see no output. Nothing. Command prompt does not return either.
What is happening here? I have to type Ctrl+C to stop whatever is happening.
EDIT: Using scala 2.9 in ubuntu 14.04 : http://i.imgur.com/VMYKnUX.png
Your pre-packaged version of Scala is from a long time ago and a galaxy far, far away.
You'll do better to download the latest 2.11.6 from the website.
When the scala runner runs a script, it starts a compile server process. If that process is borked, you may have to kill it or run fsc -shutdown to ask it nicely to go away.
You can try adding the -nc option to your script to eliminate that factor, i.e., scala -nc says no compile daemon.
Finally, if you're just testing your library, it's more common to run scala -cp my.jar and experiment from the REPL. Or if you are using SBT, start the console from there.
Anonymous suggests adding: "They seriously let you type anything on here"
To which I'll append the advice from the other answer, to run fsc -verbose. And note that they threaten to stop supporting fsc because it has issues which are maddening when they occur. For that reason, I prefer scala -nc for brief testing and scalac -d script.jar script.scala where script is an App.
The problem on the original computer was never really explained, though it is pointed out that use of the '-nc' flag worked.
The original problem might with the compilation daemon's ability to open a port. From the man page for fsc:
The first time it is executed, the daemon is started automatically.
On subsequent runs, the same daemon can be reused, thus resulting in a faster compilation. The tool is especially effective when repeatedly
compiling with the same class paths, because the
compilation daemon can reuse a compiler instance.
One way to check if this is the problem is to run fsc on its own with the verbose flag. For example, make a script called hello.scala with
println("Hello")
in it, and run
fsc -verbose hello.scala
If this shows the compile server unable to connect, you've identified your problem. A first thing to try in that case would be to check that your hosts file is kosher.
(I had a similar problem, and this is what I found).
you have a few changes to do on your code, mainly on the # line which is not a comment in scala.
#!/bin/sh
# exec scala -classpath "/usr/local/google/home/vvasuki/sanskritnlpjava/target/sanskritnlp-1.0- SNAPSHOT.jar " "$0" "$#"
exec scala "$0" "$#"
!#
// import sanskritnlp.transliteration._;
print ("hello\n")
I recently followed the instruction on this thread for compiling BLAS and LAPACK as pre-requisites to a SciPy installation. First I got a gfortran error at some point, which recommended that I re-compile LAPACK with -fPIC. So I did this by replacing the -frecursive with -fPIC in makefile.inc (which, I assume is some file the Makefile reads for different compile options) and the error was gone.
Can someone explain more generally what the difference is in compiling something with -fPIC and -frecursive, and how it helped fix the error in my case.
Thanks!
As Soren already commented: -fPIC is totally unrelated to -frecursive. PIC influences how machine code can be positioned inside memory. If you want to compile a library code must be compiled to be relocatable. In other words the code must be able to run regardless of where it is loaded in memory. This question deals with this in more detail.
The -frecursive indeed should be specified if possible. Older implementations of gfortran, e.g. gfortran 4.1.2 on RedHat 5 do not support this option. Currently I haven't seen a workaround, so you have to remove it.
The gfortran documentation describes it as
Allow indirect recursion by forcing all local arrays to be allocated on the stack
In the thread you mentioned, for compilation of the LAPACK library the option -frecursive can be removed. Then the library compiles.
If it works without this feature remains to be seen. Haven't tested yet.
I built a GUI in MATLAB that makes use of the Instrument Control Toolbox, among other things. I tried to compile this GUI with deploytool but it's getting stuck during the compile:
ant:
<mkdir dir="Z:\My Path\MyApp\distrib" />
<mkdir dir="Z:\My Path\MyApp\src" />
mcc -o MyApp -W WinMain:MyApp -T link:exe -d 'Z:\My Path\MyApp\src' -N -p instrument -w enable:specified_file_mismatch -w enable:repeated_file -w enable:switch_ignored -w enable:missing_lib_sentinel -w enable:demo_license -v 'Z:\My Path\MyApp.m'
Compiler version: 4.18.1 (R2013a)
Processing C:\Program Files\MATLAB\R2013a\toolbox\matlab\mcc.enc
Processing C:\Program Files\MATLAB\R2013a\toolbox\instrument\mcc.enc
Processing C:\Program Files\MATLAB\R2013a\toolbox\shared\instrument\mcc.enc
Processing include files...
2 item(s) added.
Processing directories installed with MCR...
The file Z:\My Path\MyApp\src\mccExcludedFiles.log contains a list of functions excluded from the CTF archive.
0 item(s) added.
Generating MATLAB path for the compiled application...
Created 54 path items.
And that's all she wrote. Of note, the final statement of "Created 54 path items" to me doesn't make a whole lot of sense, since I don't have 54 dependencies.
I changed the path that the code is on to Z:\My Path\MyApp to be generic. It may or may not be important but there are spaces in the path. I mentioned this because maybe that's my problem. Z:\ is a network drive instead of a local drive. Some dependencies live on R:\, which is also a network drive. All dependencies are on the MATLAB path or in my local folder.
I'm using MATLAB R2013a x64 and the Windows SDK 7.1 (used mbuild -setup to set this).
The deploytool and MATLAB are both responsive - I can cancel the build process with no problem. I ran the mcc code verbatim as above and it's still stuck in the same place with no indication that it's working. Hitting CTRL-C to interrupt it gives no error messages or anything.
Does anyone know what's going on? It must be something to do with the mcc call, I'm sure of it.
It looks like this problem is due to my license file being located on a network server rather than locally. Working with MathWorks tech support really helped out here.
When using mcc, specify a local license file with the -Y flag. The compile then goes from 20 minutes or so to about 2. An example call:
mcc -m -v -N -Y alpha.lic myApp.m
I have inherited code, trying to compile with gcc on Linux.
what library am I looking for that has __builtin_ia32_stmxcsr ?
apologies -- i was too fast to submit; running gcc inside of Nvidia Eclipse. actual error message is "Functuion . . . could not be resolved" so i jumped the conclusion i needed to reference some lib. As the offending lines hav a :#if defined(SSE) I take it to mean that the -msse2 switch is present although i cannot seem to find a copyh of the compile command line. [just learning this Eclipse tool -- very new!]
You don't need to link with anything - the "builtin" in the name is a clue that it's a gcc built-in (intrinsic) compiler function.
However you do need to be compiling for an x86 target with SSE enabled for this to be recognised, e.g. gcc -msse2 ....
Note that you can use the _mm_getcsr intrinsic from <xmmintrin.h> instead of __builtin_ia32_stmxcsr - this would be a little more portable.
This is a bug in eclipses indexer with gcc's __builtin* functions. The bug report is at https://bugs.eclipse.org/bugs/show_bug.cgi?id=352537
The problem is that even the glibc/gcc libraries themselves use these __builtin* functions, so eclipse complains about a faulty xmmintrin.h etc., which is of course nonsense.
There is a workaround given in the bug report, you can add the function prototypes as user defined macros for the indexer, but of course this becomes tedious if there are a few more and some type checking abilities are lost.