This is on a fairly fresh vanilla Win7 64-bit installation with the latest MinGW64, in a clean (freshly extracted) GLFW 2.7.5 source directory calling their make win32-msys command.
[A] Building the libs
#1 -- Warning at gcc -c -I. -I.. -Wall -mwin32 -O2 -o win32_init.o win32_init.c:
win32_init.c: In function '_glfwPlatformTerminate':
win32_init.c:353:27: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
#2 -- Warning at gcc -c -I. -I.. -Wall -mwin32 -O2 -mdll -DGLFW_BUILD_DLL -D_GLFW_NO_DLOAD_GDI32 -D_GLFW_NO_DLOAD_WINMM -o win32_init_dll.o win32_init.c:
win32_init.c: In function '_glfwPlatformTerminate':
win32_init.c:353:27: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
But the relevant output files do get created in .\lib\win32: glfw.dll, libglfwdll.a and libglfw.a. However I worry those might be corrupted, since it's impossible for me to link to them via gcc later on -- same problem as the last one in this post described further down.
[B] Building the examples
#3 -- Warning at triangle.exe, pong3d.exe, splitview.exe, mipmaps.exe, gears.exe, boing.exe, wave.exe, heightmap.exe:
c:/mingw64/x86_64-w64-mingw32/bin/ld.exe: warning: cannot find entry symbol _mainCRTStartup; defaulting to 0000000000401000
Not so however for listmodes.exe, mthello.exe, mtbench.exe and particles.exe which build fine. Indeed those 4 are the only ones running properly here afterwards, the others just exit immediately without outputs or errors (naturally, since there is no valid entry point for them).
[C] Building the tests
Warning at accuracy.exe, dynamic.exe:
c:/mingw64/x86_64-w64-mingw32/bin/ld.exe: warning: cannot find entry symbol _mainCRTStartup; defaulting to 0000000000401000
No such problem for defaults.exe. For dynamic.exe it then proceeds with the following errors:
C:\Users\roxor\AppData\Local\Temp\cc8hsorn.o:dynamic.c:(.text.startup+0x1c): undefined reference to `__imp_glfwGetVersion'
C:\Users\roxor\AppData\Local\Temp\cc8hsorn.o:dynamic.c:(.text.startup+0x62): undefined reference to `__imp_glfwInit'
C:\Users\roxor\AppData\Local\Temp\cc8hsorn.o:dynamic.c:(.text.startup+0xcf): undefined reference to `__imp_glfwOpenWindow'
C:\Users\roxor\AppData\Local\Temp\cc8hsorn.o:dynamic.c:(.text.startup+0x10b): undefined reference to `__imp_glfwSetWindowTitle'
C:\Users\roxor\AppData\Local\Temp\cc8hsorn.o:dynamic.c:(.text.startup+0x118): undefined reference to `__imp_glfwSetWindowSizeCallback'
C:\Users\roxor\AppData\Local\Temp\cc8hsorn.o:dynamic.c:(.text.startup+0x123): undefined reference to `__imp_glfwSwapInterval'
C:\Users\roxor\AppData\Local\Temp\cc8hsorn.o:dynamic.c:(.text.startup+0x14a): undefined reference to `__imp_glfwGetWindowParam'
C:\Users\roxor\AppData\Local\Temp\cc8hsorn.o:dynamic.c:(.text.startup+0x151): undefined reference to `__imp_glfwSwapBuffers'
C:\Users\roxor\AppData\Local\Temp\cc8hsorn.o:dynamic.c:(.text.startup+0x174): undefined reference to `__imp_glfwTerminate'
collect2: ld returned 1 exit status
make[1]: *** [dynamic.exe] Error 1
make[1]: Leaving directory `/c/glfw64/tests'
make: *** [win32-msys] Error 2
Now this latter one is the test program for loading the DLL. You might think that's simply missing the necessary libs (.a and .dll) in the correct places, but do note at this very point I DID have all the necessary includes and libs (from an earlier GLFW make that was exactly the same as the above, same versions, same warnings, same output files) in the correct places:
libglfwdll.a in \MinGW64\x86_64-w64-mingw32\lib (next to libglu32.a, libopengl32.a)
glfw.h in \MinGW64\x86_64-w64-mingw32\include\GL (next to gl.h, glaux.h, glu.h)
glfw.dll in \windows and \windows\system32 (next to opengl32.dll, glu32.dll)
Problem A is harmless but I've added an additional cast to remove the warning. Problems B and C are due to two bugs in GLFW. They have now been fixed, in part thanks to this thread. Thanks for posting it to the GLFW bug tracker and so bringing them to my attention. The fixes will be included in the 2.7.6 release. Until then, you can grab trunk from the GLFW Subversion repository.
Problem C was tricky enough to solve that someone may find a summary useful.
Proper linking for 32-bit requires a .def file with __stdcall decorated symbols, but this file cannot be used for 64-bit. The solution was to have GCC generate the correct .def file for the given architecture.
This is done by linking the DLL twice. First it's linked as exporting __stdcall decorated symbols (the default) and generating the .def file (using -Wl,--output-def,file.def) and then it's linked again without decorations (using --kill-at) to produce the final DLL. This generated .def file can then be used as usual with dlltool to generate the import library.
The most useful resource I found whilst researching this was Stdcall and DLL tools of MSVC and MinGW, which among other things outlines this method.
I got the same error too.
Solved by change the file glfw-2.7.5\tests\Makefile.win32.mingw:12 from
SOLIB = ../lib/win32/libglfwdll.a
to
SOLIB = ../lib/win32/glfw.dll
I ran into the exact same problem and while researching the errors and warning I found a fix for the 'cannot find entry symbol error' warning:
In examples/Makefile.win32.msys and tests/Makefile.win32.msys change the line
WINDOWS = -mwindows -e _mainCRTStartup
to
WINDOWS = -mwindows
Kabie's fix helps with the dynamic linking error
I'm not 100% sure this is a correct solution as I don't completely understand the reason for the alternate entry point name in the first place but at least the tests seem to work and the examples run.
Related
I have recently started using the OpenCascade defeaturing operation and found issues compiling with gcc and link time optimization. When including "#include <BRepAlgoAPI_Defeaturing.hxx>" and using flag "-flto" I get the error:
`_ZThn80_N23BRepAlgoAPI_DefeaturingD1Ev' referenced in section `.rdata$_ZTV23BRepAlgoAPI_Defeaturing[_ZTV23BRepAlgoAPI_Defeaturing]'
of /opt/opencascade/lib/libTKBO.a(BRepAlgoAPI_Defeaturing.cxx.o):
defined in discarded section `.gnu.linkonce.t._ZN23BRepAlgoAPI_DefeaturingD1Ev[_ZThn80_N23BRepAlgoAPI_DefeaturingD1Ev]'
of obj/occt_ops.o (symbol from plugin)
collect2: error: ld returned 1 exit status
make: *** [Makefile:147: occt-test] Error 1
If I understand correctly the defeaturing symbol has been discarded, and is therefore not found. No other changes have been made and it compiles without the -flto flag, so I wonder how can I assure that the symbol will not be discarded? Or what could potentially be in the defeaturing code that causes this, as this issue has never come up before?
I've been trying unsuccessfully for a week to get a build of Assimp that is linkable with a project I'm compiling with MinGW.
It seems that the makefiles that cmake generates to build Assimp 4.1.0 are flawed somehow because when I try to use them I get some warnings which ultimately lead to a failure when trying to link "libassimp.dll"
CMakeFiles\assimp.dir/objects.a(Exporter.cpp.obj):Exporter.cpp:(.text+0x1571): undefined reference to `Assimp::ExportScene3MF(char const*, Assimp::IOSystem*, aiScene const*, Assimp::ExportProperties const*)'
collect2.exe: error: ld returned 1 exit status
code\CMakeFiles\assimp.dir\build.make:3159: recipe for target 'code/libassimp.dll' failed
mingw32-make[2]: *** [code/libassimp.dll] Error 1
CMakeFiles\Makefile2:289: recipe for target 'code/CMakeFiles/assimp.dir/all' failed
mingw32-make[1]: *** [code/CMakeFiles/assimp.dir/all] Error 2
Makefile:131: recipe for target 'all' failed
mingw32-make: *** [all] Error 2
Before it gets to this the only error it seems is a format error in certain header files which use the %llu conversion type when referencing the ai_snprintf function.
warning: unknown conversion type character 'l' in format [-Wformat=]
warning: too many arguments for format [-Wformat-extra-args]
I'm using the latest MinGW which has g++ version 6.3.0, by default using the c++14 standard. I did a test to see if this standard on windows didn't support %llu but when I wrote a CMakeLists.txt file, generated a makefile, and compiled using the makefile, it gave no errors and ran as expected.
I've tried using cmake to generate a Visual Studio 2017 project and building it there and it links fine when used in Visual Studio. If I call the same functions and compile with MinGW it doesn't link, I guess this is just an interoperability problem, but it suggests I have everything assimp needs to be built properly.
My thoughts are, somehow assimp's cmake modules are defining what standard assimp should be compiled with, and that standard doesn't support %llu, but that sounds silly. I don't like to assume something is a bug but these warnings don't seem like they're thrown because I forgot to do something.
I've tried editing the makefile it gives me and adding to the front:
CXX = g++
CXXFLAGS = -Wall -std=c++11 $(DEBUG)
Cause somewhere it said that could work, but it didn't change anything.
I also tried defining the macro __USE_MINGW_ANSI_STDIO 1 for cmake but that didn't do anything either.
But I really don't know much about building binaries (though I've learned more than I expected to recently), so any advice, information, guidance is appreciated.
I am compiling a C++ program using make, this is the error i'm getting.
/usr/bin/ld: fglut/libfglut.a(freeglut_state.o): undefined reference to symbol 'XGetWindowAttributes'
//usr/lib/i386-linux-gnu/libX11.so.6: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
Makefile:55: recipe for target 'morphlines' failed
make: *** [morphlines] Error 1
I'm beginner
/usr/bin/ld: fglut/libfglut.a(freeglut_state.o):
This tells me you link libfglut statically (*.a is just an archive of object files). When you do this, you must link all dependencies as well, because with the object files from the static library actually compiled into your program, your program will depend on them.
Either link libfglut dynamically (this is the default with the GNU toolchain), so your program will depend on libfglut.so which will itself depend on libX11.so -- or add -lX11 after -lfglut on the command line of your final linking step. You might need -Wl,-Bdynamic before -lX11 to switch the linker back to dynamic linking.
If this doesn't directly solve your problem, I suggest you edit your question to include the relevant parts of the Makefile you're using.
I am trying to build CEF in Release mode but I get the following linker error:
AR(target)
/home/adminuser/temp/build/linux/Release/obj.target/libcef_dll_wrapper.a
LINK(target) /home/adminuser/temp/build/linux/Release/cefclient
/home/adminuser/temp/build/linux/Release/ldb.a(ldbJS.o): In function
LdbURLLoader::LoadURL(std::string)': ldbJS.cpp:(.text+0x34e):
undefined reference toCefURLRequest::Create(CefRefPtr,
CefRefPtr)' collect2: error: ld returned 1 exit
status make: *** [/home/adminuser/temp/build/linux/Release/cefclient]
Error 1
I don't get this problem when building the Debug version so I am not quite sure how to resolve it. I tried various #pragma directives to stop the compiler from optimizing out this method but to no avail.
* UPDATE *
When I remove the -DNDEBUG flag from CFLAGS_Release in the libcef_dll_wrapper.target.mk file it will build. I don't want to do this in the Release build without knowing what I'm doing though.
I am using gcc 4.8.2.
It turns out forcing the LD linker to reanalyze my libraries was the solution. The CEF application already had an elaborate scheme of makefiles that used the --start-group and --end-group indicators to do this, but the library I previously added was not included with them. I added it and linked my application without any more problems!
I have been writing some python extension modules with cython. The extensions I've written build and work well. Then, I wanted to use typed memoryviews, when accessing my numpy arrays, as they seem to have several advantages http://docs.cython.org/src/userguide/memoryviews.html
However, as soon as I use a memoryview in my cython code I will get an error when building the extension. For example, if I add this test line:
cdef double[:, ::1] X = np.zeros((100, 100))
to an existing, working cython extension. I will get the following errors:
C:\MinGW\bin\gcc.exe -shared -s build\temp.win32-2.7\Release\image_box.o build\temp.win32-2.7\Release\image_box.def -Lc:\python27\libs -Lc:\python27\PCbuild -lp
ython27 -lmsvcr90 -o x:\ARframework\python\image_ops\image_box.pyd
build\temp.win32-2.7\Release\image_box.o:image_box.c:(.text+0xe23): undefined reference to `___sync_fetch_and_add_4'
build\temp.win32-2.7\Release\image_box.o:image_box.c:(.text+0x3318): undefined reference to `___sync_fetch_and_add_4'
build\temp.win32-2.7\Release\image_box.o:image_box.c:(.text+0x4c81): undefined reference to `___sync_fetch_and_sub_4'
build\temp.win32-2.7\Release\image_box.o:image_box.c:(.text+0x4d37): undefined reference to `___sync_fetch_and_sub_4'
build\temp.win32-2.7\Release\image_box.o:image_box.c:(.text+0x10767): undefined reference to `___sync_fetch_and_sub_4'
build\temp.win32-2.7\Release\image_box.o:image_box.c:(.text+0x10793): undefined reference to `___sync_fetch_and_sub_4'
collect2.exe: error: ld returned 1 exit status
error: command 'gcc' failed with exit status 1
I've tried to add -march=i486 to the gcc line, as suggested in this post:
undefined reference to sync_fetch_and_add_4
but that didn't solve the problem. For that matter, I also tried -march=i586 and -march=pentium without success.
Any idea what's going on here?
My platform is Windows 7, mingw version is 4.70, Cython version is 0.17.1
Thanks
I found a solution.
Actually, the gcc flag -march=i486 does solve the problem! However, when I tested it in the console I just applied it to the gcc line for the link step (that's where I got the errors) and as it didn't solve the problem I thought it just didn't work.
In fact, I need to use -march=i486 both in the compile and link steps, then there is no errors anymore.
As to how to include these flags when I build the extension, I have tried to add
import os
os.environ['LDFLAGS'] = '-march=i486'
os.environ['CFLAGS'] = '-march=i486'
to the setup.py but it didn't seem to work.
So I have modified the c:\python27\Lib\distutils\cygwinccompiler.py to include these flags in the compile and link steps. Not sure if this is very elegant way of setting these flags. Any alternatives are welcome!