Multiple definition of '_Unwind_Resume'

Multiple definition of '_Unwind_Resume' - version mismatch?

Frank Drebin

Member #2,987

December 2002

So I compiled my program using

g++ test.cpp -o test -static-libgcc -static-libstdc++ -lallegro_monolith

and I get the following output:

C:/MinGW-w64/x86_64-7.2.0-posix-seh-rt_v5-rev1/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.2.0/libgcc_eh.a(unwind-seh.o): In function `_Unwind_Resume':
C:\mingw720\x86_64-720-posix-seh-rt_v5-rev1\build\gcc-7.2.0\x86_64-w64-mingw32\libgcc/../../../../../src/gcc-7.2.0/libgcc/unwind-seh.c:347: multiple definition of `_Unwind_Resume'
C:/MinGW-w64/x86_64-7.2.0-posix-seh-rt_v5-rev1/mingw64/lib/../lib/liballegro_monolith.dll.a(d000594.o):(.text+0x0): first defined here

I did find several threads about that being a common problem caused by a mismatch between the Allegro binary and the MinGW compiler version. However, I cannot spot the difference in this case both showing up as 'MinGW 7.2.0/x86_64-720-posix-seh-rt_v5-rev1'. What am I missing ::) ?

Brutalo Deluxe 3 | Brutalo Deluxe 2 | BD2 Movie | BDNE 1.29 (C++ TCP Socket Wrapper) | Stats

Edgar Reynaldo

Major Reynaldo

May 2007

Link order matters. Try moving your -static-libgcc and -static-libstdc++ to after the allegro monolith. Otherwise you're linking to the CRT twice.

Eagle and Allegro 5 binaries | Older Allegro 4 and 5 binaries | Allegro 5 compile guide
King Piccolo will make it so Then I could just flip it with some sweet, sweet matrix math. In either case, I’ll ride this wagon until the wheels fall off. Thanks to those that keep it running

Frank Drebin

Member #2,987

December 2002

Unfortunately this did't change the output...

Brutalo Deluxe 3 | Brutalo Deluxe 2 | BD2 Movie | BDNE 1.29 (C++ TCP Socket Wrapper) | Stats

Edgar Reynaldo

Major Reynaldo

May 2007

Well, basically it means you didn't use the same compiler allegro did.

Frank Drebin

Member #2,987

December 2002

OK, but what is the difference in compilers between this

