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.
Related
Firstly, I am not sure if the title exactly words my question well but after three days of searching the web and SO for no working answer, please bear with me.
So the problem is that I have a C application where CMake is the build system. This application relies on libreadline and I can correctly find and link with it using the snippet below:
find_library(READLINE_LIBRARY readline REQUIRED)
target_link_libraries(myExe PRIVATE "${READLINE_LIBRARY}")
The problem is that when I build the application on a system with say for example libreadline.so.8 which is the version 8 and move the application to another system that only has libreadline.so.7 or none available, I'll have to install the missing library before I can run the application. This make for a very bad user experience.
I have tried setting the #rpath before the add_executable and add_library with:
set(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_RPATH}:$ORIGIN")
set(CMAKE_BUILD_WITH_INSTALL_RPATH TRUE)
set(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)
The problem is that while that correctly sets the #rpath for a shared library which forms part of the project, it doesn't do the same for libreadline. Also even if for any reason I am able to get it to work, I don't know how to get call to find_library return a relocatable library (meaning I can't bet that the libreadline.so.8 was build with -fPIC or not).
Whatever I do, I can't get a local copy of libreadline in my build output directory.
Also note that this problem exists on OSX as well just using the Linux example for simplicity.
On OSX when I inspected the executable with tool -l myExe, I noticed that only the Load Command section for the shared executable which is part of my project correctly uses #rpath while the editline (OSX deadline seems to just be an editline) looks like this:
Load command 14
cmd LC_LOAD_DYLIB
cmdsize 56
name /usr/lib/libedit.3.dylib (offset 24)
Any help will be appreciated. I'm quite stuck. But one thing I'm certain of it that I have seen applications that does this which means it's very possible.
Let me preface this, I am very new to linux and to working on a non-IDE based setup.
I am trying to debug a very simple C program using vs code version 1.55
I unloaded all modules beforehand, so vs code can load appropriate default gcc & gdb versions (which it did, GCC 8.2)
I am following the VS code getting started documentation for setting up and everything seems very straight forward until I try to debug.
I use the default settings as instructed, the file builds successfully but then I get the below
/usr/bin/gdb: symbol lookup error: /usr/bin/gdb: undefined symbol: PyUnicodeUCS4_FromEncodedObject
please note that I cannot rebuild python with ucs4 enabled as suggested in another thread as I have no root access. however I can change VS code version to an earlier one if this will help.
Thanks.
I think this issue is specific to my environment but I will post the answer anyway as it may face someone else.
So this for me was 2 separate issues:
First gdb doesn't start and second vs code can't start gdb.
To check if this is the case try to launch gdb from terminal (not vs code) by typing gdb in the terminal (after loading gdb if needed), I was receiving the error above
Solution to this part is this as T0maas thankfully suggested above
Steps for linux newbies:
ldd gdb (or /usr/bin/gdb) (with vs_code loaded)
from step one get the python library path
unload all modules
load gdb
LD_PRELOAD=<python path from 1>
bash -c "export LD_PRELOAD"
load vs_code
load gdb
After the above steps writing gdb in the terminal should start gdb
Part 2:
The rest of the problem was when I tried to launch debugging session through the GUI of vs_code (still produced the same error)
In the terminal (after loading gdb) type whereis gdb
For me this produced multiple directories the first of which was /usr/bin/gdb (this is the default used in vs_code launch.json)
Changing that directory in the launch.json file to a different one of the other directories solved the second part of the problem for me.
I wrote a demo using libpq to connect to a PostgreSQL database.
I tried to connect the C file to PostgreSQL by including
#include <libpq-fe.h>
after I added the paths into system variables I:\Program Files\PostgreSQL\12\lib as well as to I:\Program Files\PostgreSQL\12\include and compiled with this command:
gcc -Wall -Wextra -m64 -I "I:\Program Files\PostgreSQL\12\include" -L "I:\Program Files\PostgreSQL\12\lib" testpsql.c -lpq -o testpsql
It first raised three errors, like
libssl-1_1-x64.dll is missing
libintl-8.dll was missing
libcrypto-1_1-x64.dll was missing
After I downloaded these three files and put them into I:\Program Files\PostgreSQL\12\lib, and compiled it again, it shows the error
The application was unable to start correctly (0xc0150002)
when I type testpsql. But if I type ./testpsql on git bash, it works. Anyone can please tell me why?
The code that I used was the first example from here.
Environment: PostgreSQL 12, Windows 10, MinGW64
“Download the DLL files” sounds dangerous. From where?
I would get rid of these files again. Since you probably don't reference these libraries from your code, it must be the dependencies of libpq.dll and are probably found in I:\Program Files\PostgreSQL\12\bin (if you used the EDB installer).
The problem is probably that you the PATH environment variable is different in git bash and in cmd.exe, and in the latter case not all required shared libraries can be found on the PATH. The solution is to change the PATH so that it includes all DLL files the executable requires, not to start copying around files.
It is probably enough to include I:\Program Files\PostgreSQL\12\bin in the PATH. To resolve missing dependencies, use a tool like dependency walker or this replacement.
I am trying to compile a C code on Oracle Linux 7.2 which is hosted as VM on windows 10.
Name of file run: configure
Name of log file: confg.log
Error where I am stuck
gcc: error: unrecognized command line option '-V'
As per my understanding of the code structure so far, there is a file named configure which is having compilation related commands and this file generates Makefile.am which further generates Makefile.in and at last Makefile.
Please help me in solving the error and also let me know if my understanding about the configure and makefiles is incorrect
configure scripts explore the environment in which a program is to be built. They then accordingly adjust tools called, options used and libraries linked, among other things. Some of the information is obtained by trying to execute programs with certain options; failure of a program to run is the intended way of obtaining the information that the given program is not available or does not take those options. Therefore it is not necessarily an error if one of the things doesn't work and produces an error; it may be one of the legitimate outcomes, and the (error, here) exit code of the compiler will be used to modify the Makefile accordingly — for example by omitting -V ;-).
Does the configure script actually stop there, or are you just observing the error in the log file? If you search for gcc -V on the web you'll find examples of configure scripts failing actually later (for unrelated reasons) which have the same "-V error" line in it. Could that be the case? I would assume that errors which actually cause configure to stop and not produce a Makefile should be visible on the command line, not only in the log file.
As an aside it is worthwhile to run ./configure --help and look through the options. Some may improve the build process or the result; for example you can usually tell configure that you are using gcc, gnu ld and so on, or that you don't need certain features (like X25 ;-) ).
You should look into the makefile of your project, identify where the misspelled -V option is and replace it with -v (lowercase). As pointed out by others in the comments -V is not a compiling flag, but gives back the compiler's version.
I'm trying to compile a simple hello world application to be run on uCLinux (2.4) which is running on a board with a Freescale Coldfire (MCF5280C) processor...and I'm not quite sure what to do here.
I know I need to compile with the correct version/tools from Freescale to target this hardware, so I downloaded and installed the Coldfire tool chain and verified that one I have is for my target:
mike#linux-4puc:/usr/local/m68k-elf/bin> ./gcc -v
Reading specs from /usr/local/lib/gcc-lib/m68k-elf/2.95.3/specs
gcc version 2.95.3 20010315 (release)(ColdFire patches - 20010318 from http://fiddes.net/coldfire/)(uClinux XIP and shared lib patches from http://www.snapgear.com/)
I tried a simple gcc "file" type command:
mike#linux-4puc:/home/mike> /usr/local/m68k-elf/bin/gcc test.c
/usr/local/m68k-elf/bin/ld.real: cannot open crt0.o: No such file or directory
collect2: ld returned 1 exit status
Which does not work at all.. so it's clearly more complex that than. The output almost looks like it wants me to build the tool chain before I use it?? Anyone ever done this before? Not sure what I need to do or if I just need some flags.
You might also try seeing if you have a command called m68k-elf-gcc or something along those lines. This is a common naming for cross-compilers.
As for your problem, it sounds like there is something wrong with your compiler setup. crt0.o is the object file that contains C-runtime setup code. The linker (what is actually giving the error) should know where this file is if setup properly.
When you installed you should have run make install as the last step without having modified anything since the make step. The configuration step will setup certain variables and such based on the path where it's supposed to be installed.
Where did you get a FreeScale toolchain? I took a look at their site and it seemed only third parties supplied C++ cross-compilers. In the toolchain I get from NetBurner (for use with their hardware) the crt0.o file exists under the gcc-m68k\m68k-elf\lib directory.