SDL_stdinc.h inlines problematic when application not compiled in exact same feature environment

SDL Development
61

Well, not fully C99, but that is good news. Herb Sutter finally gave in,
huh?

Jonny DOn Fri, Jul 5, 2013 at 10:46 AM, Vittorio Giovara < vittorio.giovara at gmail.com> wrote:

In case this thread is still of any interest, m$ announced that visual
studio 2013 will support c99.

http://arstechnica.com/information-technology/2013/06/c99-acknowledged-at-last-as-microsoft-lays-out-its-path-to-c14/
(news is rather old but quite interesting after all).

Cheers,
Vittorio

On Thu, Jun 20, 2013 at 9:15 AM, Vittorio Giovara < vittorio.giovara at gmail.com> wrote:

On Fri, Jun 14, 2013 at 7:33 AM, Sam Lantinga wrote:

SDL_stdinc.h is designed to provide all the C library functionality used
by SDL, for platforms that don’t have the standard C library, or where you
don’t want C library dependencies for some reason.

I made a change so you can define SDL_STDINC_NO_INLINES, and
SDL_stdinc.h won’t define inline versions of the C library functions it
provides.
http://hg.libsdl.org/SDL/rev/728e5f22a82f

Maybe I’m interpreting this in a wrong way, but weren’t compiler macros
discouraged to be used in headers as they are harder to read, document and
maintain?
http://sdl.5483.n7.nabble.com/Proposal-Drop-support-for-software-rendering-in-1-3-tp1144p1175.html(although maybe this thread was referring only to configuration switches).

Also if other language bindings (pascal/java/whatnot) want to use/not use
inlined functions how can they turn it on or off without modifying the
library header itself?

Thanks,
Vittorio

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

62

Okay, this should be fixed in the latest RC candidate:
http://www.libsdl.org/tmp/download-2.0.php

Thanks!On Mon, Jun 10, 2013 at 8:39 PM, Drake Wilson wrote:

This is “interesting” behavior (and breaks my build, but then, I’m doing
something a bit weird):

I’m building SDL 2.0.0 on my main development box, which runs Debian sid
AMD64
with GCC 4.7.3 (Debian 4.7.3-4). The autoconf-based configure for it
detects
functions like strdup and setenv being available, which they are,
provided
the correct feature test macros are active. However, trying to build a
test
application results in:

SDL_stdinc.h: In function ?SDL_setenv_inline?:
SDL_stdinc.h:282:1: error: implicit declaration of function ?setenv?
[-Werror=implicit-function-declaration]
SDL_stdinc.h: In function ?SDL_strdup_inline?:
SDL_stdinc.h:485:1: error: implicit declaration of function ?strdup?
[-Werror=implicit-function-declaration]
SDL_stdinc.h:485:61: error: return makes pointer from integer without a
cast [-Werror]

I’m guessing this is because I’m compiling my application with -std=c99.
If I
use -std=gnu99, for instance, the errors go away, but don’t I lose my more
explicit portability control that way. I’d just as soon not have so much
transitive header cruft anyway (cf. SDL_syswm.h not being included by
default),
but a lot of the public headers depend on SDL_stdinc.h; a cursory glance
suggests that they mainly depend on it for types, so I’m not sure why all
the
inlines are stuffed in there too.

My current intended workaround is to just strip all the inline functions
from
that file manually, but this seems fragile as well and might wind up
requiring
me to keep a local fork if I juggle build environments enough.

Any recommendation on how best to handle this?

—> Drake Wilson

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

63

Anyone have any suggestions for getting libtiff built on OSX?==========
Just so you can see what happens when you combine a language
like C with programmers that think they’re God:

~/tiff/libtiff>make
Making all in port
make[1]: Nothing to be done for `all’.
Making all in libtiff
make all-am
/bin/sh …/libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -g -O2 -Wall -W -MT tif_jpeg.lo -MD -MP -MF .deps/tif_jpeg.Tpo -c -o tif_jpeg.lo tif_jpeg.c
libtool: compile: gcc -DHAVE_CONFIG_H -I. -g -O2 -Wall -W -MT tif_jpeg.lo -MD -MP -MF .deps/tif_jpeg.Tpo -c tif_jpeg.c -fno-common -DPIC -o .libs/tif_jpeg.o
In file included from /usr/local/include/jpeglib.h:27,
from tif_jpeg.c:88:
/usr/local/include/jmorecfg.h:263: error: expected identifier before numeric constant
make[2]: *** [tif_jpeg.lo] Error 1
make[1]: *** [all] Error 2
make: *** [all-recursive] Error 1

This is the CVS version of libtiff trying to use libjpg-9 (also built from source).

We have this rubbish in jmorecfg.h:

/*

  • On a few systems, type boolean and/or its values FALSE, TRUE may appear
  • in standard header files. Or you may have conflicts with application-
  • specific header files that you want to include together with these files.
  • Defining HAVE_BOOLEAN before including jpeglib.h should make it work.
    */

#ifdef HAVE_BOOLEAN
#ifndef FALSE /* in case these macros already exist /
#define FALSE 0 / values of boolean */
#endif
#ifndef TRUE
#define TRUE 1
#endif
#else
typedef enum { FALSE = 0, TRUE = 1 } boolean;
#endif

However setting HAVE_BOOLEAN doesn’t work:

libtool: compile: gcc -DHAVE_CONFIG_H -I. -g -O2 -Wall -W -MT tif_jpeg.lo -MD -MP -MF .deps/tif_jpeg.Tpo -c tif_jpeg.c -fno-common -DPIC -o .libs/tif_jpeg.o
In file included from tif_jpeg.c:88:
/usr/local/include/jpeglib.h:103: error: expected specifier-qualifier-list before ‘boolean’
[and hundreds more errors]

If C isn’t evil enough this uses GNU autotools which are even worse.

The problems above aren’t SDL’s fault, but it’s a typical library integration nightmare
using C code, especially archaic unix codes where the developers are ruled
by the false god of compatibility with their own bad practices.

–
john skaller
@john_skaller
http://felix-lang.org