{"name":"611620","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/b\/7\/b7cf1e27e91fb4714f1bdd150d2bf4e0.png","w":899,"h":475,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/b\/7\/b7cf1e27e91fb4714f1bdd150d2bf4e0"}

and this

{"name":"611621","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/8\/6\/8614a86fb770d2b7c428910b2b667662.png","w":530,"h":390,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/8\/6\/8614a86fb770d2b7c428910b2b667662"}
?

Or should I use build revision 0 instead of revision 1 (event though the compiler output says 'x86_64-720-posix-seh-rt_v5-rev1')?

Who compiled the binary package and can tell? SiegeLord?

Brutalo Deluxe 3 | Brutalo Deluxe 2 | BD2 Movie | BDNE 1.29 (C++ TCP Socket Wrapper) | Stats

SiegeLord

Member #7,827

October 2006

There's 2 things here.

First, somehow the Allegro static runtime binaries for 5.2.4 don't actually have the runtime correctly statically linked. I am not sure how that happened.

Second, even testing with the 5.2.3 binaries (which are correctly set up), I still get the same error you're describing. Honestly, it's not obvious to me how this is supposed to work... if you're linking the runtime to the DLL and the exe, surely you're guaranteed to get duplicate definitions. How would it be possible for it to work otherwise?

It sounds like the only usecase for the static runtime DLLs is for them to be used in C programs...

Either way, for you I think you just need to either not worry about static linking the runtime, or link to static Allegro.

"For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18
[SiegeLord's Abode][Codes]:[DAllegro5]:[RustAllegro]

Edgar Reynaldo

Major Reynaldo

May 2007

My binaries don't suffer the same problem. They work correctly when static linking the C and C++ Runtimes.

MinGW-W64, Allegro5, GCC 8.1 binaries

The static libraries shouldn't be linked to anything. They should be static.

Frank Drebin

Member #2,987

December 2002

Thanks guys

This means until I upgrade to MinGW 8.1 and can use ER's binaries I could either do

g++ test.cpp -o test -static-libgcc -static-libstdc++ -lallegro_monolith-static (with the static build of Allegro)

g++ test.cpp -o test -lallegro_monolith (in this case I'll need to include libgcc_s_seh-1.dll, libstdc++-6.dll, libwinpthread-1.dll and allegro_monolith.dll along with the binary)

BTW: I tried Allegro 5.2.2.0 with MinGW 7.2.0 and this seems to work as well...

Brutalo Deluxe 3 | Brutalo Deluxe 2 | BD2 Movie | BDNE 1.29 (C++ TCP Socket Wrapper) | Stats

SiegeLord

Member #7,827

October 2006

Edgar Reynaldo said:

My binaries don't suffer the same problem.

I am skeptical. Can you try compiling and linking this code using Frank's command above?

#include <allegro5/allegro.h>
#include <stdexcept>

int main()
{
  try
  {
    al_init();
  }
  catch(const std::exception& e)
  {

  }
}

Frank Drebin said:

BTW: I tried Allegro 5.2.2.0 with MinGW 7.2.0 and this seems to work as well...

Your original command worked with these binaries?

"For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18
[SiegeLord's Abode][Codes]:[DAllegro5]:[RustAllegro]

Frank Drebin

Member #2,987

December 2002

SiegeLord said:

Your original command worked with these binaries?

Yes, it worked with the original command and Allegro 5.2.2.0. Maybe it works if the compiler version is higher than the compiler that was used to build Allegro

Actually I am wondering why I am the first one to observe this cause I find a lot of threads on the forums that tell people to use the original command to be able to share their programs with others...

Brutalo Deluxe 3 | Brutalo Deluxe 2 | BD2 Movie | BDNE 1.29 (C++ TCP Socket Wrapper) | Stats

SiegeLord

Member #7,827

October 2006

How strange... I tried your original command with my copy of 5.2.2 binaries and it gave me the same error. Where did you get your copy?

Frank Drebin said:

It sort of works if your binary doesn't use exceptions.

"For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18
[SiegeLord's Abode][Codes]:[DAllegro5]:[RustAllegro]

Edgar Reynaldo

Major Reynaldo

May 2007

SiegeLord said:

I am skeptical. Can you try compiling and linking this code using Frank's command above?

It works fine. Both debug and release dynamic and static versions all link fine. static versions link to the static CRT.

My compiler version is the 32 bit posix dwarf version if that matters.

e:\LIBS\LIBS81Distro\Allegro524_mingw-w64-gcc81_posix_dwarf\bin\examples>set A5INCDIR="e:\LIBS\LIBS81Distro\Allegro524_mingw-w64-gcc81_posix_dwarf\include"

e:\LIBS\LIBS81Distro\Allegro524_mingw-w64-gcc81_posix_dwarf\bin\examples>set A5LNKDIR="e:\LIBS\LIBS81Distro\Allegro524_mingw-w64-gcc81_posix_dwarf\lib"

e:\LIBS\LIBS81Distro\Allegro524_mingw-w64-gcc81_posix_dwarf\bin\examples>set A5STATICLIBS= -static -ldumb -lFLAC -ltheora -lvorbisfile -lvorbis -logg -lfreetype -lpng16 -lzlibstatic -ldsound -lgdiplus -luuid -lkernel32 -lwinmm -lpsapi -lopengl32 -lglu32 -luser32 -lcomdlg32 -lgdi32 -lshell32 -lole32 -ladvapi32 -lws2_32 -lshlwapi -static-libstdc++ -static-libgcc

e:\LIBS\LIBS81Distro\MultiSample>g++ -Wall -g -o test.exe -I %A5INCDIR% test.cpp -L %A5LNKDIR% -lallegro_monolith-debug-static %A5STATICLIBS%

e:\LIBS\LIBS81Distro\MultiSample>test.exe

e:\LIBS\LIBS81Distro\MultiSample>

It works even if I link the the dynamic allegro dll and the static CRT.

e:\LIBS\LIBS81Distro\MultiSample>g++ -Wall -O2 -o test.exe -I %A5INCDIR% test.cpp -L %A5LNKDIR% -lallegro_monolith.dll -static-libgcc -static-libstdc++

Frank Drebin

Member #2,987

December 2002

SiegeLord said:

Where did you get your copy?

I took "allegro-mingw-gcc6.2.0-x86-dynamic-5.2.2.zip" from https://github.com/liballeg/allegro5/releases ...

Quote:

It sort of works if your binary doesn't use exceptions.

I am not aware that I use exceptions in my code (unless Allegro's function that I use do so...)

Brutalo Deluxe 3 | Brutalo Deluxe 2 | BD2 Movie | BDNE 1.29 (C++ TCP Socket Wrapper) | Stats

SiegeLord

Member #7,827

October 2006

Frank Drebin said:

I took "allegro-mingw-gcc6.2.0-x86-dynamic-5.2.2.zip" from https://github.com/liballeg/allegro5/releases ...

Yeah, so that worked because it wasn't actually a statically linked dll (see the 'dynamic' in the filename).

Edgar Reynaldo said:

It works even if I link the the dynamic allegro dll and the static CRT.

Now this is astonishing to me, I wonder how this could possibly work. I wonder if this has to do with 32 vs 64 bit exception handling. It's pretty clear that when statically linking the runtime, a part of it will be linked to the Allegro DLL. Then, the linker has to somehow drop the duplicate parts of it from the exe. The only mechanism I know of for this is https://en.wikipedia.org/wiki/Weak_symbol, which is Linux only?

"For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18
[SiegeLord's Abode][Codes]:[DAllegro5]:[RustAllegro]

Frank Drebin

Member #2,987

December 2002

Sorry I am not an expert in this, but why does "allegro-mingw-gcc6.2.0-x86-dynamic-5.2.2.zip" work whereas "allegro-x86_64-w64-mingw32-gcc-7.2.0-posix-seh-dynamic-5.2.4.1.zip" that I used in the first place doesn't?

Brutalo Deluxe 3 | Brutalo Deluxe 2 | BD2 Movie | BDNE 1.29 (C++ TCP Socket Wrapper) | Stats

SiegeLord

Member #7,827

October 2006

It's a mystery . My running hypothesis is that the way official DLLs are compiled is somehow broken in 5.2.4 and maybe 5.2.3. I might play around with the settings soon to see if I can figure it out.

"For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18
[SiegeLord's Abode][Codes]:[DAllegro5]:[RustAllegro]

Edgar Reynaldo

Major Reynaldo

May 2007

The only real solution is not to link the CRT to the dll at all.

Then the end-user can link to whatever they want.

Frank Drebin

Member #2,987

December 2002

OK, let me know if you figured it out...

Brutalo Deluxe 3 | Brutalo Deluxe 2 | BD2 Movie | BDNE 1.29 (C++ TCP Socket Wrapper) | Stats

Edgar Reynaldo

Major Reynaldo

May 2007

You mistake my meaning. When building Allegro, the CRT should not be linked. That's what I'm saying.

SiegeLord

Member #7,827

October 2006

Edgar Reynaldo said:

When building Allegro, the CRT should not be linked.

But that's exactly what the 'static' binaries do. If you don't statically link the runtime, then the user will need to bundle it with their game, because the DLLs will require it. The goal of this exercise is to get an exe + Allegro DLL that do not have a runtime DLL next to them.

"For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18
[SiegeLord's Abode][Codes]:[DAllegro5]:[RustAllegro]

Edgar Reynaldo

Major Reynaldo

May 2007

Which means you are forbidden from linking the CRT. That's what a static library is, a collection of unlinked symbols.

EDIT
SiegeLord, while you're here, where is allegro.log on iOS / OSX?

EDIT2
To elaborate, if you link the Allegro DLL to the dynamic CRT or the static CRT, you are locking your user into using the same one.