Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: How does SFML resolve dependencies?  (Read 1559 times)

0 Members and 1 Guest are viewing this topic.

Symphonym

  • Newbie
  • *
  • Posts: 32
    • View Profile
How does SFML resolve dependencies?
« on: May 02, 2014, 01:44:18 am »
I'm currently developing a little library of my own, which uses OpenAL (amongst others) like SFML. So when I compile my library I dynamically link against the OpenAL Soft .so file and create my own .so file, no problems.

But when I create a test program and link against only my own library, and include the headers of my own library; it doesn't work. Undefined symbols to OpenAL as well as it not finding its headers. (It works when I manually add these to the compilation settings of the test program; linking and including OpenAL).

However using SFML audio would only require you to link to the SFML modules, such as sfml-audio, and not manually adding OpenAL to the linking settings. So I assume SFML automatically links the dependencies it has when you link against it in your program, but how is this achieved? I've looked into libtool, pkg-config, ld options and whatever things google might suggest without much success.

So I thought I'd finally ask here to see how you do it, since I can seem to figure it out on my own :/

FRex

  • Hero Member
  • *****
  • Posts: 1848
  • Back to C++ gamedev with SFML in May 2023
    • View Profile
    • Email
Re: How does SFML resolve dependencies?
« Reply #1 on: May 02, 2014, 02:51:46 am »
SFML never exposes any OpenAL in the headers so you don't need to include and link OpenAL yourself.
When compiling a program with SFML Audio you never compile or link any code from OpenAL directly.
Your library probably has some headers that include or call OpenAL which is why it tries to look for the headers and symbols from it.
Back to C++ gamedev with SFML in May 2023

Symphonym

  • Newbie
  • *
  • Posts: 32
    • View Profile
Re: How does SFML resolve dependencies?
« Reply #2 on: May 02, 2014, 10:33:43 am »
SFML never exposes any OpenAL in the headers so you don't need to include and link OpenAL yourself.
When compiling a program with SFML Audio you never compile or link any code from OpenAL directly.
Your library probably has some headers that include or call OpenAL which is why it tries to look for the headers and symbols from it.

Ah yes, I looked into the SFML source again and noticed how it forward declared usage of internal dependencies. I believe this is known as the pImpl idiom or opaque pointer idiom, so I'll be researching those next. Thanks for the help!

 

anything