I know of the OCaml debugging tool (first compile with ocamlc -g <file>, then run ocamldebug <output>) and also the function call tracing feature in the toplevel (both covered here). However, I can't seem to find anything about debug builds with dune. Is this possible? Can someone point me in the right direction? Thank you!
The -g flag is present by default in all build profiles, so the short answer is that you don't need to do anything. As a pro tip, if you want to see what flags are set by default use
dune printenv .
or for the given building profile, e.g., for release,
dune printenv --profile release .
In a general case, flags are added using flags, ocamlc_flags, and ocamlopt_flags fields that are accepted by env, library, executable, and executables stanzas and have the corresponding scopes. If you want your flag to be applied globally you need to add the corresponding flag field to env stanza, e.g.,
(env
(release
(ocamlopt_flags (:standard -O3))))
Here :standard expands to the standard set of flags.
It is also worth to know that OCaml native executables (the executables compiled to machine code using ocamlopt) do not work with ocamldebug. You can use either gdb, which OCaml supports pretty well or use bytecode executables.
Related
I am in the process of converting a Makefile to CMake. We use several variables to configure a combination of build configurations.
These variables are things like:
OS := linux
CPU := amd64
BUILD_TYPE := dbg
Currently, we use a local.mk file to specify what values we would want to change these to if we were building for a different platform.
I know that I can pass these kind of values on the command line, but would prefer that I could modify a file and have that be used to decide the value of the before mentioned variables. Does CMake have an equivalent to a local.mk file that can change these values without modifying them inside the CMakeLists.txt?
The build type in particularly is handled by the CMAKE_BUILD_TYPE variable. It is used to determine what flags to pass to the compiler for a build of that particular type. For example: when CMAKE_BUILD_TYPE is Debug, it uses CMAKE_C_FLAGS_DEBUG. If it's Release, CMAKE_C_FLAGS_RELEASE is used.
When you're not doing cross-compilation CMake is clever enough to figure out the environment and what toolchain to use by itself.
I've no experience with cross-compilation using CMake, but using the CMAKE_TOOLCHAIN_FILE variable along with a file written with help from the cmake-toolchains documentation looks like the way to go. The "Cross-compiling for Linux" section is a good place to start with the example it provides.
I am learning to build a compiler using LLVM as back end.
I followed the steps on getting started with the LLVM system until setting up your environment
What is the specific location for [/path/to/your/bitcode/libs] ?
Was this mistake cause the command not found when I type in lli in a Terminal?
//I am trying to build a hello world to see through the total compiling procedure
You can put LLVM_LIB_SEARCH_PATH wherever you want. For now, you probably don't need to worry about it at all; as the documentation says, it is optional. Later, you may create bitcode (i.e. compiled VM code) functions which you would like to link into the bitcode your compiler produces. For example, you may need to create some kind of standard library and runtime environment for your executables.
That has nothing to do with the lli not found error, which is the result of the LLVM binaries either not having been installed, or having been installed somewhere which is not in your $PATH.
By default, the llvm package will configure itself for installation under the prefix /usr/local, which means that after you gmake install you should find lli and friends in places like /usr/local/bin/lli. That may or may not be in your $PATH; to find out, type
echo "$PATH"
and see if it has :/usr/local/bin: somewhere in it. If it doesn't, then you could change your PATH:
export PATH="/usr/local/bin:$PATH"
To make that permanent, you'll have to add it to your bash startup files.
But you might not want it to be installed there. I usually install software I'm playing with in my local directory tree, so that I don't have to sudo all the time. You can change the root of the installation directory tree with the --prefix argument to ./configure. (You have to do that before you build LLVM.) ./configure --help will provide some more information about configure options, but --prefix is certainly the most important one.
Whatever you do, don't do it blindly. Make sure you understand what this all means before doing it. If you plan on making a compiler, you'll need to understand some of the details of a typical build- and runtime- environment; PATH and configure scripts are on the unfortunately long list of things you should at least be somewhat familiar with.
As I understand it, some version of LLVM is already installed on Mac OS X, so you'll need to be careful that your installation doesn't interfere. The fact that bash is report that lli can't be found probably indicates that not all the tools are installed, which will make things less complicated.
I'm afraid that I don't really have any experience with installing LLVM on a Mac, but if you run into specific problems (like "my compiler doesn't work after I install LLVM") then you could ask a specific question with appropriate tags.
How to add source code of some_shared_library.so into gdb.
I've tried to use dir command but it has not helped.
In order for GDB to know what sources match your some_shared_library.so, you must build it with debugging info (usually -g flag).
Once you've done that (and it sounds like you haven't), on many platforms (e.g. Linux) GDB will find the sources automatically. On other platforms, dir is the right command to tell GDB where the sources are.
Upon finishing a COBOL program, how do I compile it into an executable file that may be run on other PCs? I'm using OpenCOBOL via cygwin.
Check out this getting started page from the user manual for OpenCOBOL:
But in case the link is broken, just do this:
$ cobc -x hello.cob
$ ./hello
cobc is the compiler. hello.cob is the source file. The output is simply the file hello which can be run by calling ./hello. The -x option is necessary to build an executable.
However, with all compiled programs, it is compiled for the machine is was built on. It will work on machine with similar architectures, but you don't true cross-platform ability unless you're using an interpreted language like Python or Java.
If you compile with Cygwin, the target computers also need Cygwin, or in particular the cygwin dynamic libraries along with the OpenCOBOL runtimes.
Many times, you can also compile under MinGW, which lessens the dependencies, but also lessens the available POSIX features.
Easiest path, install OpenCOBOL and Cygwin on the target machines, and you'll be good to go, otherwise you'll need to produce release packages with all the dependencies and instructions for PATH settings.
I'm using CMake 2.8.6 and the latest Intel C++ Compiler for a program which is compiled for Linux, MacOSX and Windows. For the development I'm using Eclipse with CDT on Linux and MacOSX.
Until recently I used CMake to create usual Makefiles which I ran from the console. To have a working environment, the Intel compiler comes with a shell-script called iccvars.sh which can be sourced to set all required include- and library-paths.
Now I decided to give the Eclipse-CDT build-system a chance and used the "Eclipse CDT4 - Unix Makefiles" generator of CMake to create an Eclipse project file. Everything works fine under Linux, but under OSX, Eclipse does not know about the environment variables and therefore paths like DYLD_LIBRARY_PATH are missing and the compilation stops because libraries are not found.
Update
Let me explain in more detail what I do. I'm running
cmake -G "Eclipse CDT4 - Unix Makefiles" path/to/src
from within the terminal where source iccvars.sh was executed and all environment-variables are set correctly. If I would have created a normal Makefile there and would run make, the compilation would succeed. This is because of the DYLIB_LIBRARY_PATH (in Linux LD_LIBRARY_PATH) is set correctly and I do not have to give -L/path/to/libs as option to the compiler.
But instead, I start Eclipse and import the created .project which works fine. The problem is that Eclipse do not know about my environment in the console and therefore cannot find the required libraries. One solution would be to use find_library inside CMakeLists.txt and locate every required library because then the full path should be included in the created Makefiles. Instead, I was wondering whether...
Question: Is there a way to source the iccvars.sh into my CMakeLists.txt so that the paths are available even when I'm not in my usual terminal-environment? Are there other possibilities?
Please note, that I know you can set environment variables for GUI-programs under OSX. What you have to do is to create a file environment.plist in your home under ~/.MacOSX. In this xml-file you put all your variables a GUI program should have. This works fine for other applications, but especially the Eclipse-builder seems to ignore this.