Libs + Dlls for Visual C++

[Badestrand]

Hi!

Although I'm really(!) glad to have the pre-compiled libraries for VC05 & 08, there's one thing that's not 100% right in my oppinion.

First I'll explain what I know about delivering DLLs + Libs with the Visual Studio:
Generally, there are two ways to use other code through a library: Either you link it static which means you don't need a dll or dynamic which means you have a lib which contains some info about the dll (functions' entry points etc) and you'll need the dll.

When I link dynamically to some code, I need the classification between debug and non-debug since the DLL contains the debug-symbols when compiled in debug-mode.
When I'm linking statically, then the library has to be conform with two of my project-options: debug<->non-debug and crt-linked-static<->crt-linked-dynamic. This means that there have to be four versions of the static-lib.
This four-version-stuff sounds difficult but isn't, at least if you deliver only the libs to link against statically. Fortunately we can use the compiler-switches and the "#pragma comment" to include the libs automatically, might look like this (I can't remember the right macros right now, I will check it in a few hours):

Code: [Select]


#ifdef _MSVC
#    ifdef _DEBUG
#        ifdef BLA // crt-is-dynamic-linked; can't remember the name
#            pragma comment( lib, "sfml-system-d.lib" )
#        else
#            pragma comment( lib, "sfml-system-s-d.lib" )
#        endif
#    else
#        ifdef BLA // crt-is-dynamic-linked; can't remember the name
#            pragma comment( lib, "sfml-system.lib" )
#        else
#            pragma comment( lib, "sfml-system-s.lib" )
#        endif
#    endif
#endif

The "s" in the library-path stands here for "the c-runtime is linked statically".


What I'm facing: You can't compile your app with the option "multithreaded debug" and link to sfml statically. And you'll propably need 6 libs instead of 4

I'm pretty tired right now so I can't think of a possible solution since the option is given to link to sfml statically as well as dynamically.


edit: Got the right macros/definitions:

Code: [Select]


// Needs to get into a header-file, only for static linking against your lib
#ifdef _MSVC
#ifdef _DEBUG
#    ifdef _DLL
#       pragma comment( lib, "bla_debug_dynamic_crt.lib" )
#    else
#       pragma comment( lib, "bla_debug_static_crt.lib" )
#    endif
#else
#    ifdef _DLL
#       pragma comment( lib, "bla_release_dynamic_crt.lib" )
#    else
#       pragma comment( lib, "bla_release_static_crt.lib" )
#    endif
#endif
#endif


[Badestrand]

This might be a possible solution:

sfml-system-library-files in SFML/SFML-1.3/lib/vc2005/:

Code: [Select]


sfml-system-stat-s-d.lib // linked statically against SFML; user's app: static crt & debug
sfml-system-stat-s.lib   // linked statically against SFML; user's app: static crt & release
sfml-system-stat-d.lib   // linked statically against SFML; user's app: dynamic crt & debug
sfml-system-stat.lib     // linked statically against SFML; user's app: dynamic crt & release
sfml-system-d.lib        // linked dynamically against SFML; user's app on debug
sfml-system.lib          // linked dynamically against SFML; user's app on release

Place this in the sfml-system-header-file or make it an extra include-file which is included in sfml-system.hpp:

Code: [Select]


#ifdef _MSVC
#    if defined(SFML_SYSTEM_STATIC) || defined(SFML_STATIC)
#        ifdef _DEBUG
#            ifdef _DLL
#               pragma comment( lib, "sfml-system-stat-d.lib" )
#            else
#               pragma comment( lib, "sfml-system-stat-s-d.lib" )
#            endif
#        else
#            ifdef _DLL
#               pragma comment( lib, "sfml-system-stat.lib" )
#            else
#               pragma comment( lib, "sfml-system-stat-s.lib" )
#            endif
#        endif
#    else
#        ifdef _DEBUG
#            pragma comment( lib, "sfml-system-d.lib" )
#        else
#            pragma comment( lib, "sfml-system.lib" )
#        endif
#    endif
#endif

So when a user wants to link to SFML dynamically, he has nothing to do -  including the "sfml-system.hpp" will automatically link his app against the DLL (sfml-system-d.dll or sfml-system.dll).

