Author Topic: A few beginner questions (Read 5231 times)

GarrickW · « **on:** June 11, 2011, 08:36:41 am »

So I've recently made the move from Python to C++, and now that I feel somewhat confident in the latter, I'm trying out SFML. However, I have a few problems/issues so far. Keep in mine, I'm using CodeBlocks 10.05 for all my coding.

First, I dislike having to copy the DLLs into the executable folder all the time; I've heard of static linking, but I've also heard it's better to copy the DLLs anyway. Why? What are the advantages/disadvantages of static linking? And how do I go about doing it, anyway? Do I need to link to them in Build Options?

Second, I dislike having to manually go into Build Options and link all the libraries I need each time I start a new project. I assume the SFML template in CodeBlocks is meant to avoid this hassle, but I've yet to get the template to work, for some reason. Can I somehow set up CodeBlocks such that when I want to write an SFML program, I can just create a project and start coding, with the linkage already done for me? Would this involve setting up my own template, and if so, how would I go about this?

Disch · « **Reply #1 on:** June 11, 2011, 09:09:57 am »

Quote

I've heard of static linking, but I've also heard it's better to copy the DLLs anyway. Why?

I don't know where you heard that. If you statically link, the DLLs are not used. They'd be 100% worthless.

Quote

What are the advantages/disadvantages of static linking?

Biggest advantage: always sure that the user has the right version of the right lib installed.

Biggest disadvantage: your exe is bigger

Personally I strongly prefer static linking on Windows.

Quote

And how do I go about doing it, anyway?

When you compile SFML, set up the project so it compiles statically. There are options for that in CMake (See the tutorial page:
http://www.sfml-dev.org/tutorials/2.0/compile-with-cmake.php )

EDIT: specifically, the BUILD_SHARED_LIBS option is how you choose whether you want static or dynamic.

You'll know you did it correctly if your libraries have "-s" in the name after you build them.

Quote

Do I need to link to them in Build Options?

Yes. You link to them the same way you link to dynamic libs. The only difference is you don't need the DLL to run the program.

Quote

Second, I dislike having to manually go into Build Options and link all the libraries I need each time I start a new project.

There's a workaround this for Visual Studio that uses #pragmas, but I don't think it would work for C::B. =(

Groogy · « **Reply #2 on:** June 11, 2011, 04:35:30 pm »

For windows static linking is preferred since Windows don't have a proper system for shared libraries( DLL's ) that makes it easy for the developer to use.

Anyway you don't have to copy the DLL's if you have them in a folder that is written in the environment variable PATH. System32 is for instance in that variable.

GarrickW · « **Reply #3 on:** June 12, 2011, 09:05:17 pm »

Thanks for the response!

After some fiddling, I've managed to get things working. I'm looking forward to more fun with SFML soon!

shiroaisu · « **Reply #4 on:** June 13, 2011, 01:23:46 pm »

IMO you should use static linking for now because of a bug regarding the ATI drivers that will cause your program to not work on some computers.

Lots of users have problems with that... i did too lol

Just a warning and gl on your future code

Silvah · « **Reply #5 on:** June 13, 2011, 02:09:47 pm »

Quote from: "Groogy"

For windows static linking is preferred since Windows don't have a proper system for shared libraries( DLL's ) that makes it easy for the developer to use.

[citation needed]

Svenstaro · « **Reply #6 on:** June 13, 2011, 08:05:16 pm »

If you static link your C++ library, you will lose exception support, so careful.

Nexus · « **Reply #7 on:** June 13, 2011, 09:48:05 pm »

Quote from: "Svenstaro"

If you static link your C++ library, you will lose exception support, so careful.

What do you mean exactly? One can certainly use exceptions when linking statically...

Groogy · « **Reply #8 on:** June 13, 2011, 09:58:12 pm »

Quote from: "Silvah"

Quote from: "Groogy"
For windows static linking is preferred since Windows don't have a proper system for shared libraries( DLL's ) that makes it easy for the developer to use.
[citation needed]

Allright I'll rephrase. Windows don't have a central place where DLL's should be placed without possible disruption to the integrity of the system. Also it does not handle different versions. All is a comparison to Linux and you can see it in SFML 2, the DLL's there are named sfml-xxxx-2.dll to not conflict with the older version. In Linux this is resolved using symbolic linking so that the developer and user don't have to even bother about this.

It's a common problem with dependencies on Windows, that's why it's easier to statically link. I can give examples of problems I am having with rbSFML and DLL's. I am actually thinking of just dropping support to shared library there and force the user to link against a static SFML instead.

Svenstaro · « **Reply #9 on:** June 13, 2011, 10:30:59 pm »

Quote from: "Nexus"

Quote from: "Svenstaro"
If you static link your C++ library, you will lose exception support, so careful.
What do you mean exactly? One can certainly use exceptions when linking statically...

If you static link partially, yes. If you go all the way, no: http://www.trilithium.com/johan/2005/06/static-libstdc/

Nexus · « **Reply #10 on:** June 14, 2011, 11:48:39 am »

I think the problem is rather to mix incompatible runtime libraries. By the way, this problem doesn't affect only exceptions and RTTI: The freestore manager or other global state may be duplicated when linking multiple CRT libraries. You have to be very careful anyway, or just ensure compatible libraries (which may be sometimes difficult if only a few configurations of binaries are available).

Silvah · « **Reply #11 on:** June 14, 2011, 03:42:38 pm »

Quote from: "Svenstaro"

If you static link your C++ library, you will lose exception support, so careful.

Not if you're using TDM-GCC, as it includes a patch that allows throwing exceptions across dynamic library boundaries even when there are several instances of libgcc.