[joaquimandrade]

I want to include a third party library in a module and it massively uses STL. In moduleconfig.h it is said that

Unless you use STL or exceptions, keep this commented. It allows you to compile without libstdc++.so as a dependency

What are the disadvantages of compiling with libstdc++ as dependency? The dependency is on the same version of the lib using in compiling? The majority of the GSP's have it installed?

[Seta00]

There are plenty of Linux distributions that come with only C enabled by default.
Less dependencies is always better =D

And what is a GSP?

STL or exceptions

-> C++ exceptions are part of the STL

[joaquimandrade]

Originally Posted by Seta00 There are plenty of Linux distributions that come with only C enabled by default. Less dependencies is always better =D And what is a GSP? STL or exceptions -> C++ exceptions are part of the STL

GSP - Game Service Provider.

About "less dependencies is always better" you are uninformed.

[Seta00]

Originally Posted by joaquimandrade About "less dependencies is always better" you are uninformed.

How more dependencies would be better?

Dependencies are good for project design, not for the project performance.

[joaquimandrade]

Originally Posted by Seta00 How more dependencies would be better?

If you compile a library against libstdc++ statically, it won't be a dependency but it won't work in some conditions despite working when the library is not present. If you compile it dynamically it will work in more conditions but only if the library is present.

If you have doubts on what I said search in google for "compile against stdc++ statically"

[Seta00]

Oh, I completely forgot about static linking.
So you want to know if static linking against stdc++ is better than dinamically linking.

It doesn't really matter, NO_ALLOC_OVERRIDES allows compiling without linking to stdc++, statically or dinamically.
If you want compatibility, link statically.

[gangien]

in general, you want to avoid statically linking (And it's a bigger pain anyways with getting the compilers to do that). But, in cases, like with libstdc++, there's not a whole lot that can be done to avoid it. SHort of requiring people to have it installed.

And less dependencies are better, less chances for errors, less requirements, smaller size and such. But if you need it, then you have to put up with it.

[BAILOPAN]

AMX Mod X and SourceMod require no dependencies on STL. They are not exception safe, and try/catch blocks add runtime overhead in MSVC. It's also really hard to properly and safely statically link libstdc++, and Linux doesn't guarantee the C++ ABI will be the same on all distros.

A particularly nasty bug is that hlds_* do not have PT_TLS headers. In older versions of libc (which are still floating around on servers that don't want to do a massive distro upgrade), PT_TLS sections cannot be late loaded, but newer libsdtc++ versions have them. So I have seen STL-dependent modules refuse to load with extremely confusing error messages.

I've also seen conflicts when linking with Valve libraries. I'm not exactly sure what happened, perhaps it was a name conflict (ELF names tend to be leaky) or something. Anyway our libstdc++ conflicted with Valve's and crashed.

If you can get it working, that's great - but we don't check in libstdc++ dependent code into the tree.

[joaquimandrade]

Originally Posted by BAILOPAN If you can get it working, that's great - but we don't check in libstdc++ dependent code into the tree.

You mean, adding to amxmodx?

[Seta00]

Originally Posted by joaquimandrade You mean, adding to amxmodx?

Yes, and as a consequence, your statically linked module won't be added in the default distribution (which are on the source tree).