I have a small project in Nvidia's Nsight, which creates the makefiles for me. I want to use some SSE instructions and would like to compile cpp-files in the project with gcc instead of nvcc.
Is there a way to configure Nsight to do that or do I have to write the Makefile manually?
EDIT: .cu file should be compiled with nvcc of course.
You should be able to use GCC SSE instructions in the CU files - NVCC compiles all the host code with your platform compiler.
If you still would like to use GCC, you have two options:
Create two projects - one is a static library project compiled with NVCC and another a regular executable project compiled with GCC. Then you can setup Nsight to link the executable with your library. (You may also use NVCC for executable and GCC for the library)
As #Eric mentioned, you can create a "Makefile Project" and write the makefile by hand.
To use gcc in Nsight, you have to create makefile project and write the makefile by hand.
Alternatively, uou could use nvcc to compile your .cpp/.c file. To add extra compiler options which do not recognized by nvcc (only recognized by gcc), the nvcc option -Xcompiler should be prefixed.
One of the side-effects using nvcc is that your .cpp program will require libcudart.so to run, even it does not really need that.
Related
I use my own build tool in cdt eclipse. It builds the target files and writes some build information to the console window.
For the indexer I only enables the cdt gcc Output parser, and my expectations is that all the information for the include path and dependencies are getting from the build output.
Unfortunately the parser seems not to work correctly. It could not resolve the dependencies. I tried several times to rebuild the indexer
I tried it with the default Compiler command pattern: *(g?cc)|([gc]++)|(clang)
and for example I simplified log line to compile a single c-file is as follows:
INFO :: Command C:\target-gcc.exe -c- -IC:\Include1 -IC:\Include2.. C:\Projects\test.c -o C:\Projects\test.o
Using the the CDT GCC Build in Compiler Settings MinGw in principle works, but then I have some addtional errors in the Problems windows which I want to avoid.
I am about to write the build configuration for a (mostly) SWIG'd wrap of a C++ library to be callable from Scala. Due to the presence of 3rd party dependencies on the Scala side, as well vast community support, I'd like to use sbt to automate the build.
However, I am a bit at a loss as to automating the swig and c++ compilation steps. Does anyone have experience with mixed-language build configurations driven by sbt and can offer advice about this?
So far I have found about the sbt-sh plugin, but I'd rather avoid shelling out directly if possible. I have also considered using cmake as the driver (since cmake does have a swig-driver plugin), and have a java/scala-only build step fired off cmake after it has completed the swig and c++ build steps.
SBT has its own syntax for executing external processes. You can leverage this + path finding + source generation.
A rough example:
lazy val invokeSwig = taskKey[Seq[File]]("invoke swig")
invokeSwig := {
s"swig -java example.i -outdir ${target.value}" !
val pathFinder = target.value ** "*.java"
pathFinder.get
}
target in invokeSwig := target.value / "swig"
sourceGenerators in Compile <+= invokeSwig
Note: I am using sbt v0.13.9, but this should work in other versions too.
You'd have to do some additional work for the native components. This includes compiling them as well as ensuring that they are available during run.
Unfortunately, I don't think you can get around doing some shell scripting since swig is a command line tool. (I have not found any java wrappers.)
SBT has the concept of source generators. A source generator is nothing more than a function/task writing (and returning) some files. If you do this, then SBT will first execute all source generators before starting to compile the (rest of the) code.
Just make sure to get swig to output its files to sourceManaged in Compile, then the generated source files are available on the classpath during compilation.
def runSwig: Seq[File] = {
import sys.process._
Seq("swig" , "param1", "param2", "..." ).!
// Somehow determine which files have been written by swig.
// I would make swig output its files to a temp directory and copy them to the source managed directory manually.
}
sourceGenerators in Compile += Def.task {
runSwig
}
I'm not sure about C++ code though. In my own project I'm using docker to cross compile to various platforms. If your native code doesn't change often, I won't recommend recompiling the native code every time SBT is compiling your java/scala code.
I have IntelliJ Idea Community Edition v 123.72, with Scala Plugin 0.6.371 on an Debian unstable box that has packages scala and scala-library v 2.9.2+dfsg-1. When creating a new Scala module, I am asked for either "SCALA_HOME" or an "Existent Library" with two empty drop downs for "compiler library" and "standard library".
Is it possible to use the distro scala packages with the plugin? If so, how do I fill out the
"new project form"?
If not, where do I find a Linux binary distro of Scala?
(It all seems straight-forward, but my Google-fu fails me.)
Download the latest version of Scala here and then set scala home to the unzipped directory (can be anywhere). IntelliJ will take care of the rest.
Alternatively, recreate the directory structure that intelliJ is looking for by using mkdir and ln -s.
The Debian package manager installs bits and pieces of scala all over the root directory. I found the libs that intelliJ is looking for in /usr/share/java
To create system links and satisfy intelliJ you can try the following:
mkdir /usr/share/java/lib
ln -s /usr/share/java/scala-library-X.X.X.jar /usr/share/java/lib/scala-library.jar
ln -s /usr/share/java/scala-compiler-X.X.X.jar /usr/share/java/lib/scala-compiler.jar
export SCALA_HOME=/usr/share/java
Why aptitude drops scala nuggets all over the place, instead of a more common, central location such as /usr/lib/scala remains a mystery to me. Anyone?
I have a program, written in fortran90, previously successfully compiled on a compaq compiler and working, that I'm now trying to compile with gfortran. I can compile the code to an .exe and run it. It works fine until a certain point in the routine and then an error is thrown.
My current configuration:
Windows 7
Eclipse Juno with CDT
Photran
Cygwin installation with gfortran compiler and GDB debugger (gdb.exe)
Configurations for the debugger:
GDB command set: Standard (Windows)
Protocol: mi
Shared libraries: don't load shared library symbols automatically (when activating this, no changes are noted).
When running the debug command I get the following output:
.gdbinit: No such file or directory.
Reading symbols from /cygdrive/c/Users/thys/Documents/doctoraat/12_in progress/Hamfem/Debug/Hamfem.exe...done.
auto-solib-add on
Undefined command: "auto-solib-add". Try "help".
Warning: C:/Users/thys/Documents/doctoraat/12_in progress/Hamfem/Hamfem/in: No such file or directory.
[New Thread 5816.0x1914]
[New Thread 5816.0x654]
Basicly that leaves me with 2 questions:
Where can I find the .gdbinit file in the cygwin installation?
Are there any other possible errors in my setup, or points to think about?
Did you add the debugging information when compiling? When using gdb in console it shouldn't be a problem, except looking at memory addresses and a lot of gibberish, but there could be complications from using Eclipse...
I tried to compile Scala^Z3 on Win XP using Cygwin and JDK 1.7.0 but it didn't work out as expected.
I did the following:
- Use SBT 0.7.4
- Use current Scala^Z3 revision from github
- Use Cygwin and its gcc
- Use JDK 1.7.0 (javac)
"sbt update" was successfull.
"sbt package" end up in several errors stating undefined references like the following:
\psuter-ScalaZ3-35cb691\src\c/z3_Z3Wrapper.c:10: undefined reference to `_Z3_mk_config'
In order to make it work at all I changed ....\PSuterScalaZ3\psuter-ScalaZ3-35cb691\project\build\scalaz3.scala line 74 to:
lazy val gcc : ManagedTask = if(isUnix || is32bit) {
On the homepage it is stated that it should work for Windows, too. Does it at all?
Is there a precompiled jar available?
I saw a z3.jar here: http://lara.epfl.ch/~psuter/jniz3/z3.jar
This is a Linux Version too, I guess? Because it didn't work for me either...
Scala^Z3 is a really good piece of code (if i can get it to work ;))
Sorry about that, the sbt script indeed currently only works for Linux (and as you can tell by the absolute path, we're not quite used to having external users yet).
Here are the steps I use to compile it under Windows:
compile all Java sources with javac (there are no dependencies)
generate the header files using javah
compile all the Scala sources with scalac (using only the Java .class files as dependencies)
compile the .c + .h files with Visual Studio
manually create a jar file with everything
We also hope to release a precompiled .jar file with the shared library for Linux and Windows once we adapted Scala^Z3 to the new changes in Z3 3.1.
EDIT The GitHub repository now contains a precompiled .jar file prepared for Scala 2.9.1 and Z3 3.2. It works under Windows and Linux (32bit). The repository also contains more detailed instructions on how to compile the shared library in Windows, using MinGW instead of Visual Studio (hence removing the need for VS runtime libraries).
I had a similar problem some months back and here is what it I had to do in order to compile it with Visual Studio 2010. I am not sure if it is still relevant since Scala^Z3 and Z3 itself changed a lot, but I hope it nevertheless is helpful.
Created a new Visual C++ Win32 project (.NET Framework 4) for
creating DLLs.
Added all .h and .c files in the src/c/ directory. VC somehow
complained about the "inline" modifier and a work mate suggested to
remove them, which I did.
Added z3.h from Z3 2.19, Z3 2.16 wasn't accepted. Also added the
corresponding z3.lib (x86, haven't tried x64 yet). VC wouldn't accept
z3.dll and complaint about the file being corrupt. No clue why, Z3
itself works fine for me.
The project compiles with 13 warnings and a dll is created which
apparently MUST be named scalaz3.dll.
sbt compile, adding scalaz3.dll to lib-bin, jar the whole thing
together to scalaz3.jar
'scala -classpath scalaz3.jar test.scala' with scalaz3.jar and z3.dll
in the current folder works