Tipically you use CC or CXX or similar variables to control and configure your build when using a configure script.
Assuming that I need a much more reliable configuration, I would like to use something with a "chroot-philosophy", meaning that I would like to configure and build my compiler in an environment that has no executables in the PATH and no other environment variables other then the ones that I'm explicitly passing.
There is a solution to sandbox this kind of builds ?
I would like to get an error from my build instead of default actions or having configure scripts picking executables from the system folders .
Related
I have met with some issues in using the toolchain in Eclipse. I need the tool chain for cross compilation purpose
Currently my build method is to use makefile and I always have to
source
export LD=
But is it possible to use the information in for setting up Eclipse CDT.
I have tried to create the C/C++ Settings>Environment variables with the same environments settings as my . However it always run into error when i build
Error: Program "make" not found in PATH
my path in the environmental setup file is as follows:
/opt/R3linux/sysroots/x86_64-R3linuxsdk-linux/usr/bin:/opt/R3linux/sysroots/x86_64-R3linuxsdk-linux/usr/sbin:/opt/R3linux/sysroots/x86_64-R3linuxsdk-linux/bin:/opt/R3linux/sysroots/x86_64-R3linuxsdk-linux/sbin:/opt/R3linux/sysroots/x86_64-R3linuxsdk-linux/usr/bin/../x86_64-R3linuxsdk-linux/bin:/opt/R3linux/sysroots/x86_64-R3linuxsdk-linux/usr/bin/aarch64-R3linux-linux:/opt/R3linux/sysroots/x86_64-R3linuxsdk-linux/usr/bin/aarch64-R3linux-linux-musl:$PATH
Just like to know what is wrong? and what steps have i missed out in configuration steps
REgards
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.
Scenario:
We would like to build our sources by an external / hermetic toolchain so all includes, libs and tools from the host are ignored
To do so, a new toolchain is introduced to Bazel-Configuration. >>> working well
Using -Wl,-rpath=$ORIGIN/%{runtime_library_search_directories}/... the relative path from the binary to the libs that should be loaded on runtime gets defined >>> works quite well
When doing bazel run the Binary is executed but the host's LD is being used
To get rid of this a wrapper (written in Bash) is injected using --run_under. >>> dirty workaround
Problem:
--run_under could only be used once. We also need this option to execute tests within a specific environment and so this option is not the way of choice for us. IMHO it's also a bit dirty workaround.
We also tried to use -Wl,--dynamic-linker=<<PATH_TO_LD>>. But we were not able to get neither a relative nor an absolute path to LD when linking the executable.
Questions:
Is there ...
... any way to get the absolute/relative path to LD when linking?
... any other way of running a binary on Host using a toolchain?
... a possibility to do sandboxing/chroot so the correct LD of the toolchain is being used automatically?
Sidenotes:
Bazel 1.1.0 is used
the toolchain is GCC8 build from sources
the host is an Ubuntu 18.04.1 image running in docker
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'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.