#1228 MinGW-w64/MSYS2 cannot build SDL UI

[Carlo Bramini]

Hello,
when linking the executables, the process fails because stdc++ is not added to the list of the libraries to link. When building SDL UI, it should add it, like it has been done for GTK3 UI.

Sincerely.

[gpz]

thats surprising.... since it works fine in linux shrug

[Greg King]

I can build SDL2 with MSYS2.

Did you configure VICE with --enable-sdlui or --enable-sdlui2?

[gpz]

please paste the full configure line.... my guess would be that resid was disabled?

[Carlo Bramini]

Hello,
if you look here:
https://sourceforge.net/p/vice-emu/code/HEAD/tree/trunk/vice/configure.proto#l1224
you will see the addition of stdc++ to LIBS.
But this is added only if these conditions are true:
https://sourceforge.net/p/vice-emu/code/HEAD/tree/trunk/vice/configure.proto#l1108
So, I think that I'm getting the error because I have not installed gtk3 and glib2 libraries in my system, while you probably have in your tree.
It seems to me that there is another place where stdc++ should be added sdlui:
https://sourceforge.net/p/vice-emu/code/HEAD/tree/trunk/vice/configure.proto#l1422
but since a build for Windows will always require that you add "-luserenv" and stc++ static or dynamic, and for both i686 and x86_64 and for both gtk3ui and sdlui, probably it would be worth to move them elsewhere, without extra conditions.

Sincerely.

[Greg King]

Here is a command line that builds SDL2 x64sc on my MSYS2 system:

g++ -std=c++11 -g -O3 -Wall -Wformat -Wformat-signedness -Wshadow -Wpointer-arith -Wstrict-prototypes -Wuninitialized -Wunreachable-code -Wno-unused-parameter -Werror=implicit-function-declaration -Wfatal-errors -Wall -Wno-unused-parameter -Wno-sign-compare -mwindows -I/mingw64/include/SDL2 -Dmain=SDL_main -Ofast -march=native -o x64sc.exe alarm.o attach.o autostart.o autostart-prg.o cbmdos.o cbmimage.o charset.o clipboard.o clkguard.o cmdline.o color.o crc32.o debug.o dma.o embedded.o event.o findpath.o fliplist.o gcr.o info.o init.o initcmdline.o interrupt.o ioutil.o kbdbuf.o keyboard.o lib.o libm_math.o log.o machine-bus.o machine.o main.o network.o opencbmlib.o palette.o ram.o rawfile.o rawnet.o resources.o romset.o screenshot.o snapshot.o socket.o sound.o sysfile.o traps.o util.o vicefeatures.o vsync.o zfile.o zipcode.o midi.o ../src/arch/shared/libarchdep.a ../src/tapeport/libtapeport.a ../src/c64/libc64sc.a ../src/tapeport/libtapeport.a ../src/c64/cart/libc64cartsystem.a ../src/c64/cart/libc64cart.a ../src/c64/cart/libc64commoncart.a ../src/datasette/libdatasette.a ../src/drive/iec/libdriveiec.a ../src/drive/iecieee/libdriveiecieee.a ../src/drive/iec/c64exp/libdriveiecc64exp.a ../src/drive/ieee/libdriveieee.a ../src/drive/libdrive.a ../src/drive/tcbm/libdrivetcbm.a ../src/lib/p64/libp64.a ../src/iecbus/libiecbus.a ../src/parallel/libparallel.a ../src/vdrive/libvdrive.a ../src/sid/libsid.a ../src/monitor/libmonitor.a ../src/joyport/libjoyport.a ../src/samplerdrv/libsamplerdrv.a ../src/sounddrv/libsounddrv.a ../src/mididrv/libmididrv.a ../src/socketdrv/libsocketdrv.a ../src/hwsiddrv/libhwsiddrv.a ../src/iodrv/libiodrv.a ../src/gfxoutputdrv/libgfxoutputdrv.a ../src/printerdrv/libprinterdrv.a ../src/rs232drv/librs232drv.a ../src/diskimage/libdiskimage.a ../src/fsdevice/libfsdevice.a ../src/tape/libtape.a ../src/fileio/libfileio.a ../src/serial/libserial.a ../src/core/libcore.a ../src/viciisc/libviciisc.a ../src/raster/libraster.a ../src/userport/libuserport.a ../src/diag/libdiag.a ../src/rtc/librtc.a ../src/video/libvideo.a ../src/arch/sdl/libarch.a ../src/imagecontents/libimagecontents.a ../src/resid/libresid.a ../src/hvsc/libhvsc.a -lwinmm -lws2_32 -ljpeg -lgif -lpng -lz ../src/arch/sdl/libarch.a ../src/arch/shared/libarchdep.a ../src/arch/sdl/icon.res -lFLAC -lvorbisenc -lvorbisfile -lvorbis -logg -lm -liconv -ldinput -lwinmm -lws2_32 -lntdll -L/mingw64/lib -lmingw32 -lSDL2main -lSDL2 -mwindows -luserenv -lvorbisfile -logg -lvorbis -lvorbisenc -lFLAC -lportaudio -lwinmm

