Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Warning on implicit declaration of function 'memset_pattern4' on OSX #3657

Closed
SDLBugzilla opened this issue Feb 11, 2021 · 8 comments
Closed

Comments

@SDLBugzilla
Copy link
Collaborator

This bug report was migrated from our old Bugzilla tracker.

Reported in version: 2.0.12
Reported for operating system, platform: Mac OS X (All), x86_64

Comments on the original bug report:

On 2020-04-23 07:58:49 +0000, LGB wrote:

Recently I get C compiler warning on OSX on every file which includes SDL2.h:

In file included from /usr/local/include/SDL2/SDL.h:32:
In file included from /usr/local/include/SDL2/SDL_main.h:25:
/usr/local/include/SDL2/SDL_stdinc.h:426:5: warning: implicit declaration of function 'memset_pattern4' is invalid in C99 [-Wimplicit-function-declaration]
memset_pattern4(dst, &val, dwords * 4);
^
1 warning generated.

As far as I know (I just google'd for this), memset_pattern4() is in string.h in OSX. So I tried to include string.h before SDL.h, but interestingly the same warning ... But even if it works, I guess SDL should include the right header file for a given function by its own too. Though my project compiles regardless of the warnings, it's ugly, and may have other implications not knowing the prototype well enough by the compiler, I guess.

I use Apple's "gcc" (at least they use this name) which in fact is clang:

Apple clang version 11.0.0 (clang-1100.0.33.8)

System info:

ProductName: Mac OS X
ProductVersion: 10.14.6
BuildVersion: 18G3020

SDL2 is from homebrew:

==> Downloading https://homebrew.bintray.com/bottles/sdl2-2.0.12_1.mojave.bottle.tar.gz

Example build output (using travis-ci.org):

https://travis-ci.org/github/lgblgblgb/xemu/jobs/678485424

Thanks for your attention!

On 2020-04-23 08:57:33 +0000, LGB wrote:

Sorry, I meant "includes SDL.h" not SDL2.h. But from SDL2 :)

On 2020-10-22 13:34:45 +0000, ux wrote:

We have the same problem in our project. It boils down to using SDL.h with POSIX features. Following is a very simple way of reproducing the issue:

echo '#include<SDL.h>' | cc -Wall -Werror=missing-prototypes -D_POSIX_C_SOURCE=200112L $(pkg-config --cflags sdl2) -x c -c -

