I am working on integrating a few static libraries in one application. All libraries are build with GCC and CMake. Unfortunately CMake provide absolute paths to compilation command, what cause macro __FILE__ to be absolute path from build machine. If I am debugging library on other machine I am not able to locate file due to wrong path. In project tree I have access to libraries sources. I would like macro __FILE__ to point to relative path from project root.
Is it possible to achieve this with CMake and GCC?
CMake now uses only absolute path and GCC sets macro __FILE__ according to path received in command, so it seems that it is impossible to solve this.
The answer is: yes, it is possible to resolve this issue. Unfortunately not by providing relative path.
We modify path provided in file by -ffile-prefix-map option. We set all files path absolute to project root. Last step is to inform debugger where project root is. Due to fact that project location is constant to project root it will work on all machines.
Solution we used:
cmake_path(NORMAL_PATH PROJECT_ROOT OUTPUT_VARIABLE PROJECT_ROOT_NORMALIZED)
add_compile_options(-ffile-prefix-map=${PROJECT_ROOT_NORMALIZED}=./)
All credits to starball who posted a comment with the idea and article providing solution.
If link dies, article is named An introduction to deterministic builds with C/C++ and is on Conan (package manager) blog.
I'm currently trying to write an app for Raspberry Pi 3B under Rasbpian with aid of Linux Development plugin in Visual Studio 2017 Community. I managed to successfully deploy 'Blink' example, nobly attached by Microsoft folks, according to tutorial, and that went well. I even made some transmission over SPI thanks to wiringPi library. Then I would like to add some GUI to my app, so that one could, for example, make some transmission on click of a button on screen.
IntelliSense hinted me, that, in fact, there is gtk-3.0 library present in toolset. It seems that libraries are being copied from target device on every connection or so and I installed gtk on my Raspberry. So I added a simple line to this Blink example:
#include <gtk-3.0/gtk/gtk.h>
On compilation attempt, of course there was nearly 4k errors. Well, enough said, with a little hint from this old tutorial and a bit of trial and error, I managed to add this set of links under Debugging/Project properties/Configuration properties/VC++ directories/Header files directories:
Everything goes in promising direction, as errors number diminished from 4k to just one:
gtk-3.0\gtk\gtk.h: No such file or directory
No matter that this file is ACTUALLY in this location:
Regardless of combination of links in configuration above and using statement composition, compiler (?) can't find this damn file.
Please Halp
EDIT
I just confirmed, that it is indeed problem with target configuration. This is bad or good, depending on point of view. Good, because there is probably all good with VS setup. Bad, because I don't know a thing about compiling things under Linux.
On target (Raspberry Pi 3B) all ingredients for compilation are copied by Linux Development plugin. So in Terminal I executed line:
g++ main.cpp -o Blink2onRPi
and got
main.cpp:4:21: fatal error: gtk/gtk.h: no such file or directory
Now, I altered include line in main.cpp on target RPi, to this:
#include <gtk-3.0/gtk/gtk.h>
And now its missing <gdk/gdk.h>! When this change is made on host windows device - same result, but in VS.
As I dealt with similar problem in VS, upon setting links for IntelliSense (now apparently they're for this purpose), now probably similar dependencies have to be set somewhere on Raspbian. But where?
EDIT2
Upon execution of:
g++ main.cpp -o Blink2onRPi `pkg-config --cflags --libs gtk+-3.0`
on target RPi there is no more GTK-related errors, just wiringPi (also present in project) undefined references. It raises two possible questions:
1) How can I setup wiringPi on RPi so that the project could be manually compiled on target and
2) How/where add above line to Visual Studio, so it execute remotely with all GTK dependencies added properly on target
Researching stock present wiringPi library (as this is Blink led example for cross-compile Linux Development) I've found, that in Project Properties/Linker/Input/Library Dependencies there is mysterious entry:
wiringPi
Just that, nothing more. After removing this entry, on compilation pops out same errors as before on target (which apparently lacks proper wiringPi setup) - undefined references (not mensioned any missing headers). Can this be relevant for the case? If so, how could I add there such entry which would deal with missing GTK dependencies?
TL;DR
Use screenshot below to know where to add pkg-config calls in VS configuration so that it forwards it to the compiler and linker on the target.
Thanks to #zaguoba for providing these.
ORIGINAL ANSWER:
The list of directories to include is provided by pkg-config. For example pkg-config --cflags-only-I gtk+-3.0 will give you the list of include directories required. Those are the ones you need to add to the directories where VC++ wil look at include files. If you add the relative path you use in the #include, to one of those paths, you are able to find the file.
Example:
If you add to the directories C:\Program Files\foo\bar\gtk+-3.0
and have in your C file:
#include <gtk/gtk.h>
then the compiler will look for C:\Program Files\foo\bar\gtk+-3.0\gtk\gtk.h.
EDIT:
This all means the 'file not found' errors are because you're really building on the target and the target has no idea what C:\Program Files\... means. Those should be paths on the target filesystem, where the compiler is called. And this is exactly what pkg-config provides.
The copy of those files on the Windows machine filesystems is merely for Intellisense use, not for compiler use.
EDIT 2:
So that's that Visual Studio 2017 Community Linux Development plugin is what need to be undestood. It's not for cross compilation from Windows to Linux, istead it merely synchronizes code to the Windows host (for Intellisense use), but builds on the target. This means that all the paths and commands are Linux paths and commands, run on the target.
Here's the OP working configuration:
With that setup, you should
#include <gtk\gtk.h>
instead of
#include <gtk-3.0\gtk\gtk.h>
Alternatively remove all those VC++ directories/Header files directories, and just keep one of them that ends with include/ instead of listing up all the sub directiores.
Disclaimer: I'm no software engineer or programmer. I just know enough to get myself in trouble. Please forgive any misused or inaccurate terms.
I'm currently trying to test my HDF5 installation using the in-built Example test scripts. These are organised by CMake and compiled by gcc (MinGW and MinGW-w64). When I go to execute the test script:
ctest -S HDF518_Examples.cmake -C Release -V -O test.log
I'm met with pages and pages of errors, the core of these being:
mingw32-make.exe[2]: *** No rule to make target 'C:/aroot/stage/Library/lib/z.lib', needed by 'bin/h5ex_d_compact.exe'. Stop.
From my hours of trying to fix this on my own, I've been able to work out that z.lib is a library file part of the ZLIB library, ubiquitous these days. I also know that I have at least one copy of this particular file in my Anaconda directory under /Library/lib/.
I have two questions:
1) How can I get CMake or MinGW to recognize where this file is, and hence stop this error? Is there an environment variable I can set, or a config file I can modify?
2) As an aside, where did this path come from? There is no C:/aroot/ directory on my computer. I've also been unable to find any generators for this path in any of the CMake, HDF5, or MinGW files. So why is CMake pointing to this faux-directory?
Any help would be appreciated.
I use ENVIRONMENT PATH in set_tests_properties to specify the dependent external libraries.
set_tests_properties(${Testname} PROPERTIES ENVIRONMENT
PATH=${/your/zlib/location}
WORKING_DIRECTORY "${/your/working/directory}/")
I am newbee c programmer so be patient. I have a MSP430 C project in Code Composer Studio 7.3 using windows 7. My project (USB) was working fine and then I tried to add more code to incorporate a SPI interface and everything went sideways. I restored my original code but now have problems that weren't there before. Seems to compile but has several unresolved symbols errors in the linker (I think). I have searched/researched many answers to these types of problems on the forum and tried many things (over the past two days!!) and cannot resolve my problem. Possibly I made things worse by copying library/functions directly into my project directory but still didn't seem to change anything. The errors are related to standard MSP430 functions, not my code. My project tree looks like:
project tree
Errors from Console are:
console errors
From everything I have read it indicates that either I have a compiler library path problem or a linker file path problem. Tried a lot of combinations to no avail. Following are the compiler and linker path info:
linker 1
linker 2
If I look in my repository of library stuff downloaded from TI you can see that the dma.h and dma.c files which reference the error message lines in the files are there and I don't understand why the linker can't do its thing.
dma file tree
In the linker under library files I noticed the original libmath.a file didn't point to anything so I found one and added it (not help). Also the libc.a points to a section of 3 directories (different versions of a tool) which each have a different version of libc.a and I think I tried all of them. See below for directories
directories
Any help would be greatly appreciated
A CLUE POSSIBLY: CLUE? In my quest to solve my issues, I created a new CCs project and pasted my main.c file in and then went through a series of compiles solving the errors as the showed up. I was down to one error : can't open source file hal.h. I believe this is a file that was included with the usb example code I started with. After copying it into my project I am back to square on with all the errors listed above. To get here I only needed to point the compiler to driverlib to solve previous errors. The hal.h file seems to only include driverlib.h which is also referenced in my main function so why all the errors??
FIXED BUT WHY!!!
To solve this issue I imported the drivlib directory from the TI repo on my D drive into my project. Now everything compiles. Can anyone tell me why I had to do that given that I had path directives to look on my D drive?? Can it be related to search path length being too long?
I've installed the avr-gcc compiler and successfully convinced it to compile some test code through the terminal, so I thought I'd have a go at setting it up in code:blocks to make it a little easier to handle.
It seems to have detected it ok and I have it selected in compiler settings, but for some reason it can't find the avr standard libraries when I try to include them (like #include </avr/io.h>). The same code was fine when compiling using the CLI tool.
I tried manually inserting the file path into the include command (#include </usr/lib/avr/include/avr/io.h>) which solved the problem, it was able to find it then, but then it encountered an error in io.h where that file tried to include another .h file and again it couldn't be found.
Short of going through every standard library and manually rewriting every include command, is there a setting somewhere to have the compiler automatically search those directories? I tried giving it the address in
Settings/Compiler/Search Directories/Compiler
Settings/Compiler/Search Directories/Linker
Settings/Compiler/Search Directories/Resource Compiler
Settings/Compiler/Toolchain Executables/Additional Paths
but no joy. Anyone out there know of some field or tickbox I should have filled out?