How do you abstract a platform library like SDL from the graphics api?

The usual way to do it is to create a class that you can swap for another one at will. The key is to have an abstraction over the low level stuff, making it possible for the caller to ask what to do, not how to do it.

Let's say you write an application for a library that handles a list of books. If the books are stored in a SQL database, they can be changed through three basic SQL operations: insert, update, and delete, and they can be retrieved using select. Now, those operations are low level—they are SQL dependant. If you decide to swap the database for plain text storage where the information about each book is kept in a separate JSON file on disk, there is no such thing as selecting files or inserting files. Nor would you update a given field—you'd rather read the whole file, change it in memory, and write the whole file back.

Now, if you have a more abstract approach where you have an interface that gives you a possibility to add or remove a book, or search for a book, or correct the author or the ISBN, then you reason in terms of an abstraction. It then belongs to a particular class to translate this abstraction into the precise actions for a given underlying technology.

(A single class would work for simple stuff, but for more complex implementations, you'll need this class to rely, in turn, on other classes. For instance, in my previous example, the class that makes it possible to persist books to a database would possibly use a whole third party library for a given database variant, but may also need some more specific classes, such as the one that would translate the violation of database-level constraints to human-readable error messages.)

How do you perform an actual swap depends on you—and the technologies you use. As stated by freakish in the comment to your question, you don't need, in your case, to swap the classes during runtime, and templates would be indeed a way to go over inheritance and virtual members. Things would be different with other languages—you'd very likely rely on the actual interfaces in Java or C#, for example.

Make absolutely sure, however, that you do test that all implementations compile. In fact, you don't want to find yourself in a situation where you forget about one of the implementations for some time, just to find out much later that it is completely outdated and needs severe rework in order to be used.

It sounds like you are trying to hang on to too much.

These low level calls will be part of a presentation layer. If you accept that you will lose the entire presentation layer if you switch out openGL. Then you should be able to keep your core game code.

If you try to encapsulate the low level gfx calls then you will find it hard, and, even if you can achieve it, you will be coupled to the design of those calls, which might not find analogous functions in a different gfx framework.

There is a balance between the extra added time it will take to split your presentation layer into 2 sub layers vs the time it would take to re write the presentation layer later if you switch tech.

If you have both frameworks to hand, say openGL and directX I expect you could split the presentation layer some. You will know the full requirements of each set of functions and be able to code around them.

If you just want to leave room to switch out to an unnamed different tech at some future time, I wouldn't bother, there are too many guesses involved. Just make sure you can switch the presentation layer out.

What I would like to know is what strategies can I use to decouple these dependencies?

What you need is to define your games rendering needs. If it needs to put a dot on the screen define that in a way that is not dependent on the rendering engine.

The problem here is how easy it is for those dependencies to emerge. You think you know what a dot is until you change rendering engines and now what you thought was a pixel is now a percentage of the screen.

It's all too easy to let the needs of the rendering engine leak into your abstraction. It's far more than simply the interface. You need a clean way to model what should be rendered.

Start small. Test the model against as many engines as you can get your hands on. You'll start to see what decisions can't be left to the engine and must be dictated by your model.

You may find there isn't any one model that allows for every rendering engine. Sadly, if your needs drive you there then you'll be stuck having to write adapters to get your game working with different rendering engines. In the world of printers we call them drivers. Same trick. Different surface.