[Patches] Resolve all symbols

[christoph]

Hi Laurent!

I have created a set of 2 patches which resolves all symbols needed in SFML libraries. This has 2 advantages: The libraries become dlopen() able and you don't need to remember linking against some library in your application if you don't use it directly. Patches are against sfml2 branch and tested locally on my system.

http://random.christoph-egger.org/.sfml-2/

[Laurent]

Hi Christoph

I'm not sure whether this patch is really good or not. SFML libraries are not linked against each other on purpose: I think it's good that users explicitely see what modules they are using.
Plus, I think they will be in trouble if both SFML and them link against the same library ("multiple definitions" errors -- or is the linker smart enough?). This would be even worse for static libraries.

However I agree with you on this point:

The libraries become dlopen() able

So, what do you think?

[christoph]

Hi Christoph

I'm not sure whether this patch is really good or not. SFML libraries are not linked against each other on purpose: I think it's good that users explicitely see what modules they are using.

OK I suspected that argument. If you want to keep it that way it's your decision, I'll have to patch it for my part but that's not much of a problem.

Personally I prefer if I can guess the libraries I need to link to from my sources correctly witout any second thought

Plus, I think they will be in trouble if both SFML and them link against the same library ("multiple definitions" errors -- or is the linker smart enough?). This would be even worse for static libraries.

For dynamic libraries the linker is able to cope with that. There's just one potential cause of problem: If I use a sfml-graphics linked against some version of sfml-system and link against another version of sfml-system as the symbols are not versioned and the linker now sees 2 different dynamic libraries. However I doubt this has any relevants in reality.

Static libraries are, of course, another case and should probably be solved, if at all, with pkg-config.

However I agree with you on this point:

The libraries become dlopen() able

So, what do you think?

If you decide to leave everything as is, please consider adding GL and X11 to libsfml-graphics linker at least they're missing as well (sfml-window is linked against GL but that doesn't propagate to -graphics, IIRC you will need to ass -lGL even if you have -lsfml-graphics -lsfml-window)

[Laurent]

For dynamic libraries the linker is able to cope with that

Ok, one point for you

Static libraries are, of course, another case and should probably be solved, if at all, with pkg-config.

So this would the last problem to solve. I'm not an expert and thus I cannot write and maintain pkg-config scripts. This wouldn't be a solution anyway, as it doesn't work on Windows (which is the main OS where static libraries are used).

If you decide to leave everything as is, please consider adding GL and X11 to libsfml-graphics linker at least they're missing as well (sfml-window is linked against GL but that doesn't propagate to -graphics, IIRC you will need to ass -lGL even if you have -lsfml-graphics -lsfml-window)

There seems to be no problem with that, sfml-graphics links with no error (as well as programs using it).
But I guess you're right, I should add GL as it's used directly by sfml-graphics. However X11 is not.

[christoph]

Code: [Select]

% grep -Rni XFree src/SFML/Graphics
src/SFML/Graphics/Linux/RenderImageImplPBuffer.cpp:124:        XFree(configs);
src/SFML/Graphics/Linux/RenderImageImplPBuffer.cpp:138:        XFree(configs);
src/SFML/Graphics/Linux/RenderImageImplPBuffer.cpp:154:        XFree(configs);
src/SFML/Graphics/Linux/RenderImageImplPBuffer.cpp:155:        XFree(visual);
src/SFML/Graphics/Linux/RenderImageImplPBuffer.cpp:164:    XFree(configs);
src/SFML/Graphics/Linux/RenderImageImplPBuffer.cpp:165:    XFree(visual);

[Laurent]

:mrgreen: :mrgreen: :mrgreen: