I'm trying to get a grasp on audio programming in C with OpenAL. I prefer CLion as an IDE to Visual Studio, but that generally means having to deal with cmake stuff and I ran into an issue regarding this. Right now I'm just trying to link the library (as in getting the definitions of the OpenAL functions) but it seems I've got something out of place. Here's the CMakeLists.txt file,
cmake_minimum_required(VERSION 3.19)
project(AudioTest C)
set(CMAKE_C_STANDARD 99)
set(OPENAL_LIBRARY "C:/Program Files (x86)/OpenAL 1.1 SDK/libs/Win64/") //OpenAL Installed here
find_package(OpenAL REQUIRED)
add_executable(AudioTest main.c)
target_link_libraries(AudioTest "${OPENAL_LIBRARY}")
The Cmake file compiles (or reloads) fine on it's own. But when I try to run this simple program,
#include <stdio.h>
#include <al.h>
int main() {
printf("Hello, World!\n");
alGetError();
return 0;
}
I end up with this,
undefined reference to '_imp__alGetError'
Could I get some pointers to what I might be missing?
Related
TL;DR - I have tried all solutions I could find, nothing has worked so far.
Hello, I have searched far and wide but I cannot find an answer to my problem. When I try to compile my C program with GCC, I get an undefined reference to glfwInit(). First, I tried putting the glfw .dll in the same location as the program, which did seemingly nothing. After this I tried removing the glfw libraries from MinGW's "lib" directory and replacing them with the .dll, and adding #define GLFW_DLL to the top of my .c file (same error). I also tried changing the linking order around, adding -lopengl32 and -lgdi32, renaming one of the static libraries just in case the compiler was confused, etc. Nothing seems to be working here, but I have previously installed and developed with SDL2 in the same fashion.
main.c:
#include<stdio.h>
#include<GLFW/glfw3.h>
int main(int argc, char **argv) {
if(!glfwInit()) {
printf("Failed!");
return -1;
}
printf("Success!");
getch();
return 0;
}
Instructions to the compiler:
gcc -std=c99 -o project.exe main.c -lglfw3 -lglfw3dll
Alright, I have finally solved the problem. I followed the instructions in this video: https://www.youtube.com/watch?v=bIK95aWk-Bo. The gist of the video is that you need to download CMake as well as the GLFW version found here: https://www.glfw.org/
Then, you need to hit "Configure" after setting the source and build paths. After this, hit "Generate." Then, you need to open a command prompt and locate the newly created MakeFile. I am using Windows, which means I needed to use the command mingw32-make. The library files then built successfully!
After doing this, I put the created .dll and .a files in the MinGW "lib" folder. Then, I copied the .dll and placed it in the same directory as my executable.
I wrote the following program in Codeblocks
#include <stdio.h>
#include <stdlib.h>
int main()
{
int a, b, c;
a = 5;
b = 6;
c = a+b;
printf("Hello world!\n");
return 0;
}
for both debug and release builds. The exe files are created in the respective bin\debug and bin\release folders, and the program works fine when run from codeblocks.
However when I try to execute the exe files form bin\debug or bin\release, I get the libgcc_s_dw2-1.dll is missing from your computer. error.
Searching for libgcc_s_dw2-1.dll only brings out other posts that ask how to fix this problem, where the suggested solution is to either add the path to libgcc_s_dw2-1.dll, which is somewhere inside inthe MinGW installation, to the system path, or statically link the dll file to the program during compilation.
My question is, why is this necessary? This is a very simple hello world program. The file is in a codeblocks project and file extension is .c (main.c, so I'm guessing gcc is automatically invoking the C compiler and it doesn't have anything to do with compiling C code with cpp compiler?) and the compiler settings have been left at their default values after a fresh MinGW and Codeblocks install. Since this program is very simple I am assuming it should work the same way in any other older version compilers as well.
Then what is the use of this dll file? What is happening under the hood when compiling this program? Suppose I compile the hello world program above and distribute the exe file to my friends. How am I supposed to know that I should have statically linked the dll file during compile?
I am in despair for a simple explanation to a simple problem.
I made a program in java that I need to recode in C for performance reasons. So I learned how to program in C. The problem is that C standard libraries do not contain collections (why????) such as a hashtables, treesets, etc. So I found this: https://github.com/srdja/Collections-C.
I use CLion on windows, I know well about coding but NOTHING about compiling, CMake, Linux, etc. My question is: I want to use those external source files my project, why is that so hard ? The tutorial on the link provided above tells me to use Linux command lines and stuff that I don't understand. Online I find stuff about telling me to add commands into CMakelist, none of these work for diverse reasons. I can't even copy all the .c and .h into my project because "they are not part of the project". So can anyone tell me how to make this simple code work ?
#include <stdio.h>
#include "hashtable.h"
int main() {
Hashtable *table;
hashtable_new(&table); //this is a function that creates the new hashtable in the source code of Collections-C
return 0;
}
By the way, because I think it's the same problem, how can I have subdirectories in my project so that I can put my header files away to keep the project tree tidy? I tried to add add_subdirectories($/include) to my CMakelist.txt
I am expecting people telling me that there are many similar questions already, but none of those I found is clear to me.
Thank you if you have the patience to explain this to me.
Henri
This is for C++, but it should work for your C code. In this example, it's defining where to find the OpenSSL and Google Test headers, and how to link with the Google Test library and the OpenSSL library (which is in C, as it turns out):
cmake_minimum_required(VERSION 3.5)
project(stackexample)
set(CMAKE_CXX_STANDARD 11)
find_library(GTest required)
include_directories(${GTEST_INCLUDE_DIRS} /usr/include/openssl)
set(
SOURCE_FILES
StackExample.cpp
StackExample.h
)
add_executable(stackexample ${SOURCE_FILES})
target_link_libraries(stackexample -lgtest -lssl -lcrypto pthread)
Collections-C appears to have an installer, so you would
List the path to its installed headers in the include_directories line
List its installed library in the target_link_libraries line
The solution was to build the library then do stuff with CMake. I followed this tutorial.
I'm new to external static libraries in C, and i'm having trouble adding pnglib (or any library) to Eclipse. Im using Eclipse v3.3.2 with mingw on windows 7 64bit.
I first followed these instructions to install libpng and zlib: http://wiki.openttd.org/Compiling_on_MinGW
Then in Eclipse under C/C++ Build -> Settings ->Tool Settings -> MinGW C Linker -> Libraries
I added: "png" then "z" in Libraries (-l)
and: "C:\MinGW\libpng-1.5.12" then "C:\MinGW\zlib-1.2.7" in the Library search path (-L)
If I execute the simplest code:
#include <stdio.h>
#include <zlib.h>
#include <png.h>
int main(void) {
printf("foo\n");
unsigned char header[8];
//png_sig_cmp(header, 0, 0);
return 0;
}
It works fine, however as soon as i uncomment the function, the code compiles (without error/warning), but does absolutely nothing, (not even the print statement). This happens when I use ANY function from an external library.
I assume it can read the headers but there's funny business with finding function definitions.
I have no idea where i went wrong.
I'm sure I have missed something trivial!
Looking into learning C. As I understand it when I say #include <stdio.h> it grabs stdio.h from the default location...usually a directory inside your working directory called include. How do I actually get the file stdio.h? Do I need to download a bunch of .h files and move them from project to project inside the include directory? I did the following in a test.c file. I then ran make test and it outputted a binary. When I ran ./test I did not see hello print onto my screen. I thought I wasn't seeing output maybe because it doesn't find the stdio.h library. But then again if I remove the greater than or less than signs in stdio the compiler gives me an error. Any ideas?
I'm on a Mac running this from the command line. I am using: GNU Make 3.81. This program built for i386-apple-darwin10.0
#include <stdio.h>
main()
{
printf("hello");
}
Edit: I have updated my code to include a datatype for the main function and to return 0. I still get the same result...compiles without error and when I run the file ./test it doesn't print anything on screen.
#include <stdio.h>
int main()
{
printf("hello");
return 0;
}
Update:
If I add a \n inside of the printf it works! so this will work:
#include <stdio.h>
int main()
{
printf("hello\n");
return 0;
}
Your code should have preferably
printf("hello\n");
or
puts("hello");
If you want to know where does the standard header file <stdio.h> comes from, you could run your compiler with appropriate flags. If it is gcc, try compiling with
gcc -H -v -Wall hello.c -o hello
Pedantically, a standard header file is even not required to exist as a file; the standard permits an implementation which would process the #include <stdio.h> without accessing the file system (but e.g. by retrieving internal resources inside the compiler, or from a database...). Few compilers behave that way, most really access something in the file system.
If you didn't have the file, you'd get a compilation error.
My guess is the text was printed, but the console closed before you got the chance to see it.
Also, main returns an int, and you should return 0; to signal successful completion.
#include <header.h>, with angle brackets, searches in standard system locations, known to the compiler-- not in your project's subdirectories. In Unix systems (including your Mac, I believe), stdio.h is typically in /usr/include. If you use #include "header.h", you're searching subdirectories first and then the same places as with <header.h>.
But you don't need to find or copy the header to run your program. It is read at compilation time, so your ./test doesn't need it at all. Your program looks like it should have worked. Is it possible that you just typed "test", not "./test", and got the system command "test"? (Suggestion: Don't name your programs "test".)
Just going to leave this here : STILL! in 2018, December... Linux Mint 18.3
has no support for C development.
innocent / # cc ThoseSorts.c
ThoseSorts.c:1:19: fatal error: stdio.h: No such file or directory
compilation terminated.
innocent / # gcc ThoseSorts.c
ThoseSorts.c:1:19: fatal error: stdio.h: No such file or directory
compilation terminated.
innocent / # apt show libc6
(Abbreviated)::
Package: libc6
Version: 2.23-0ubuntu10
Priority: required
Section: libs
Source: glibc
Origin: Ubuntu
Installed-Size: 11.2 MB
Depends: libgcc1
Homepage: http://www.gnu.org/software/libc/libc.html
Description: GNU C Library: Shared libraries
Contains the standard libraries that are used by nearly all programs on
the system. This package includes shared versions of the standard C library
and the standard math library, as well as many others.
innocent / # apt-get install libc6-dev libc-dev
So, magic... and a minute later they are all installed on the
computer and then things work as they should.
Not all distros bundle up all the C support libs in each ISO.
Hunh.
hardlyinnocent / # gcc ThoseSorts.c
hardlyinnocent / # ./a.out
20
18
17
16
... ... ...