If a user wants to link statically to the SFML, he has to specify SFML_SYSTEM_STATIC (or SFML_STATIC for each SFML-module being linked statically) at the preprocessor-tab in the application's configuration. Libraries get linked all automatically, isn't this cool?

Of course all this applies to Visual Studio-applications only!

PS: Changes according the other modules are analogue and maybe it should be the other way around, that you have to specify this extra-preprocessor-definition (SFML_STATIC) for dynamic linking instead?

[Laurent]

I'm not a huge fan of automatic linking with VC++ pragmas.

Regarding the static use of CRT, you can just change this setting and recompile SFML yourself. People (especially beginners) are already confused between debug / release / static / dynamic versions, I don't want to add more to this confusion.

But anyway, thanks for your feedback

[Badestrand]

I'm not a huge fan of automatic linking with VC++ pragmas.

For a specific reason or just as general feeling (I'm asking just because I'm curious)?

People (especially beginners) are already confused between debug / release / static / dynamic versions, I don't want to add more to this confusion.

Hm, but don't the pragmas just take any sorrows off the beginners? I mean, they don't have to tell their compiler whether/with which lib they want to link (especially when you switch the strange standard-configuration above to "default-static", they won't even need a dll).

But anyway, thanks for your feedback

But I'm feeling a little dumb right now - I thought you may not know about the pragma-import since they're not used in sfml; I just assumed that you're mainly programming with gcc under linux so you may not know much about the MSVC and therefore not about the pragmas - On the other hand, the sfml-library is definitely not a standard-linux library :lol: I had to use and work on some linux-libraries a few days ago and I can tell you: I was a damn mess. ~7 files of C-code with each containing ~3500 lines of code   :twisted:

[Laurent]

For a specific reason or just as general feeling (I'm asking just because I'm curious)?

Because it's not how C++ works; when you link to a library you have to do it explicitely. It's fun to get it linked automatically but I don't think it really helps, it's like #pragma once.
Moreover, I think a cross-platform library shouldn't behave differently with each compiler, I rather try to stick to a standard usage than using compiler's specific settings that might confuse people.
But that's just my point of view

Hm, but don't the pragmas just take any sorrows off the beginners? I mean, they don't have to tell their compiler whether/with which lib they want to link (especially when you switch the strange standard-configuration above to "default-static", they won't even need a dll)

I prefer showing beginners how to do things properly rather than hiding the important details. So that when they try to use another library they know how to do it instead of saying "hey, this lib sucks, SFML doesn't require so many settings!".

I thought you may not know about the pragma-import since they're not used in sfml; I just assumed that you're mainly programming with gcc under linux so you may not know much about the MSVC and therefore not about the pragmas

I'm definitely not a Linux programer, Visual Studio is my prefered IDE
I'm not using any #pragma because it's not portable and I don't like compiler-specific stuff in a portable library.

[MadMartin]

I'm not a huge fan of automatic linking with VC++ pragmas.

Regarding the static use of CRT, you can just change this setting and recompile SFML yourself. People (especially beginners) are already confused between debug / release / static / dynamic versions, I don't want to add more to this confusion.

But anyway, thanks for your feedback

I'm not quite sure about this whole linking thing. If I would compile SFML with static linking to the CRT and my own program also with static linking to CRT, is there a point at which I could run into problems or is it considered save practice?

[bullno1]

I'm not quite sure about this whole linking thing. If I would compile SFML with static linking to the CRT and my own program also with static linking to CRT, is there a point at which I could run into problems or is it considered save practice?

If I'm not wrong, you must statically link your program to the CRT if SFML does that since you cannot mix static CRT and dynamic CRT

[Laurent]

Yah, the point is that every library linked to your program (and your program itself) must use the same version of the CRT.

There's one exception : if there's absolutely no reference to the standard library in the public interface, and no standard object / memory shared across DLL boundaries, there's a chance that a mix of CRT versions might work.

[MadMartin]

Ok, as long as I am able to compile all used code (libraries, my program, ...) myself (regardless whether with static or dynamic binding), there won't be any problems, because I simply choose the same CRT for every part?
Fine.