trouble building with MinGW-w64

[onqtam]

basically my problem is this:

https://stackoverflow.com/questions/38673228/multiple-definition-of-dllmaincrtstartup12-while-building-glew-on-windows-wit

and the solution from that answer seems like not the right thing to do.

I commented out this function from glew.c:

int __stdcall DllMainCRTStartup(void* instance, unsigned reason, void* reserved)

everything linked properly.

Here is my cmake for the glew target:

add_library(glew SHARED ${GLEW_DIR}/src/glew.c)
target_compile_options(glew PRIVATE -DGLEW_BUILD)
target_link_libraries(glew PUBLIC opengl32)

And here is the error I get if that function is not commented out:

[100%] Linking CXX shared library ..\..\..\bin\gcc\Release\libplugin_plugin.dll
../../../bin/gcc/Release/libglew.a(glew.c.obj):glew.c:(.text+0x1cf90): multiple definition of `DllMainCRTStartup'
C:/mingw/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.1.0/../../../../x86_64-w64-mingw32/lib/../lib/dllcrt2.o:crtdll.c:(.text+0x3d0): first defined here
collect2.exe: error: ld returned 1 exit status

using this mingw: gcc (x86_64-posix-seh-rev2, Built by MinGW-W64 project) 7.1.0 (taken from here)

Any idea why this might be happening?

This problem was not present in versions of glew older than 2.0 - there the DllMainCRTStartup function was nowhere to be found in glew.c

I traced it all to this commit - but I don't understand the reasons for it... (since then it has been moved to glew_init_tail.c instead of gcc_dll_entry.c)

IMHO something is very wrong here - this does not seem normal. For now I'm gonna stick to 1.13.0 since it doesn't have this problem. There is a deeper issue here...

[nigels-com]

I see. It was part of a broader consolidation of the Windows cmake build. It looks like DllMainCRTStartup was added to make the MinGW build link along with the '-nostdlib' option. In hindsight, it's probably not healthy to link on Windows with that flag.

My recollection is that '-nostdlib' was for the Linux builds to not depend on the C library for string wrangling, etc.

[nigels-com]

GLEW is building fine with Mingw64 on Ubuntu 18.04

Perhaps glew.c ought to conditionally compile the DllMainCRTStartup rather than always for gcc on Windows.

I'll look into some Windows GLEW testing soon, for the upcoming release.

#if defined(_WIN32) && defined(GLEW_BUILD) && defined(__GNUC__)
/* GCC requires a DLL entry point even without any standard library included. */
/* Types extracted from windows.h to avoid polluting the rest of the file. */
int __stdcall DllMainCRTStartup(void* instance, unsigned reason, void* reserved)
{
  (void) instance;
  (void) reason;
  (void) reserved;
  return 1;
}
#endif

$ make SYSTEM=linux-mingw64 all
mkdir lib
x86_64-w64-mingw32-gcc -DGLEW_NO_GLU -DGLEW_BUILD -O2 -Wall -W -Iinclude -fno-builtin -fno-stack-protector  -o tmp/linux-mingw64/default/shared/glew.o -c src/glew.c
x86_64-w64-mingw32-ld -nostdlib -shared -soname libglew32.dll --out-implib lib/libglew32.dll.a     -o lib/glew32.dll tmp/linux-mingw64/default/shared/glew.o  -L/usr/x86_64-w64-mingw32/lib -lopengl32 -lgdi32 -luser32 -lkernel32 
sed \
    -e "s|@prefix@|/usr|g" \
    -e "s|@libdir@|/usr/lib|g" \
    -e "s|@exec_prefix@|/usr/bin|g" \
    -e "s|@includedir@|/usr/include/GL|g" \
    -e "s|@version@|2.2.0|g" \
    -e "s|@cflags@||g" \
    -e "s|@libname@|glew32|g" \
    -e "s|@requireslib@|glu|g" \
    < glew.pc.in > glew.pc
x86_64-w64-mingw32-gcc -DGLEW_NO_GLU -DGLEW_STATIC -O2 -Wall -W -Iinclude -fno-builtin -fno-stack-protector  -o tmp/linux-mingw64/default/static/glew.o -c src/glew.c
ar rv lib/libglew32.a tmp/linux-mingw64/default/static/glew.o
ar: creating lib/libglew32.a
a - tmp/linux-mingw64/default/static/glew.o
mkdir bin
x86_64-w64-mingw32-gcc -DGLEW_NO_GLU -O2 -Wall -W -Iinclude -fno-builtin -fno-stack-protector  -o tmp/linux-mingw64/default/shared/glewinfo.o -c src/glewinfo.c
x86_64-w64-mingw32-gcc -O2 -Wall -W -Iinclude -fno-builtin -fno-stack-protector -o bin/glewinfo.exe tmp/linux-mingw64/default/shared/glewinfo.o -Llib  -lglew32  -L/usr/x86_64-w64-mingw32/lib -lopengl32 -lgdi32 -luser32 -lkernel32
x86_64-w64-mingw32-gcc -DGLEW_NO_GLU -O2 -Wall -W -Iinclude -fno-builtin -fno-stack-protector  -o tmp/linux-mingw64/default/shared/visualinfo.o -c src/visualinfo.c
x86_64-w64-mingw32-gcc -O2 -Wall -W -Iinclude -fno-builtin -fno-stack-protector -o bin/visualinfo.exe tmp/linux-mingw64/default/shared/visualinfo.o -Llib  -lglew32  -L/usr/x86_64-w64-mingw32/lib -lopengl32 -lgdi32 -luser32 -lkernel32

[ericzhang1124]

I select Eclipse as my IDE and met the same question. g++ -o GCCOpenGLTest.exe gccOpenGLTest.o -lopengl32 -lglew32 -lglu32 -lfreeglut D:/DEVAPPS/TDM-GCC-64/bin/../lib/gcc/x86_64-w64-mingw32/5.1.0/../../../../x86_64-w64-mingw32/lib/../lib/glew32.lib: error adding symbols: File in wrong format collect2.exe: error: ld returned 1 exit status

[Baljak]

Same problem with latest MinGW-w64 version using GCC 8.1.

[xantares]

It depends on how you build glew : using cmake is ok as it links with -nostdlib, but in some mingw makefiles it is commented:

$ grep -nr nostdlib src/glew-2.1.0
src/glew-2.1.0/config/Makefile.linux-mingw64:14:#LDFLAGS.EXTRA += -nostdlib
src/glew-2.1.0/config/Makefile.mingw:9:LDFLAGS.EXTRA += -nostdlib
src/glew-2.1.0/config/Makefile.linux-mingw32:14:#LDFLAGS.EXTRA += -nostdlib

So for example if you build with Makefile.mingw you have to pass nostdlib.

I wonder why there are so many crappy Makefiles in their build system, my advice: use cmake.

[nigels-com]

The make files have a longer history than cmake. I still use those for development, although I'd like to slim them down in some areas, eventually. I've been assuming that cmake would make way for something nice, but it doesn't seem that way so far.

[xantares]

glew builds totally fine with cmake, see https://aur.archlinux.org/packages/mingw-w64-glew/

[nigels-com]

Fixed now, thanks.