Working SDL Examples?

Try as I might, I cannot get anything that uses the SDL1.2 libs to build on RO.

Is there some arcanum that I’m not aware of?
In linux I can build the code with:
gcc -o myprogram mysource.c -lSDL
In the source, it has to be
#include "SDL.h" not #include "SDL/SDL.h"
because of the way !SDL is set up, but that is the only difference I can see.
Best case is all that works then it freaks out on every single SDL_ thing being undefined. I absolutely cannot work out why!

Any help would be appreciated. Does anyone here use SDL on RO?

In linux I can build the code with

You will have to specify -static if you are building a static binary.
I have had occasional mishap with local h files, sometimes swapping "" for <> works, assuming you do have a SDL local directory

It gets grumpy about not finding the header if I change it, so I guess that’s okay. So I have to do it static? I’ll give it a try next chance I get.

I think if it found shared library components it might have tried to build a shared executable, but would then complain that -ldl was missing.
You could try forcing it with -shared to see what happen.
Edit: silly idea, -shared wont make an executable, just for lib making, I guess.
To be sure of linking to the static library you would have to use -L. libSDL.a
If you building static and there is shared components involved there will be an error when you try elf2aif on the binary.
If you are building a shared executable and it has static components in the library it could fail also, you have to search for TEXTREL after using readelf.
Static components can infiltrate the shared library from any of the components used to build it.
Linux can get away with one size fits all, but we often have to have two parallel builds to keep static from shared.

To be sure of linking to the static library you would have to use -L. libSDL.a

I have been reading a bit on this, It seems to be mentioned in !SharedLibs docs and in my big Linux book that the type of executable is decided by what type of libraries it is told to link to, with a preference for dynamic building.
However Linux has -Wl,-Bstatic and -Wl,Bdynamic to force the type. Neither of these are recognised in !GCC, but using -static does at least force the static build for us. Interesting also that -Wl,-static goes wonky, in my example anyway, there is an unusual error wanting libgcc_s. There is mention somewhere of gcc spinoffs having trouble with -Wx, options and to avoid them if possible. Apparently -Wl,-s can be used for stripping when building static.
-static is commonly used as a CFLAG, though it serves no purpose in the preprocessing stage. It is likely that the over-use of -shared would cause problems though, particularly when making the (dynamic) executable.
It is possible that on one liners, gcc pre-allocates them to the right stages, but forces them when asked to compile or link separately.

Separating the build stages is probably the safest way and perhaps better visibility.
To build a shared library
the .o objects are built with -fPIC
The shared lib is built with -shared and soname info.

To build a static library
No special flags, accepts --no-pic but end result is the same
ARchive the objects to libx.a
Link the executable using -static
Reportedly using -static may not be necessary, and having the desired libraries/objects built for the target type would be most important.
I dont know, but at a minimum it reflects what type you are trying to build.

Something I learnt today, was that the link flag -export-dynamic can be used on spinoffs of gcc that dont recognise -rdynamic Early tests show a difference in the output which is positive.