I have included vk_mem_alloc.h on my c project and in my cmake file i added it as an interface like this
add_library(include INTERFACE)
target_include_directories(include INTERFACE include)
while include is the folder where i put my vma header file
and i added it without #define VMA_IMPLEMENTATION as mention in documentation like this
#include "include/vk_mem_alloc.h"
and yet it always gives me
undefined reference to 'vmaCreateAllocator'
when i try to initialize it
im using fedora 37 with vulkan 1.3
Related
I've got a piece of code in C in the main.c file of my program which is for embedded ESP 32 in ESP-IDF for context, and I'd like to cut and move some of the code like global variables callback functions definitions etc to other files like init.c, my_functions.c etc without creating a special library with header file and using 3include<lib.h> similar to how you can do it in arduino with ino files.
Is such a thing possible with CMake or ESP-IDF?
I am trying to compile a simple DLL using strictly C. The code for the entire test library is shown below:
#include <stdio.h>
__declspec(dllexport) void hello(void) {
printf("Hello, World!\n");
}
The library is meant to be a simple proof of concept which is built using CMake as provided by CLion with the following CMakeLists.txt:
cmake_minimum_required(VERSION 3.12)
project(test_lib C)
set(CMAKE_C_STANDARD 99)
add_library(test_lib SHARED library.c)
The DLL was built so I tried testing it with node-ffi and got Error: Dynamic Linking Error: Win32 error 126. Taking a step back from node-ffi, I put my newly created DLL in the apparently unanimously recommended debugging tool for DLLs: Dependency Walker. And it appears that the DLL I built has errors. Specifically:
Error: At least one required implicit or forwarded dependency was not found.
Warning: At least one delay-load dependency module was not found.
Dependency Walker did however find that I am exporting the symbol hello. I am basing this on the fact that hello is listed with an entry point when I examine the root DLL in Dependency Walker. It shows up in the bottom of the two right panes in Dependency Walker with nothing in the top most pane. The only item in Dependency Walker's bottom pane for symbol exploration looks something like:
E | Ordinal | Hint | Function | Entry Point
-----+------------+------------+----------+------------
[C ] | 1 (0x0001) | 0 (0x0000) | hello | 0x000010C8
Where the [C ] is a grayish color (if this means anything to anyone).
I am not sure what I am missing to cause this DLL to have faulty exported dependencies/symbols.
As it turns out, I was building for the wrong architecture. I was building for x86 with previous attempts (with my machine using an Intel processor). After all these attempts failing, I tried using this DLL in Python using ctypes. The error ctypes provided after loading in the DLL via CDLL('lib_test.dll') was much more elaborate, not only explaining the mismatched architecture, but which one my machine was expecting. In my case, it was x86-amd64.
Makes sense now that my DLL could not find those libraries. The DLL was attempting to fetch MSVC++ runtime libraries not installed since they are for a completely different architecture.
I am currently learning the C programming language and I'm having some issues with importing modules I created.
I created a small module to read with fgets and flush the buffer from stdin perfectly and I don't want to keep writing the code every single time. I just want to import this small module like I used to do in Python. I didn't knew how because I'm not using an IDE. I'm just compiling with gcc in terminal and using a text editor. I tried to search with Google,but in vain.
You should create a header for your module that declares the functions in the module – and any other information that a consumer of the module needs. You might call that header weekly.h, a pun on your name, but you can choose any name you like within reason.
You should create a library (shared or static — that's up to you) that contains the functions (and any global variables, if you're so gauche as to have any) defined by your module. You might call it libweekly.so or libweekly.a — or using the extensions appropriate to your machine (.dylib and .a on macOS, for example). The source files might or might not be weekly.c — if there's more than one function, you'll probably have multiple source files, so they won't all be weekly.c. You should put this code (the header and the source files and their makefile) into a separate source directory.
You should install the header(s) and the library in a well-known location (e.g. $HOME/include for headers and $HOME/lib for the library — or maybe in the corresponding directories under /usr/local), and then ensure that the right options are used when compiling (-I$HOME/include for the headers) or linking (-L$HOME/lib and -lweekly).
Your source code using the module would contain:
#include "weekly.h"
and your code would be available. With shared libraries in $HOME/lib, you would have to ensure that the runtime system knows where to find the library. If you install it in /usr/local, that is done for you already. If you install it in $HOME/lib, you have to investigate things like /etc/ld.so.conf or the LD_LIBRARY_PATH or DYLIB_LIBRARY_PATH environment variables, etc.
You need to create a header file (.h) with your function declarations types and extern variables. Then in the program where you want to use those functions include this .h file and and add the compiled .o file (with your functions) to the object file list. And you are done.
I'm reading mach-o/loader.h and noticed this file type and it's description:
#define MH_DYLIB_STUB 0x9 /* shared library stub for static */
/* linking only, no section contents */
This sounds almost like an import library for PE/COFF. Can anybody point me to something that talks about it?
This is a link-time only special object file which contains no code, but does contain symbols (LC_SYMTAB, DYSYMTAB) so that the linker can use it. It has made a cameo appearance around Xcode 7 before Apple moved to the proprietary ".tbd" files (which are textual).
Source: MacOS/iOS Internals, 2nd Edition, Chapter 6.
I am developing a C application, and using Eclipse CDT IDE, which I find great. The project uses Glib,Gtk,and GStreamer , so whenever I use some of their features in a file, I need to include:
#include <glib.h>
#include <gtk/gtk.h>
#include <gst/gst.h>
The code compiles without any error, since the PATH variable to search those headers is set correctly in a CMakeLists.txt.
However, while working on the project, I found annoying errors highlighting in my code, regarding type definitions like gchar or GValue or GTKApplication; the error outlined is "symbol **** could not be resolved". These definitions are inside a header file that my Eclipse IDE cannot find (included by glib.h), if not at compile time (indeed the program compiles correctly). Instead, the type GError , defined in gst.h , is not highlighted as an error by the pre-compiler.
I would like then that my Eclipse IDE could search on nested headers (#include inside an #inlcude inside...) to find those type definition, in order so to not have those annoying errors highlighting. How can I do so? I would not like to have to include directly all files where the type definitions are done.
EDIT: As Jonah Graham outlined, the problem is not beacuse Eclispe does a "single-step research" on the headers, since it inspects includes inside other includes like any other IDE. It is a CMake bug with c and Eclipse
Thanks in advance.
The problem you are facing is a CMake bug*. CMake adds __cplusplus into the defined symbols unconditionally, which means that glib headers are not parsed properly when in C mode. You can see this clearly by opening gmacros.h around the definition for G_BEGIN_DECLS:
Because CMake told CDT __cplusplus is defined, it thinks G_BEGIN_DECLS is also defined, which makes code like this from gtypes.h parse incorrectly:
G_BEGIN_DECLS
/* Provide type definitions for commonly used types.
* These are useful because a "gint8" can be adjusted
* to be 1 byte (8 bits) on all platforms. Similarly and
* more importantly, "gint32" can be adjusted to be
* 4 bytes (32 bits) on all platforms.
*/
typedef char gchar;
...
Of course with no gchar defined, everything else is going to go badly.
Luckily there is a quick workaround until the problem is resolved in CMake, remove __cplusplus from the info in CDT.
Open Project Properties
C/C++ Include Paths and Symbols
Remove __cplusplus from the list and press OK
(sometimes necessary) Right-click on project -> Index -> Rebuild
* There may be some other workarounds if you know CMake better. The bug says also it will be fixed for the next release of CMake.