Okay so I have been working on this fork for over a year now and this thing doesn't want to compile as dll on x86-64 mingw running on Windows 10. I am following the original instructions: https://github.com/kometbomb/klystron/wiki/libksnd#compiling-the-library
And this is what it tells (there are other errors which can be fixed but this infuriates me the most):
Building ksndstatic.lib...
make: lib: No such file or directory
make: [Makefile:117: bin.release/libksndstatic.a] Error 127 (ignored)
Linking ksnd.dll...
Building ksnd.lib...
make: lib: No such file or directory
make: [Makefile:127: bin.release/ksnd.dll] Error 127 (ignored)
What the hell is lib?! Is this Visual Studio thing or outdated name for dlltool or libtool? What kind of zombie toolchain is this even made for? (hint: year 2007 or even earlier)
This can be relatively easy compiled as a submodule using the same windows mingw toolchain: https://github.com/kometbomb/klystrack
Or, if this does not work, try my fork: https://github.com/ltva1/klystrack
So the question is how to compile it at least with SDL linkage? Maybe I will be able to get it to work with native OSes APIs but at least I want a dll I can use in other C/C++ project.
Okay, the static linking works at least. There are some problems with audio buffer but this is outside of this question scope. I followed the advices in the thread above: undefined COMSPEC and added linkage to winmm in the case COMSPEC is not defined. See makefile changes there: https://github.com/LTVA1/klystron/commit/47e4c31c86833ce8d879d4474ba4045e95ea1a22 (COMSPEC undefine thing is commented out so main project which uses the repo as submodule gets compiled; -lwsock32 thing is unneded actually). At least I get the sound from the thing. Will wait 2 days to accept as answer.
Related
I have been having some issues with my CI under Windows (none of the issue occur under my own Windows installation). I am using GitHub Actions as a CI provider.
When make tries to run an executable linked against a certain DLL (which seemingly works fine in earlier invocations linked against the same DLL) with cmd.exe as the shell, it causes the following output (according to mingw32-make -d):
Creating temporary batch file C:\Users\RUNNER~1\AppData\Local\Temp\make3992-9.bat
Batch file contents:
#echo off
cd lib && ..\\test\\unit\\gencore_test.exe
cd lib && ..\\test\\unit\\gencore_test.exe
CreateProcess(C:\Users\RUNNER~1\AppData\Local\Temp\make3992-9.bat,C:\Users\RUNNER~1\AppData\Local\Temp\make3992-9.bat,...)
Putting child 000000000245A570 (gencore_test) PID 38130688 on the chain.
Live child 000000000245A570 (gencore_test) PID 38130688
Reaping losing child 000000000245A570 PID 38130688
mingw32-make: *** [test/unit/gencore_test.mk:8: gencore_test] Error -1073741819
Cleaning up temp batch file C:\Users\RUNNER~1\AppData\Local\Temp\make3992-9.bat
Removing child 000000000245A570 PID 38130688 from chain.
(The DLL is contained in the lib folder which is why I cdinto it before invoking the exe.)
This error occurs before main gets called (as I have a call to puts as the first statement), which makes me think that this is an issue with the lib loader.
I can only presume this is a bogus error code, obviously searching for it online yielded no results though I haven't searched the make or mingw source code to see if its ever mentioned.
If I replace the SHELL with sh.exe it instead gives the error 2816, which also doesn't occur on my personal Windows installation, and isn't documented on MSDN as a known error (the docs skip from 2404 to 3000).
I think this is to do with the DLL since it occurs before program runtime, but the fact that other executables linked against the same library work fine makes me think that it could be an issue in the build process - so here is the compilation and linkage of the executable:
clang -c -std=c17 -DWIN=1 -DDWN=2 -DLNX=3 -DBSD=4 -DPLATFORM=WIN -g -O0 -DMODE=DEBUG -D_MT -D_DEBUG -Igenesis/gencore/include -Igenesis/vendor/c11compat/mesa/include -Igenesis/vendor/dirent/include -o test/unit/gencore/main.o test/unit/gencore/main.c
clang -o test/unit/gencore_test.exe test/unit/gencore/main.o -lshlwapi.lib -Wl,-nodefaultlib:libcmt.lib -llibcmtd.lib -fPIE -Llib -lgencore
(IK some of that is probably irrelevant but it could be causing an esoteric conflict that I'm not aware of so I left it in)
The fact that it works fine on my own install with the same invocation, and given that I installed Windows specifically to resolve this problem and as such am as close to a vanilla installation as can be (using the same llvm release as the CI etc.) makes me think that its a configuration thing on the side of GitHub actions? But then again some executables work and some don't so its really up in the air.
Thank you very much if you know whats going on here and are able to help
The repository is here: https://github.com/Th3T3chn0G1t/GenesisEngine, though the build system is rather convoluted so if I missed a detail or something needs clarification I can distill it here.
I eventually found the answer - it turns out that Github CI can undergo some filesystem corruption and that it is a known issue, similar issues began cropping up in my Linux CI after this.
The solution I had was just to disable CI and re-enable it later on in order to possibly get a different host.
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.
I'm using Code::Blocks for a project. I have not used an IDE on Linux in years, so I'm a bit out of touch with Linux IDEs.
I'm working with an OpenSSL project that uses FIPS validated library. I duplicated the GCC compiler toolchain and modified it to use OpenSSL's fipsld (and set it as default).
When the project's code executes under Code::Blocks via F8, FIPS_mode_set fails with error 252104805 (0xF06D065). 0xF06D065 is:
$ openssl errstr 0xF06D065
error:0F06D065:common libcrypto routines:FIPS_mode_set:fips mode not supported
which tells me Code::Blocks is not using the OpenSSL I specified in /usr/local/ssl/lib. Rather, the program is using the non-FIPS library provided by Debian in /usr/lib/x86_64-linux-gnu/.
An image of the link library settings is below. Note that the libraries are fully specified, and nothing is left to chance.
CodeBlocks is clearly doing things with LD_LIBRARY_PATH (shown below).
I've also verified the project is using the correct search directories - /usr/local/ssl/include for headers and /usr/local/ssl/lib for the linker.
With compiler logging set to "Full Command Line" set, here's what I get from the build log:
-------------- Build: Debug in ac ---------------
Compiling: main.cpp
/home/jwalton/Desktop/ac/main.cpp:8:5: warning: unused parameter ‘argc’ [-Wunused-parameter]
/home/jwalton/Desktop/ac/main.cpp:8:5: warning: unused parameter ‘argv’ [-Wunused-parameter]
Linking console executable: bin/Debug/ac
Output size is 569.67 KB
Process terminated with status 0 (0 minutes, 0 seconds)
0 errors, 2 warnings
I'm aware of Basile Starynkevitch's suggestions on rpath's and LD_PRELOAD tricks, but this seems like one of those things the IDE should be handling for me (Visual Studio will handle it properly, and even gives us an input box to set Working Directories to find additional libraries).
Any ideas how to make Code::Blocks use the shared objects in /usr/local/ssl/lib when executing the program under the debugger?
Your IDE instructs the compiler to link against the specified libraries, but not to load them at run time. For this latter thing to happen, you need to pass another option to the linker, namely
-rpath=/path/to/directory/with/your/libraries
or, if the linker is invoked by the compiler,
-Wl,-rpath=/same/thing
Code::Blocks don't use shared objects (DLL are a Windows thing). Because Code::Blocks is simply an IDE. IDEs are glorified source code editors with the ability to run external software development tools. You could (and sometimes you should, at least to learn how things happen) edit your code with a plain good editor like emacs, and build it with commands. Your IDE is just running commands, notably a compiler and a linker, probably using gcc
So what is using shared objects in /usr/local/ssl/lib/ is the compiler and linker (and the runtime dynamic linker). BTW, /usr/local/ssl/lib/ is a very strange name for a directory containing shared objects; you should have configured OpenSSL to be installed in /usr/local/lib/ !
First, I really believe you should reconfigure and recompile and rebuild and reinstall your SSL to get it installed under /usr/local/ (or perhaps /opt/) prefix (i.e. shared libraries in /usr/local/lib).
Then you could add appropriate options for the ld linker (from binutils). You probably want -L/usr/local/ssl/lib (to the gcc command which is running ld), and you may want to pass -Wl,-rpath (see this).
I would suggest to reinstall your SSL in /usr/local/, add /usr/local/lib/ into /etc/ld.so.conf (or at least into your LD_LIBRARY_PATH...) and run ldconfig
Otherwise, add at least /usr/local/ssl/lib/ in front of your LD_LIBRARY_PATH (and also -L/usr/local/ssl/lib/ to your linking command).
Read Program Library HowTo, the answers to this, and Drepper's How To Write Shared libraries paper.
Just open the terminal and type
export LD_LIBRARY_PATH=/path/to/your/libraries
sudo ldconfig
I'm trying to statically link glib into my C program. I'm not sure what's the best way to do this. I downloaded the code and put it in a subdirectory called glib-2.36.4. I added "-Iglib-2.36.4" when using gcc. The glib.h is in the glib-2.36.4/glib directory and in that file there are references to other header files under the glib directory (such as #include ).
I'm not sure why that is since both glib.h and these other header files are at the same level (in glib subdirectory). I got a compile error due to galloca.h not being found (even though it's there). So I copied glib.h up one level and those errors went away. I then got an error about a missing glibconfig.h. I copied that from my usr directory and that error went away. I compiled my project and now I'm getting an error about undefined reference to g_ptr_array_new. I guess this must be because I haven't actually compiled glib. I had tried to build glib, but when I typed "./configure", but I got this message:
checking if arpa/nameser_compat.h is needed... configure: error: could not compile test program either way
I did install glib using yum, but I really want this code to run even if glib is not installed on a machine.
You need to install both glib and glib-dev via yum, compile using ./configure, (take a look in the ./configure script to see if there are any flags you need to supply or defines you need to produce the static build), without moving any files about, and then you need to compile your code using -i path/to/glib/includes and link with -L path/to/built/static/library
Let me start out by saying that I'm not a C developer and I know very little about actually writing real world C code. I've been doing some research to find a xUnit framework that I can use to write tests for C code and based on what I've found it seems like Unity is the one that I want to go with. It seems simple enough, but I really just don't know what to do after I download the zip file from Unity's website. It doesn't seem to have the normal configure/make/make install, and if it did, I'm not sure that is what I should be using anyway. It does, however, ship with some rake tasks, but none of those seemed to be any kind of "install" task. As a last resort I tried to just copy the 3 source files in with my code (which I really hope is not the right thing to do), but when I try that I get an error trying to compile my c file with gcc, but I think this should be working. Here is my set up:
src/
mycode.c
unity.c
unity.h
unity_internals.h
Here is the source for mycode.c
/* mycode.c */
#include "unity.h"
void test_sample(void)
{
TEST_ASSERT_EQUAL_INT(0, 0);
}
When I run gcc mycode.c I get:
Undefined symbols for architecture x86_64:
"_main", referenced from:
start in crt1.10.6.o
"_UnityAssertEqualNumber", referenced from:
_test_sample in ccyHByv6.o
ld: symbol(s) not found for architecture x86_64
collect2: ld returned 1 exit status
(I get a similar error when I try to compile unity.c with gcc). Which I assume means that the code that ships with unity requires a different compiler than what I have which is:
i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.9.00)
or that maybe unity is not compatible with a 64 bit processor... (I'm running on Mac OS 10.7.3 with a 2.4 GHz Intel Core 2 Duo processor - another thing that may or may not be relavent is that I've got XCode Version 4.3 (4E109) and also Command Line Tools for XCode) At this point I'm just grasping at straws and I'm in way over my head.
My question is, what is the correct process to go through to take a 3rd party C library, such as Unity, and make it available to my C code? Do I need to install something like in Python or Ruby or add something to my path like in Java or something else? Shouldn't just dropping unity's code in with mine work? Am I doing something wrong or is Unity or both? I really just want to be able to test drive C code using Unity. Any help would be greatly appreciated. Thanks in advance!
First, try 'gcc *.c -o mytest'. This will compile all of the C source files into object files, and then link them together into the binary 'mytest'. Keep in mind that all C source files have to be compiled to object files before they can be linked together. (A library is just a bunch of packaged object files.)
If you had a unity library installed in /usr/lib, you could do something like 'gcc mycode.c -lunity -o mytest'. If you had a unity library sitting in the current directory, you might do 'gcc mycode.c ./unity.a -o mytest'. This tells the compiler to look for a file named 'unity.a' in the current directory. Some libraries build .so files ('shared object' files, similar to DLLs in Windows). Replacing 'unity.a' with 'unity.so' should work if that is the case. (I'm assuming a Unix/Linux environment here.)
As an alternative to Unity, look at Google Test, which can be used with C code. I know it is supported on the Mac as well. The primary benefit is a large and active community. More information on Google Test from another SO question: Is Google Test OK for testing C code?
I figured out my problem. It turns out that unity requires you to define a setup and a teardown function and if you do not, you will get errors similar to the one that I was running into.