how to use specific toolchain in Eclipse - makefile

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

Related

CMake Error variable not found LIBXML2_INCLUDE_DIR (Gate-9.0)

So, I'm currently installing Gate-9.0 it's a simulation kit based on Geant4. I'm following the installation guide in the documents which uses the
ccmake ../Gate-9.0
When itry to configure, it gives me this CMake Error:
CMake Error: The following variables are used in this project, but
they are set to NOTFOUND. Please set them or make sure they are set and tested correctly in the CMake files:
LIBXML2_INCLUDE_DIR(ADVANCED)
used as include directory in directory/home/art/Documents/Gate-9.0
used as include directory in directory /home/art/Documents/Gate-9.0
used as include directory in directory /home/art/Documents/Gate-9.0
I have the LIBXML2 library installed so i'm not really sure what to do. I'm not entirely familiar with linux-mint (and linux in general) so i appreciate any suggestions. Thanks! :)
I had a similar problem in the GATE 8.2 installation with optical photon applications. In ccmake, you need to press [t] to toggle advanced mode. There, you will have to find the lines that cause your problem:
*LIBXML2_INCLUDE_DIR LIBXML2_INCLUDE_DIR-NOTFOUND
*LIBXML2-LIBRARY LIBXML2_LIBRARY-NOTFOUND
Change them to:
*LIBXML2_INCLUDE_DIR (path_to_include)/include/libxml2
*LIBXML2-LIBRARY (path_to_lib)/lib/libxml2.so
After that, you should be able to successfully configure, generate and compile.

Shared library under Windows and CMake: DLL not found before installation

The library mylib consists of the library proper, in directory lib/, and a test suite, in directory test/. It is completely under CMake control:
mylib/CMakeLists.txt:
...
add_subdirectory(lib)
add_subdirectory(test)
...
mylib/lib/CMakeLists.txt:
...
add_library(my_lib ${src_files})
...
mylib/test/CMakeLists.txt:
...
add_executable(mytest mytest.c)
target_link_libraries(mytest mylib)
Build steps are:
mkdir build
cd build
cmake ..
make
ctest # or make test
make install
Works under Linux, stable since many years. Under Windows10 though, a message window pops up, entitled "mytest.exe - System error": "The code execution cannot proceed because mylib.dll was not found. Reinstalling the program may fix this problem."
No, installing (rather than reinstalling) would not be a good solution: I need to first test the library before I install it (btw: this excludes most solutions proposed in response to somewhat similar questions).
Isn't CMake supposed to work cross-platform? What is the minimally invasive adjustment to make the above build steps work under Windows?
The right way of doing this on Windows is to populate the PATH environment variable for the test run:
set_tests_properties(your_test_name
PROPERTIES
ENVIRONMENT PATH="path-containing-your-dll")
I believe you can use generator expression if path-containing-your-dll is a function of an artifact that you generate in your build.
Cherry on top: since cmake 3.13, the variable VS_DEBUGGER_ENVIRONMENT can also be set on the target for having a nice debugging behaviour inside Visual Studio (eg. being able to debug the application directly from Visual instead of going through ctest).

Xcode PATH environment variable

I am trying to compile an Xcode project that uses scripts to build some external (go) code. These scripts were build with the assumption that their external dependencies are on the $PATH. However, I am so far unable to get Xcode to use a PATH environment variable that includes the additions I need.
Is there a way to do this WITHOUT having to edit the Xcode project itself or the scripts? (I really don't want to edit these as these are shared with a larger team)
I have tried to use the LaunchAgents approach suggested in for example https://support.shotgunsoftware.com/hc/en-us/articles/219042108-Setting-global-environment-variables-on-OS-X, but haven't had success with it.
Wherever the script is called in xcode, that call would have to be amended to include the desired environment variable- but you don't want to modify the project. I would suggest putting symbolic links to the external dependencies somewhere in the default $PATH, where your scripts are expecting them to be.

How I can control the environment when building gcc or clang?

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 .

Include Intel-compiler variables into CMake makefile

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.

Resources