Fix build without dlfcn.h

[ffontaine]

Fix the following build failures when dlfcn.h is not available on the toolchain (e.g. uclibc toolchain configured without dynamic library support):

sdl2-2.0.14/src/dynapi/SDL_dynapi.c:234:10: fatal error: dlfcn.h: No such file or directory
  234 | #include <dlfcn.h>
      |          ^~~~~~~~~

sdl2-2.0.14/src/thread/pthread/SDL_systhread.c:45:10: fatal error: dlfcn.h: No such file or directory
   45 | #include <dlfcn.h>
      |          ^~~~~~~~~

Signed-off-by: Fabrice Fontaine fontaine.fabrice@gmail.com

[sezero]

I can't reproduce the issue: I hand-edited SDL_dynapi.h to unconditionally define SDL_DYNAMIC_API
as 0, built usually like ../configure && make, no errors.

[ffontaine]

To get the error, you have to build sdl with a toolchain that don't have dlfcn.h (e.g. an uclibc toolchain configured without dynamic library support). You could reproduce it by renaming/removing dlfcn.h on any "standard" distribution.

[sezero]

Huh. Then the issue has nothing at all to do with SDL_DYNAMIC_API

With the current configuration scripts, the closest thing would be SDL_LOADSO_DLOPEN
but autotools and cmake must be updated to define HAVE_DLFCN_H and/or HAVE_DLOPEN

@slouken, @icculus?

[ffontaine]

Thanks for your feedback, I updated the PR to use SDL_LOADSO_DLOPEN. I'll update it if you have further comments. For example, perhaps it would be better to set SDL_DYNAMIC_API to 0 if SDL_LOADSO_DLOPEN is not defined.

[sezero]

Thanks for your feedback, I updated the PR to use SDL_LOADSO_DLOPEN.

Looks a bit saner, but our configury and cmake'ry must really be updated to
define (or not define) HAVE_DLFCN_H and/or HAVE_DLOPEN, and then
you should use them instead in pthread/SDL_systhread.c. Waiting for comments
from @slouken and/or @icculus for it.

For example, perhaps it would be better to set SDL_DYNAMIC_API to 0 if SDL_LOADSO_DLOPEN is not defined.

That makes sense to me.

[sezero]

Here is something more intrusive, but should do the job properly -I hope-
See attached patch:
dlopen_patch.txt

Comments? @slouken, @icculus: please review.

[sezero]

Here is something more intrusive, but should do the job properly -I hope-

OK, I created #4356 for this

[orbea]

I think this is at least part of the problem... #4367

[slouken]

Is this pull request taken care of by #4356?

[sezero]

Is this pull request taken care of by #4356?

That was my intention, but #4356 has been taking more time than it should
(because I felt lazy with it.)

Maybe you can apply this one as a temporary band-aid for @ffontaine's issue?