We use POSIX features for network stuff, and we do actually also have -Werror=missing-prototypes (it's usually a source of important bugs), which makes this warning a fatal error in our case.

On 2020-10-29 07:58:43 +0000, Vitaly Novichkov wrote:

I got on macOS 10.15.7 with the Xcode 11.4.1 the next:


In file included from include/SDL2/SDL_loadso.h:44:
include/SDL2/SDL_stdinc.h:426:5: error: implicit declaration of function 'memset_pattern4' [-Werror,-Wimplicit-function-declaration]
memset_pattern4(dst, &val, dwords * 4);
^

And then:


In file included from include/SDL2/SDL_loadso.h:44:
include/SDL2/SDL_stdinc.h:426:5: error: implicit declaration of function 'memset_pattern4' [-Werror,-Wimplicit-function-declaration]
memset_pattern4(dst, &val, dwords * 4);
^

On 2020-10-29 08:00:23 +0000, Vitaly Novichkov wrote:

I had to use the latest state at the top of Mercurial.

On 2020-10-29 08:01:42 +0000, Vitaly Novichkov wrote:

I got them as errors that broke the build of my project, not just warnings...

On 2020-10-29 11:51:28 +0000, Ozkan Sezer wrote:

Does it help if we define _DARWIN_C_SOURCE at top of SDL_stdinc.h?
Like:

diff --git a/include/SDL_stdinc.h b/include/SDL_stdinc.h
--- a/include/SDL_stdinc.h
+++ b/include/SDL_stdinc.h
@@ -30,6 +30,10 @@

#include "SDL_config.h"

+#ifdef APPLE
+#define _DARWIN_C_SOURCE /* for memset_pattern4() */
+#endif
+
#ifdef HAVE_SYS_TYPES_H
#include <sys/types.h>
#endif

On 2020-10-29 12:31:04 +0000, Vitaly Novichkov wrote:

Booting my macOS machine to verify that...

On 2020-10-29 12:44:50 +0000, Vitaly Novichkov wrote:

Nope, the error is still appear...

Anyway, what I see inside:

This condition blocks the necessary call:

#if __DARWIN_C_LEVEL >= __DARWIN_C_FULL

And the condition that defines the proper __DARWIN_C_LEVEL:

#if   defined(_ANSI_SOURCE)
#define __DARWIN_C_LEVEL        __DARWIN_C_ANSI
#elif defined(_POSIX_C_SOURCE) && !defined(_DARWIN_C_SOURCE) && !defined(_NONSTD_SOURCE)
#define __DARWIN_C_LEVEL        _POSIX_C_SOURCE
#else
#define __DARWIN_C_LEVEL        __DARWIN_C_FULL
#endif

At me I see it has _POSIX_C_SOURCE value.

On 2020-10-29 13:58:25 +0000, Ozkan Sezer wrote:

I am guessing that you include system headers, such as string.h, before
SDL_stdinc.h (or SDL.h), meaning _DARWIN_C_SOURCE has no effect anymore.
I can only suggest that you include SDL_stdinc.h (or SDL.h) before all
system headers. Does it help if you do so?

On 2020-10-29 14:13:14 +0000, Vitaly Novichkov wrote:

I'll check a bit later, however, I can point that problem does happens at here:

https://github.com/WohlSoft/SDL-Mixer-X/blob/master/src/codecs/music_flac.c#L28

the "SDL_assert.h" was loaded before "SDL_loadso.h" which does include of "SDL_stdinc.h" from inside.

On 2020-10-29 14:14:04 +0000, Vitaly Novichkov wrote:

I may guess, the mainstream SDL_mixer will get the same build error too...

On 2020-10-29 14:15:27 +0000, Vitaly Novichkov wrote:

Probably, I will need to try define the _DARWIN_C_SOURCE globally for entire project as a small test...

On 2020-10-29 14:26:35 +0000, Ozkan Sezer wrote:

(In reply to Vitaly Novichkov from comment # 10)

I'll check a bit later, however, I can point that problem does happens at
here:

https://github.com/WohlSoft/SDL-Mixer-X/blob/master/src/codecs/music_flac.
c#L28

the "SDL_assert.h" was loaded before "SDL_loadso.h" which does include of
"SDL_stdinc.h" from inside.

Because SDL_assert.h includes signal.h, and that nullifies _DARWIN_C_SOURCE

That can easily be rectified by flipping the order of SDL_assert.h and
SDL_loadso.h includes in music_flac.c and music_mpg123.c, if that is the
only issue.

On 2020-10-29 15:03:04 +0000, Vitaly Novichkov wrote:

I see, also music_cmd.c got affeted too, native_midi_macosx.c also. effects_internal.c, effect_stereoreserve.c, mixer.c, effect_position.c. To fix them I had to include SDL_stdinc.h at top of all of those files, or move the inclusion of SDL.h into the top of standard includes where also defined.

On 2020-10-29 15:07:21 +0000, Vitaly Novichkov wrote:

Yeh, once I avoided those headers being included after standard headers and the library got built.

I did a commit into new branch for a test and review: WohlSoft/SDL-Mixer-X@2884d7b

On 2020-10-29 15:08:49 +0000, Vitaly Novichkov wrote:

(btw, I forgot to include mpg123 fix as I didn't use it mainly because I didn't made my CMake build for it yet, and therefore I don't use it yet. A good reminder to resume my work and finally make the CMake build for it! I have the working build for Linux, but incomplete for other platforms...)

On 2020-10-29 15:13:43 +0000, Ozkan Sezer wrote:

Is it just me, or does bugzilla not send notification emails again?
(I got none of your replies to this bug.)

On 2020-10-29 15:14:52 +0000, Vitaly Novichkov wrote:

emails

Me too... It got broken again...

On 2020-10-29 17:01:22 +0000, Ozkan Sezer wrote:

I pushed the _DARWIN_C_SOURCE patch from comment # 6 to SDL:
https://hg.libsdl.org/SDL/rev/467540bb2114

Vitaly: I pushed the following patches to SDL_mixer:
https://hg.libsdl.org/SDL_mixer/rev/ec722cc63119
https://hg.libsdl.org/SDL_mixer/rev/fd0f5db8a84c
https://hg.libsdl.org/SDL_mixer/rev/6b1634997479
https://hg.libsdl.org/SDL_mixer/rev/587f28c5c3eb
https://hg.libsdl.org/SDL_mixer/rev/b59a761e3673
https://hg.libsdl.org/SDL_mixer/rev/e180daf91bdd

Please test and tell us whether the issue is resolved.

On 2020-10-29 17:14:37 +0000, Vitaly Novichkov wrote:

Just now I backported all fixes to MixerX, and I gonna to boot up my macOS machine to verify the fix...

On 2020-10-29 17:21:52 +0000, Ozkan Sezer wrote:

(In reply to Vitaly Novichkov from comment # 20)

Just now I backported all fixes to MixerX, and I gonna to boot up my macOS
machine to verify the fix...

For SDL_mixer side: Will mess with music_cmd.c and native_midi later.
(music_cmd is practically a unix thing, but native_midi needs convert
to use SDL_stdinc functions.)

On 2020-10-29 17:24:28 +0000, Vitaly Novichkov wrote:

You missed up the "music_cmd.c" and "native_midi_macosx.c":

WohlSoft/SDL-Mixer-X@795ae1b
WohlSoft/SDL-Mixer-X@e14681c

Also, another minor unrelated fix at native_midi_macosx.c:
WohlSoft/SDL-Mixer-X@eb88f66

On 2020-10-29 17:25:31 +0000, Vitaly Novichkov wrote:

Will mess with music_cmd.c and native_midi later.

I had to fix that at me, and I posted my message too late...

On 2020-10-29 17:34:24 +0000, Ozkan Sezer wrote:

(In reply to Vitaly Novichkov from comment # 22)

You missed up the "music_cmd.c" and "native_midi_macosx.c":

https://github.com/WohlSoft/SDL-Mixer-X/commit/
795ae1b0ac19cf767613f40795726c268e0915b2
https://github.com/WohlSoft/SDL-Mixer-X/commit/
e14681cafb8c4aba2f715dd0d3cb00a0494071c6

Also, another minor unrelated fix at native_midi_macosx.c:
https://github.com/WohlSoft/SDL-Mixer-X/commit/
eb88f66192c70cd24042263432f9fabe9af228d2

https://hg.libsdl.org/SDL_mixer/rev/a094e8411283

On 2020-10-29 17:35:11 +0000, Vitaly Novichkov wrote:

Okay, now build the works!

(I also had to patch the header at SDL 2.0.12 release copy I had to get build of my project)

Seems, because of this case, all past SDL2 versions are broken for newer Xcode toolchains.

On 2020-10-29 17:47:02 +0000, Ozkan Sezer wrote:

(In reply to Vitaly Novichkov from comment # 25)

Okay, now build the works!

(I also had to patch the header at SDL 2.0.12 release copy I had to get
build of my project)

Good. Let's hear from LGB and ux who posted complaints here.

I'll possibly have to adjust other SDL projects for this, too.

On 2020-10-29 20:28:22 +0000, Ozkan Sezer wrote:

I applied include tweaks to SDL_net, SDL_ttf and SDL_image too:
https://hg.libsdl.org/SDL_net/rev/65521c4ca248
https://hg.libsdl.org/SDL_ttf/rev/703ebc7c66fd
https://hg.libsdl.org/SDL_image/rev/fec158a5ebf1

Hopefully everything should be OK.

On 2020-10-30 09:10:00 +0000, ux wrote:

(In reply to Ozkan Sezer from comment # 26)

Good. Let's hear from LGB and ux who posted complaints here.

A quick test shows that the test-case I presented seems addressed, thanks. I'll probably wait for the next release to test in the real-case project though.

On 2020-10-30 09:15:26 +0000, Ozkan Sezer wrote:

(In reply to ux from comment # 28)

A quick test shows that the test-case I presented seems addressed, thanks.
I'll probably wait for the next release to test in the real-case project
though.

OK then, closing as fixed. If issues still show up, please re-open
this and drop a note here.

@joebentley
Copy link

This bug is still occuring for me on macOS Catalina

In file included from /Users/jbentley/code/ones/Source/main.cpp:2:
In file included from /Library/Frameworks/SDL2.framework/Headers/SDL.h:32:
In file included from /Library/Frameworks/SDL2.framework/Headers/SDL_main.h:25:
/Library/Frameworks/SDL2.framework/Headers/SDL_stdinc.h:66:11: warning: non-portable path to file '<String.h>'; specified path differs in case from file name on disk [-Wnonportable-include-path]
# include <string.h>
          ^~~~~~~~~~
          <String.h>
/Library/Frameworks/SDL2.framework/Headers/SDL_stdinc.h:465:5: error: use of undeclared identifier 'memset_pattern4'
    memset_pattern4(dst, &val, dwords * 4);
    ^

@sezero
Copy link
Contributor

sezero commented Aug 25, 2021

Try including SDL.h before other libc headers.

@joebentley
Copy link

That did not work unfortunately. I've resorted to modifying SDL_stdinc.h to remove the problem

@joebentley
Copy link

Ah that does not work because now the .framework file is "damaged" :)

@joebentley
Copy link

I seem to be able to get the homebrew version to work with the modified header

@mansourmoufid
Copy link

If you come across this error when compiling SDL itself, you might have made the mistake of passing --enable-libc=no or --disable-libc to the configure script, like I did... 😅

karlstav added a commit to karlstav/cava that referenced this issue Nov 8, 2021
sdl2 homebrew does not work like it should

libsdl-org/SDL#3657
karlstav added a commit to karlstav/cava that referenced this issue Nov 8, 2021
Byeongchangw added a commit to Byeongchangw/cava that referenced this issue Nov 17, 2022
sdl2 homebrew does not work like it should

libsdl-org/SDL#3657
Byeongchangw added a commit to Byeongchangw/cava that referenced this issue Nov 17, 2022
@AvnishGameDev
Copy link

AvnishGameDev commented Apr 27, 2023

Found a fix for that, just replace 'memset_pattern4(dst, &val, dwords * 4);' with

Uint32 *dst32 = (Uint32*) dst;
Uint32 value = static_cast<Uint32>(val);
size_t i;
for (i = 0; i < dwords * 4; i++)
{
    *dst32++ = value;
}

@CaptainKraft
Copy link

I'm also getting this error.

According to #3334,

memset_pattern4/8/16 is a Darwin extension available in the string.h header. It is available on macOS 10.5+ and iOS 3.0+.

So, I included string.h before including SDL.h and this error goes away for me.

This is probably not a great solution, so perhaps this issue should be reopened?

slouken added a commit that referenced this issue May 1, 2023
This requires including string.h, which isn't always done, so this commit simplifies dependencies on macOS

Fixes #3657
lexi-the-cute pushed a commit to lexi-the-cute/SDL that referenced this issue May 22, 2023
This requires including string.h, which isn't always done, so this commit simplifies dependencies on macOS

Fixes libsdl-org#3657
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants