Static Libraries, Links, and Dependencies

Question

I have a static library that I want to distribute, including Foo.c / h, and someone picks it up and includes my static library in their application.

Say they also have Foo.c / h in their application. Will they associate errors?

Answer 1

The name of the source file is not significant during the build process.

If the file has the same contents, then you will have a problem assuming that the .c file contains exported characters (for example, non-static or non-template functions or external variables).

Answer 2

It depends. If foo.c and foo.h define the same functions and / or variables, then yes, there will be many definition errors. If they have the same file names but contain different code, there will be no problem.

Answer 3

File Name Link
The linker itself has the least problems, but some IDEs will complain if files are added, even if they are in different folders. But usually this is not a problem.

Do not distribute static library (without source)

First, you should not distribute the static library yourself. The code - and compatibility - depends on the compiler, and many common settings, such as the runtime library (static / dynamic, debugging / release, happily, that one thread is removed from VC), some C ++ parameters, such as exception handling, presentation virtual member function pointer and others. Ultimately, you create hundreds of options to support only mainstream compilers, and you end up with someone who needs it anyway.

Always turn on the source so that the user can rebuild the static library on his field. As an alternative, you can use a dynamic library, but it has its own gotchas.

Namespace
As mentioned, use a namespace to avoid collisions. Do not cross overboard if you have a source, the user can always rename it. But keep in mind that declarations using namespace should not appear in the header, so you need to adjust the code a bit.

Answer 4

If you are issuing your own static library, you do not need to include foo.c, as this will be part of lib and yes, if they have their own foo.c, this will confuse the compiler and linker and may cause problems if you both have similar functions or include the wrong header.

Your best way to solve this is to use a namespace for your code, thereby keeping it unique.

 namespace myfooname { void foo() { //stuff } }