It doesn't link the C++ library explicitly. That library is implied by the g++ command.

What exactly is the error message that you're getting?

[Carlo Bramini]

Hello,
I think that you have found a possible cause of the issue.
When compiling on my side, it does not use g++ but gcc.
I typed the link command on the console, by replacing gcc with g++ and it linked successfully.
Here, I attached:

• the log file generated by configure script: this also includes the command line used for doing the configuration. As you can see, I disabled all I could for making a set of emulator with minimal dependencies.
• The messages on the console when building VICE. I used silent rules and this shows well where the tools CC, CXX, CCLD, etc are used. When the compilation halted, I executed it again with "make V=1" to show the complete list of options and used tools.
  Unfortunately, at the moment I have no idea of the reason behind this difference between our environments. My MSYS2+MinGW-W64 is unmodified, so I would expect that you shoud be able to get my same result if you provide the same configuration command, at least in theory.
  However, since here:
  https://sourceforge.net/p/vice-emu/code/HEAD/tree/trunk/vice/configure.proto#l1224
  libstdc++ is manually added for supporting some type of unknown MinGW cross compiler, but just when gtk3ui is selected, I'm wondering what you would think about moving these lines elsewhere. It should resolve the issue, whatever it is the cause.

As last words, I'm using MSYS2 updated to the latest packages at the time of writing and I'm using Windows 7 Home.

Sincerely.

[Carlo Bramini]

Configuration log.

[Carlo Bramini]

Hello,
I wanted to tell you that I just configured with this command:

/c/cygwin64/home/Carlo/vice-emu-code/vice/configure --enable-sdlui2

Everything has been built successfully and g++ is used instead of gcc in the final linking.
I hope that this additional detail could be useful.
Sincerely.

[compyx]

Has this been resolved? Please try current trunk, we've fixed a linker issue that popped up recently. I've been able to build an SDL2 bindist with msys2.

[Carlo Bramini]

Unfortunately, it is not resolved.
However, I discovered how to isolate the bug on my side.

If I configure with:
--without-resid --with-fastsid
The error happens when linking because gcc is used and libstdc++ is not provided on the command line.

If I configure with:
--with-resid --without-fastsid
or simply if you do not specify those options because this is the default setup, all executables are built without errors.

I hope that this could be useful.
Sincerely.

[gpz]

why the hell would you disable resid though :=)

[Carlo Bramini]

I just verified that this is not limited to MinGW, I have reproduced it also when compiling for linux Debian.

[compyx]

You mean you built a Gtk3 VICE on Debian for Debian (ie native)?

Don't recall that happening when I compiled with various combinations of --with/without-resid/fastsid. I'll have a look.

Edit: but I probably used clang 11, not gcc. So something to check as well.

[compyx]

Oops, missed the 'SDL', let me check that then :)

[compyx]

I 'fixed' the Linux issue by always requiring $(CXX) as the linker. I'll leave it to someone else to fix the msys2 crap.

[compyx]

I tried the msys2 stuff, that also appears to work now. Please check.

[Carlo Bramini]

I confirm that on MinGW-w64 works.
I also wanted to test with a cross compiler but, since it already works on linux and mingw, I think that it will work on it too.
Thank you very much for your support!

PS: I compiled with fastsid rather than resid because I read somewhere in the docs that it is less power hungry for the CPU and I also disabled other stuff because I compiled for an embedded platform.

[Carlo Bramini]

I confirm that it also works with a cross compiler.
I think that this issue is fixed.
Thanks again.

[compyx]

Thanks for testing! closing.