Dosbox-X 2023.09.01 build process is broken inimfc.cpp:99:32:

[FredBezies]

Describe the bug

I tried to build Dosbox-X 2023.09.01 from source using gcc 13.2.1 but everytime build process stops while processing imfc.cpp.

Here is the error log I got:

imfc.cpp: In instantiation of 'void IMF_LOG(std::string, const Args& ...) [with Args = {}; std::string = std::__cxx11::basic_string<char>]':
imfc.cpp:2037:10:   required from here
imfc.cpp:99:32: error: format not a string literal and no format arguments [-Werror=format-security]
   99 |         LOG(LOG_MISC,LOG_DEBUG)(format.c_str(), args...);
      |         ~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~
cc1plus: note: unrecognized command-line option '-Wno-int-to-void-pointer-cast' may have been intended to silence earlier diagnostics
cc1plus: note: unrecognized command-line option '-Wno-int-to-void-pointer-cast' may have been intended to silence earlier diagnostics
cc1plus: some warnings being treated as errors
make[4]: *** [Makefile:802: imfc.o] Error 1

Steps to reproduce the behaviour

1. Grab 2023.09.01 source code.
2. Apply these configure options: --enable-core-inline --enable-debug --enable-avcodec --prefix=/usr --enable-sdl2
3. Launch make and wait

Expected behavior

Build process going on.

What operating system(s) this bug have occurred on?

Archlinux

What version(s) of DOSBox-X have this bug?

2023.09.01

Used configuration

gcc 13.2.1

Output log

No response

Additional information

No response

Have you checked that no similar bug report(s) exist?

• [X] I have searched and didn't find any similar bug report.

Code of Conduct & Contributing Guidelines

• [X] I agree to follow the code of conduct and the contributing guidelines.

[FredBezies]

I wondered if it was a gcc bug, but I got the same error with llvm 16.0.6.

I tried to build in a clean chroot - to avoid any problems related to my installation - following this guide https://wiki.archlinux.org/title/DeveloperWiki:Building_in_a_clean_chroot without luck.

What is more strange is that I get git commit c340222 to build flawlessly. Weird, weird, weird.

[rderooy]

Can confirm the same issue on fedora 38.

I can also confirm that I can build the last git commit (SDL1 and SDL2).

[FredBezies]

Can confirm the same issue on fedora 38.

I can also confirm that I can build the last git commit (SDL1 and SDL2).

I'm not the only one getting this bug...

I tried to build using a git clone then a git 33c5415305e5b04f7235de44aa8099cb46b5ce8f and it seemed to work. When I try to adapt it for my PKGBUILD, it breaks once again.

Rotten source code? A too sensible C compiler? Weird, weird, weird.

[rderooy]

The flatpak build succeeded, and should be public in the next ~2 hours or so. But flatpak uses an older build environment.

[maron2000]

@FredBezies This is a duplicate of your issue #4237.

[FredBezies]

@FredBezies This is a duplicate of your issue #4237.

In a way, yes but it is a different log output.

It does not explain why up to date git version is building flawlessly. Only 2023.09.01 release is affected here.

[maron2000]

Sure, and since you enabled -Werror=format-security, gcc should abort building and throw an error. There is nothing that DOSBox-X should be blamed that gcc failed to catch that in a particular build.

[FredBezies]

Sure, and since you enabled -Werror=format-security, gcc should abort building and throw an error. There is nothing that DOSBox-X should be blamed that gcc failed to catch that in a particular build.

Ok. But there is one mystery: why git based builds are still OK with this gcc parameters?

I just want to understand that.

By the way, I try using llvm 16 instead of gcc 13.2.1 and it breaks the same way.

Edit: I work around this issue by pasting CFLAGS and CXXFLAGS and removing -Werror=format-security. And it builds successfully. Kinda dirty, but it worked :)

[maron2000]

I tried building the latest commit c340222 (which is of course not the Release version) with -Werror=format-security enabled and g++ aborted with an error. So you have to disable the -Werror=format-security option. You did like https://aur.archlinux.org/cgit/aur.git/commit/?h=dosbox-x-sdl2-git&id=4857ae0bf14b74576d11ce9a55d76cac3a880b81 in the past, is it so dirty?

I show the screenshot below (Sorry that it is displayed in Japanese)

I do agree that it is better to make it buildable regardless of -Werror=format-security option, but it is not a must fix.

[FredBezies]

I tried building the latest commit c340222 (which is of course not the Release version) with -Werror=format-security enabled and g++ aborted with an error.

What's weird is that git version doesn't need modifying CFLAGS and CXXFLAGS. Weird.

So you have to disable the -Werror=format-security option. You did like https://aur.archlinux.org/cgit/aur.git/commit/?h=dosbox-x-sdl2-git&id=4857ae0bf14b74576d11ce9a55d76cac3a880b81 in the past, is it so dirty?

Nearly 3 years ago? I did not remember this bug.

I show the screenshot below (Sorry that it is displayed in Japanese)

Ok.

I do agree that it is better to make it buildable regardless of -Werror=format-security option, but it is not a must fix.

I understand it is not a blocker bug. Just a really annoying one.

[maron2000]

Anyway you have to justify why you don't use the current PKGBUILD settings which disables the said options. Even if the current commit can be built without errors, there is a high possibility that the error occurs again in the future commits, and the error will never occur if you disable the option in the first place.

[FredBezies]

Anyway you have to justify why you don't use the current PKGBUILD settings which disables the said options. Even if the current commit can be built without errors, there is a high possibility that the error occurs again in the future commits, and the error will never occur if you disable the option in the first place.

Looking at my PKGBUILD for dosbox-x-sdl2-git, I found that I applied the same workaround for my previous bug #4237

So it was buildable without problems.

[maron2000]

Oh so there are two PKGBUILDs one for Release version and one for Development version? So nothing weird was going on and that now PKGBUILD for the release version is modified, both versions will be buildable from now on. That's great!

[skitt]

Another way to deal with this is to surround the relevant code with pragmas:

#pragma GCC diagnostic push
#pragma GCC diagnostic warning "-Wformat-security"
template <typename... Args>
void IMF_LOG(std::string format, Args const&... args)
{
    LOG(LOG_MISC,LOG_DEBUG)(format.c_str(), args...);
    /*SDL_LockMutex(m_loggerMutex);
    printf((format + "\n").c_str(), args...); // Causes "error: format not a string literal and no format arguments [-Werror=format-security]" on GCC 13.1.1
    SDL_UnlockMutex(m_loggerMutex);*/
}
#pragma GCC diagnostic pop

[hughobrien]

Encountering this building for NixOS.

imfc.cpp:99:32: error: format not a string literal and no format arguments [8;;https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wformat-security-Werror=format-security8;;]
   99 |         LOG(LOG_MISC,LOG_DEBUG)(format.c_str(), args...);

Can be worked around with hardeningDisable = [ "format" ];