I am making a game in SDL2 and C++. I use a makefile with mingw32 in visual stuido code. Because I am using SDL2 I want to use the SDL2 dll's. It works with all the dll's in the main project directory but not if I put them in the folder they are supposed to be in.
This is my make file:
all:
g++ -o main main.cpp entity.cpp entity.hpp player.cpp player.hpp -Isrc/Include -Lsrc/lib -lmingw32 -lSDL2main -lSDL2 -lSDL2_image
When I open the .exe that was made with the make command:
I do not get any errors when I make the .exe, but when I try to open it this is what I get. As stated above, these problems do not affect me if I have all the dll's in the main directory.
If I change the makefile to contain the directory of the dll's I get errors when trying to make the exe.:
g++ -o main main.cpp entity.cpp entity.hpp player.cpp player.hpp -Isrc/Include -Lsrc/lib -lmingw32 -lsrc/lib/SDL2main -lsrc/lib/SDL2 -lsrc/lib/SDL2_image
D:/mingw32/bin/../lib/gcc/i686-w64-mingw32/8.1.0/../../../../i686-w64-mingw32/bin/ld.exe: cannot find -lsrc/lib/SDL2main
D:/mingw32/bin/../lib/gcc/i686-w64-mingw32/8.1.0/../../../../i686-w64-mingw32/bin/ld.exe: cannot find -lsrc/lib/SDL2
D:/mingw32/bin/../lib/gcc/i686-w64-mingw32/8.1.0/../../../../i686-w64-mingw32/bin/ld.exe: cannot find -lsrc/lib/SDL2_image
collect2.exe: error: ld returned 1 exit status
make: *** [all] Error 1
Related
After upgrading python 3.8.6 to 3.9.10 using homebrew, my Cython extensions no longer without explicitly adding /usr/local/include (for my Intel MacBook) or /opt/homebrew/include to the include_dirs of my extension.
My setup.py.in:
import os, sys
from numpy.distutils.core import setup, Extension
from Cython.Build import cythonize
link_arguments = []
extra_include_dirs = []
if (sys.platform == 'darwin'):
link_arguments.append("-Wl,-rpath")
link_arguments.append("-Wl,#loader_path/")
if os.path.exists('/opt/homebrew/'):
extra_include_dirs.append("/opt/homebrew/include/")
else:
extra_include_dirs.append("/usr/local/include/")
else:
link_arguments.append("-Wl,-rpath=${CMAKE_SOURCE_DIR}/lib/")
pynwp_extension = Extension(
name="pynwp",
sources=["${CMAKE_CURRENT_SOURCE_DIR}/lambert.f90", "${CMAKE_CURRENT_SOURCE_DIR}/pynwp.f90", "${CMAKE_CURRENT_SOURCE_DIR}/readAtmosphereGen.f90", "${CMAKE_CURRENT_SOURCE_DIR}/ptogrot.f", "${CMAKE_CURRENT_SOURCE_DIR}/bilin1.f", "${CMAKE_CURRENT_SOURCE_DIR}/fl2pres_f.f","${CMAKE_CURRENT_SOURCE_DIR}/message.c","${CMAKE_CURRENT_SOURCE_DIR}/gridWindDirCorrection.F"],
libraries=["HirlamUtils_fPIC", "eccodes_f90", "jasper"],
library_dirs=["${PROJECT_BINARY_DIR}", "${CMAKE_SOURCE_DIR}/build${CMAKE_BUILD_TYPE}/src/libHirlamUtils/", "/opt/homebrew/lib/"],
extra_link_args = link_arguments,
include_dirs=["${CMAKE_SOURCE_DIR}/include", "/usr/lib64/gfortran/modules/",
"${CMAKE_SOURCE_DIR}/build${CMAKE_BUILD_TYPE}"] + extra_include_dirs,
extra_f90_compile_args=["-DLINUX", "-DIS_LITTLE_ENDIAN", "-DUSEWALLTIME", "-DHAS_BLAS", "-DHAS_LAPACK", "-DGRIB32", "-DTIMING", "-DPREC32", "-fno-whole-file", "-g", "-fbounds-check"]
#compiler_directives={'language_level' : "3"}
)
setup(name="pynwp",
author="me",
author_email="me!me.com",
version="1.0.1",
description="Python wrapper for pynwp",
package_dir={"": "${CMAKE_CURRENT_SOURCE_DIR}"},
url="http://emaddc.eu",
license="MIT License",
ext_modules=[pynwp_extension]
)
In the file above, I have hardcoded the location (temporarily) of the homebrew library dir and added some functionality for the include dir based on /opt/homebrew being found. If I remove this from the file, compilation fails as eccodes.mod cannot be found, see the output when I run the command generate by python/CMake manually:
buildDebug git:(master) ✗ /opt/homebrew/bin/gfortran -Wall -g -fno-second-underscore -fPIC -O3 -funroll-loops -I<project_dir>//include -I/usr/lib64/gfortran/modules/ -I<project_dir>//buildDebug -Ibuild/src.macosx-12-arm64-3.9/build/src.macosx-12-arm64-3.9 -I/opt/homebrew/lib/python3.9/site-packages/numpy/core/include -Ibuild/src.macosx-12-arm64-3.9/numpy/distutils/include -I/opt/homebrew/opt/python#3.9/Frameworks/Python.framework/Versions/3.9/include/python3.9 -c -c <project_dir>//src/pynwp/readAtmosphereGen.f90 -o build/temp.macosx-12-arm64-3.9<project_dir>//src/pynwp/readAtmosphereGen.o -DLINUX -DIS_LITTLE_ENDIAN -DUSEWALLTIME -DHAS_BLAS -DHAS_LAPACK -DGRIB32 -DTIMING -DPREC32 -fno-whole-file -g -fbounds-check
f951: Warning: Nonexistent include directory '/usr/lib64/gfortran/modules/' [-Wmissing-include-dirs]
f951: Warning: Nonexistent include directory 'build/src.macosx-12-arm64-3.9/build/src.macosx-12-arm64-3.9' [-Wmissing-include-dirs]
f951: Warning: Nonexistent include directory 'build/src.macosx-12-arm64-3.9/numpy/distutils/include' [-Wmissing-include-dirs]
<project_dir>//src/pynwp/readAtmosphereGen.f90:3:7:
3 | use eccodes
| 1
Fatal Error: Cannot open module file 'eccodes.mod' for reading at (1): No such file or directory
compilation terminated.
This extension is part of a larger project that is build using CMake. When running the gfortran command manually, the same errors indicating that eccodes.mod cannot be found. The file is however located on a default location on the gfortran/gcc search path:
locate eccodes.mod
/opt/homebrew/Cellar/eccodes/2.24.2/include/eccodes.mod
/opt/homebrew/include/eccodes.mod
And the search path for gfortran:
gfortran -E -Wp,-v -
#include <...> search starts here:
/opt/homebrew/include
/opt/homebrew/Cellar/gcc/11.2.0_3/bin/../lib/gcc/11/gcc/aarch64-apple-darwin21/11/include
/opt/homebrew/Cellar/gcc/11.2.0_3/bin/../lib/gcc/11/gcc/aarch64-apple-darwin21/11/include-fixed
/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/usr/include
/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/System/Library/Frameworks
End of search list.
Another project uses gcc/ld and has a similar problem. I need to explicitly add LINK_DIRECTORIES(/opt/homebrew/lib) to CMakeList.txt in order for gcc to find the eccodes library. Without that, I get:
gcc-11: warning: this compiler does not support X86 (arch flags ignored)
ld: library not found for -leccodes
collect2: error: ld returned 1 exit status
make[2]: *** [src/smoothModeS-v51/smoothModeS-v51.x] Error 1
make[1]: *** [src/smoothModeS-v51/CMakeFiles/smoothModeS-v51.x.dir/all] Error 2
make: *** [all] Error 2
Adding the paths to CPATH and LIBRARY_PATH had no effect.
This method works but seems hard to maintain. What am I missing and what has changed that gfortran/gcc no longer search in the default paths for but libraries and headers/modules?
EDIT
Just found that the standalone executable that uses similar code as the python extension and also uses eccodes has a similar issue. If I do not include INCLUDE_DIRECTORIES(/opt/homebrew/include) in CMakeLists.txt , I get:
cd <project_dir>/buildDebug/src/collocEHS && /opt/homebrew/bin/gfortran -I<project_dir>/buildDebug -I<project_dir>/include -I<project_dir>/src/readASTERIX2 -I<project_dir>/src/geomag70_linux -I<project_dir>/src/libDTG -fallow-argument-mismatch -ffpe-trap=invalid,zero,overflow -DPREC32 -DLINUX -DIS_LITTLE_ENDIAN -DUSEWALLTIME -DHAS_BLAS -DHAS_LAPACK -DGRIB32 -DTIMING -ffixed-line-length-none -g -fcheck=all -Wall -fcheck=bounds -O0 -g -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.1.sdk -c <project_dir>/src/pynwp/readAtmosphereGen.f90 -o CMakeFiles/collocEHSv2.dir/__/pynwp/readAtmosphereGen.f90.o
<project_dir>/src/pynwp/readAtmosphereGen.f90:3:7:
3 | use eccodes
| 1
Fatal Error: Cannot open module file 'eccodes.mod' for reading at (1): No such file or directory
compilation terminated.
make[2]: *** [src/collocEHS/CMakeFiles/collocEHSv2.dir/__/pynwp/readAtmosphereGen.f90.o] Error 1
make[1]: *** [src/collocEHS/CMakeFiles/collocEHSv2.dir/all] Error 2
make: *** [all] Error 2
So I guess the problem is unrelated to python but more with gcc/gfortran (gcc version 11.2.0 (Homebrew GCC 11.2.0_3).
EDIT 2
A reboot of the laptop fixed the issue with the python extension build and setup.py requiring additional directories. For normal builds using CMake, I still require the extra INCLUDE_DIRECTORIES and LINK_DIRECTORIES order for gcc/gfortran to find libraries installed by brew in /opt/homebrew (or /usr/local for intel MacBook).
As per homebrew devs, this is desired behaviour: /opt/homebrew and /usr/local are "special" directories to be manually added in e.g., CMake projects. This is explained in my bug report on home-brew's GitHub, see https://github.com/Homebrew/homebrew-core/issues/95561.
I haven't been able to confirm this with documentation.
I'm triing to compile the superoptimizer on windows. (https://github.com/bonzini/superopt)
Unfortunatly my knowledge of make is very limited. I tried:
make CPU=-D386 superopt
Which gives me the error:
cc superopt.c -o superopt
process_begin: CreateProcess(NULL, cc superopt.c -o superopt, ...) failed.
make (e=2): The system cannot find the file specified.
make: *** [superopt] Fehler 2
After setting the compiler to gcc manually with:
make CPU=-D386 superopt CC=gcc
I get the following error:
gcc superopt.c -o superopt
In file included from superopt.c:27:0:
superopt.h:104:2: error: #error You have to choose target CPU type (--with-arch).
#error You have to choose target CPU type (--with-arch).
^
In file included from superopt.h:130:0,
from superopt.c:27:
longlong.h:1465:14: error: unknown type name 'UQItype'
extern const UQItype __clz_tab[];
^
superopt.c:32:21: fatal error: version.h: No such file or directory
compilation terminated.
make: *** [superopt] Fehler 1
It seems it does't properly selects i386.
Any hints would be greatly appreciated.
That is not the source code of
GNU superopt. It is the source code of someone's project
to patch GNU superopt, last updated 2008, and seemingly
abandoned a hard-hat area.
This is the source code of
GNU superopt. Extract the tarball and build as you have attempted
with:
make CC=gcc CPU=-DI386 superopt
Note: I386, not 386.
You will see warnings like:
warning: incompatible implicit declaration of built-in function 'foo'
because the 20 yearold C code does not diligently include the standard
headers that prototype the standard functions that it calls, but superopt will build successfully.
I was learning OpenGL using GLFW, and didn't have a great understanding of makefiles at the time. I had OpenGL working, but I decided to learn makefiles more. I came up with this after a lot of websites, hours, and trial and error:
EXENAME = "OpenGL Demo"
CC = gcc
SRCS = ../src/OpenGLDemo.c
OBJS = $(SRCS: .c = .o)
CFLAGS = -Wall -g -c
LIBS = -L./libs -lglfw3 C:/Windows/SysWOW64/opengl32.dll C:/Windows/SysWOW64/glu32.dll
all: opengldemo exe
exe: $(OBJS)
$(CC) $(OBJS) -o $(EXENAME) $(LIBS)
opengldemo: ../src/OpenGLDemo.c
$(CC) $(CFLAGS) ../src/OpenGLDemo.c
clean:
rm -f $(EXENAME)
rebuild: clean all
But, when I compile, it gives this error when it tries to build the executable:
collect2: error: ld terminated with signal 11 [Segmentation fault], core dumped
makefile:11: recipe for target 'exe' failed
make: *** [exe] Error 1
It does build an executable, but my computer says it can't run it.
I tried searching the internet, and found gcc bug reports including this error. There is probably something stupid that I am doing to get this error.
How do I fix this error, and what does it mean?
EDIT: Full output:
make
gcc -Wall -g -c ../src/OpenGLDemo.c
gcc ../src/OpenGLDemo.c -o "OpenGL Demo" -L./libs -lglfw3
C:/Windows/SysWOW64/opengl32.dll C:/Windows/SysWOW64/glu32.dll
cygwin warning:
MS-DOS style path detected: C:/Windows/SysWOW64/opengl32.dll
Preferred POSIX equivalent is: /cygdrive/c/Windows/SysWOW64/opengl32.dll
CYGWIN environment variable option "nodosfilewarning" turns off this warning.
Consult the user's guide for more details about POSIX paths:
http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
collect2: error: ld terminated with signal 11 [Segmentation fault], core dumped
makefile:11: recipe for target 'exe' failed
make: *** [exe] Error 1
I came across exactly the same error.
I'm developing on Windows and Linux at the same time and use Filezilla to transfer my files. The code built previously on Windows with Cygwin, but wouldn't after downloading files from my Linux host.
The process was build on Windows ==> upload to Linux and build ==> make a few changes ==> download to Windows and build ==> get error.
Then it dawned on me I had transferred over the Linux object files with the source, so I erased all the .o files and the build went fine.
I can't say if this was #Zaerospi's problem or not, but it seems to have been the source of my error.
Anyone else with the same error may want to try erasing their object files and rebuilding.
It means that the ld tool or one of its dependencies has a bug which results in an invalid memory access (segmentation fault) on which the operating system kills the process with SIGSEGV (signal 11). It should not crash regardless of your build setup.
You should probably file a bug report for ld with your Linux distribution vendor or directly to the vendor of the ld tool (usually GNU in case your ld tool is from the GNU binutils).
I am using a java program. It automatically creates log files in a directory, but I am doing that myself a different way with tee. I cannot find an easy way to disable the logs, so I am resorting to using nullfs.
I cloned it with
git clone https://github.com/xrgtn/nullfs.git
and I ran
make nul1fs
as instructed. It terminates within a second, with the following output:
cc "-lfuse" nul1fs.c -o nul1fs
nul1fs.c:13:18: fatal error: fuse.h: No such file or directory
compilation terminated.
make: *** [nul1fs] Error 1
I tried apt-get source fuse and copying fuse.h into the nullfs directory, but nothing changed.
I have FUSE installed. I'm running Debian wheezy x86_64.
You need the development package of FUSE, which contains the fuse.h you're missing. Do a apt-get install libfuse-dev and it should work.
Copying the header file in the source directory did not work, because in nul1fs.c you'll notice that fuse.h is included with angle brackets. This means, the header file will be searched in the system-wide include paths. That usually means /usr/include.
Note that you then may run into this error:
$ make nul1fs
cc "-lfuse" nul1fs.c -o nul1fs
/tmp/ccbt0X7c.o: In function `main':
nul1fs.c:(.text+0x3c3): undefined reference to `fuse_main_real'
collect2: error: ld returned 1 exit status
make: *** [nul1fs] Error 1
It's a documented bug with a workaround: put the linker flags after the file lists. I.e. compile nul1fs with:
cc nul1fs.c -o nul1fs -lfuse
and not with make nul1fs, which boils down to
cc -lfuse nul1fs.c -o nul1fs
I have followed the instruction on the "GMP Install Instruction for Windows Platform". I could build a 32bit version of GMP which can be used for Visual Studio.
./configure --prefix=${gmp-install} --disable-static --enable-shared
make
make install
Then I installed mingw_w64 and msys on another machine (which is running 64bit Windows) and rerun the commands.
./configure was run without any problem. However, when I run "make", I got the following.
m4 -DHAVE_CONFIG_H -D__GMP_WITHIN_GMP -DOPERATION_add_n -DDLL_EXPORT -DPIC add_n.asm >tmp-add_n.s
gcc -std=gnu99 -c -DHAVE_CONFIG_H -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_add_n -O2 -pedantic -fomit-frame-pointer -mno-cygwin tmp-add_n.s -DDLL_EXPORT -DPIC -o .libs/add_n.o
tmp-add_n.s: Assembler messages:
tmp-add_n.s:84: Error: operand type mismatch for `push'
tmp-add_n.s:85: Error: operand type mismatch for `push'
tmp-add_n.s:86: Error: operand type mismatch for `push'
tmp-add_n.s:107: Error: operand type mismatch for `jmp'
tmp-add_n.s:114: Error: operand type mismatch for `pop'
tmp-add_n.s:115: Error: operand type mismatch for `pop'
tmp-add_n.s:116: Error: operand type mismatch for `pop'
make[2]: *** [add_n.lo] Error 1
make[2]: Leaving directory `/d/Temp/gmp-5.0.1/mpn'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/d/Temp/gmp-5.0.1'
make: *** [all] Error 2
If I used "gmake" instead, the following error was shown.
m4 gcc -DHAVE_CONFIG_H -D__GMP_WITHIN_GMP -DOPERATION_add_n -DDLL_EXPORT -DPIC add_n.asm >tmp-add_n.s
m4: gcc: No such file or directory
gmake[2]: *** [add_n.lo] Error 1
gmake[2]: Leaving directory `d:/Temp/gmp-5.0.1/mpn'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory `d:/Temp/gmp-5.0.1'
gmake: *** [all] Error 2
I am not familiar with C++ make. Do I need to specify any flag in order to notify mingw_w64 that I am building for 64bit? Thanks.
For me, gmp was successfully built for x86, and I have had problems building x64. The problem was in the following:
In mpn\fib_table.c:
#if GMP_NUMB_BITS != 32
Error, error, this data is for 32 bits
#endif
while in gmp.h:
#define GMP_LIMB_BITS 64
#define GMP_NAIL_BITS 0
#define GMP_NUMB_BITS (GMP_LIMB_BITS - GMP_NAIL_BITS)
fib_table.c is generated by gen-fix.exe tool, and this tool is generated by make.
So, if one tries to build x64 build after building x86 (like me), it is not enough to run "make clean" first. Delete all "gen-*.exe" files in gmp root folder after running "make clean", this files will be rebuilt properly by make. gmp x64 was successfully build for me after that.
Tested on gmp 6.0.0.
How I built dynamic dll gmp-6.1.2 for windows so that the dll can be linked for a visual studio project.
Setup Environment
Install 7-Zip
Install Cygwin, add the following packages to the default installation
gcc-core
gcc-g++
libgcc
m4
make
cmake
bash
Add the following Environment Variable to the User PATH: C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\bin\Hostx64\x64
This is so you can use the lib command. Your lib.exe may be located elsewhere.
Build GMP
Download the tar.bz2 version from https://gmplib.org/#DOWNLOAD and extract the gmp-6.1.2 folder with 7-zip.
Launch bash.exe from C:\cygwin64\bin.
Change directory to the unzipped gmp-6.1.2 folder. Ex: cd "A:\Code\gmp-6.1.2"
Execute ./configure --disable-static --enable-shared
Execute make
This will create cyggmp-10.dll under A:\Code\gmp-6.1.2\.libs\
Execute make check
Execute cd ./libs
Execute lib /machine:i386 /def:cyggmp-10.dll
This will generate cyggmp-10.exp and cyggmp-10.lib under A:\Code\gmp-6.1.2\.libs\ for use with visual studio
You now have everything needed to call gmp from C# code.
See http://gladman.plushost.co.uk/oldsite/computing/gmp4win.php , and note this paragraph;
GMP cannot, however, provide high
performance 64-bit libraries on
Windows because its 64-bit assembler
code is incompatible with Windows x64
calling conventions. This means that
64-bit GMP libraries on WIndows are
very slow when compared with MPIR,
which has excellent 64-bit assembler
support.
So you either disable assembly with ./configure --disable-assembly or use MPIR.
You might want to take a look at MPIR. It is a fork of GMP that natively supports Visual Studio.
I have tried the following. The library can be built successfully.
./configure --prefix=/d/Temp/gmp-5.0.1-install --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --disable-static --enable-shared