I have mac os CMake project where I'm trying to bundle a Wavefront text .obj files into the resources of the application (https://en.wikipedia.org/wiki/Wavefront_.obj_file): the content is irrelevant, but just happens that the standard extension for that format is .obj.
Now, If I name the files something.obj_ I get everything working properly, so this is not a "mac question". But I want to keep original extension .obj.
What I want to achieve is that my target executable has also a dependency on the .obj resource file, since a change on the resource should recreate the bundle with the new file.
My problem is that any dependency on a file named .obj gets it interpreted as a code object and the linker just issues the errors:
ld: warning: ignoring file ../../assets/file.obj, file was built for unsupported file format ( 0x23 0x20 0x42 0x6C 0x65 0x6E 0x64 0x65 0x72 0x20 0x76 0x32 0x2E 0x37 0x39 0x20 ) which is not the architecture being linked (x86_64): ../../assets/file.obj
From what I see, any other files that are on the same directory with "unknown" extensions such as .mtl are copied correctly, but this .obj file must be some triggering some rule associated with linker.
How can I get cmake to simply handle the file as a "text file to copy" independently if it was called .obj, .cpp or .o ?
I think I found the solution to my own question:
set_source_files_properties(${ASSET_FILES} PROPERTIES
HEADER_FILE_ONLY ON
)
This will pass ASSET_FILES through the linker without a problem
Related
How can I find a file inside a directory based on the file extension?
I want to create a function that finds a linker script. The function will be defined in the toolchain file, because each compiler has a different type of linker script.
I want to pass to the function a path to a directory with linker files for all type of supported compilers.
The function implemented for the specific compiler will find the right linker file (for example, armcc compiler will find the file with the extension .sct)
Thanks for the help.
I have an ELF file that links to a shared object file from version X of a library. I only have access to the version of the shared object file from version Y of the library. When I try to run the ELF file, I get <ELF filename>: <shared object filename>: version X not found (required by <ELF filename>). Installing version Y of the library is not an option for me right now. Is there any way to force the ELF file to ignore the version mismatch and try to run? Can I fool the ELF file or somehow edit the shared object file to change the apparent version?
No. The "version" is not the version of the library, but the version of the symbol (ELF files support symbol versioning for keeping backward binary compatibility when changing APIs, see this post for details).
Effectively what it's saying to you is that it's missing a symbol (function, constant, global, etc.) that is not present in the library you have. Which means the library does not have the interface it needs.
What is the difference between the map file generated by the linker and the linker file that contains the memory segments itself ?
the 'linker' file is a set of commands to the linker as to how everything is to be laid out in memory and is created by the programmer.
The 'map' file is a listing of where everything is located in memory and is created by the linker.
In the main folder of my project, I have a CMakeLists.txt file. Inside this file, I include (using add_subdirectory) another CMakeLists.txt file located in my header file directory. The responsibility of this second file is to add all of my header files to the project:
file(GLOB gl_nbody_HEADERS "*.h")
add_executable(gl_nbody ${gl_nbody_HEADERS})
However, this files causes an error:
CMake Error: CMake can not determine linker language for target:gl_nbody
CMake Error: Cannot determine link language for target "gl_nbody".
What is strange is that when I include the two lines causing this error in my main CMakeLists.txt file (modified to work correctly for the change in directory), it works fine.
What is going wrong here?
add_executable causes the creation of an executable target, meaning the compilation of a list of source code files into an executable binary.
In order for this to work, and have CMake select a suitable compiler, the list of source files must contain at least one file with a "compilable" extension, ie. .c, or .cpp, or .cxx....
I don't see why you are trying to compile an executable here, since you only seem to try to list header files for inclusion into a project (which only makes sense for IDE-based generators, such as Visual Studio).
Also, it is not recommended to use globbing of files in CMake, because if you add more files to your project, CMake cannot detect them automatically, and will not regenerate build files. Please list all files explicitely.
The proper solution here is to list the header files in the proper add_executable command call where you list the actual source files that you want to compile.
You might also want to use the source_group() command, that allows you to group files into folders in the generated Visual Studio solution, for example:
source_group(header_files ${gl_nbody_HEADERS})
Compiler: Mingw GCC compiler
In make file I specified src directory location like below..
dirsrc = ./src
So here I mentioned current directory. The problem is the generated DLL having the Absolute path to the source directory. Is there any way to notify the compiler which should be relative.?
Because I am generating this DLL with Codecoverage information. If I moved my full project structure to somewhere means while simulating the DLL to target, at that time the DLL refers to the absolute path of the source directory.
I need the DLL with relative path to the source directory.? How do I write the make file with relative path to the source directory?
The real problem is,
I am doing code coverage analysis using gcov.
I followed following steps:
1.) I compiled my program with GNU CC options: `-fprofile-arcs -ftest-coverage'.
2.) I got 2 additional file with suffix *.bb and *.bbg in same directory
3.) Running the program will cause profile output to be generated.
For each source file compiled with -fprofile-arcs', an accompanying .da' file will be placed in the source directory. The name of the .da' file is stored as an *_absolute pathname_* in the resulting object file. This path name is derived from the source file name by substituting a .da' suffix.
The problem here is that I am compiling on one machine and running on a seperate machine. Each '.da' file has absoulte pathname in the resulting object file. So it does not find same path on another machine.
Is it possible to have fprofile-arcs and any other profiling-related options in GCC to have file names relative rather than absolute.
please let me asap.! thanks in advance.