Can adding a static variable break binary compatibility on Linux?

Question

I made some changes to a shared library on a linux platform and sent the updated library to the end user. The end user has reported that they believe the binary compatibility has been broken (not really sure how they know that).

The changes I made were to internal classes (user doesn't have the header files):

I made 3 different changes:

added a protected static member variable to a class (didn't really need to be protected)
added a private static member to a class
added a static variable to a cpp file (in a non-anonymous namespace)

Which of these changes (if any) can break binary compatibility and how should I add a static variable so that it does not break binary compatibility? Or is adding a static variable generally safe for preserving binary compatibility?

Example of the change I made (denoted by +)

internal .h file:

class A
{
protected:
    + static Mutex m;
}

internal cpp file

void A::doSomething
{
    + m.Lock();
    ...
    + m.Unlock();
}

What are you asking about actually? Adding a static variable usually doesn't break binary compatibility. Also what has mutex to do with that? Are you asking about a thread safe singleton inferred from a shared library? — πάντα ῥεῖ
What is the nature of the incompatibility that the end user asserts? If they do not receive headers then it cannot involve any code that they write directly against the library. — John Bollinger
The user says that they believe they will have to recompile to get the library to work but they cannot do that at the moment as it takes hours to compile. So my question is "what change did I make to break binary compatibility" and "how can i added a static variable to a shared library without the user having to recompile their code" — default
If your library binary has a different SO version then the end user would need to re-link. That's not directly related to any specific changes in the library. — John Bollinger
static member variables inside a class have external linkage, so they are visible in the binary. static variables outside a class have internal linkage (gotta love C++) so they are invisible outside the library. But neither changes the size or layout of objects, nor any function signatures. From an API perspective, old code should be binary-compatible with a new dynamic library that is changed only in the ways you describe. — John Bollinger

Employed Russian Employed Russian · Accepted Answer · 2016-04-27T03:26:13

So I guess question is more generic as in "can the addition of a static variable cause binary compatibility issues and if so how do you avoid the issue?"

Of course it could cause issues.

The end user may do any number of unsupported things, from hard-coding the size of your library into his program, to stomping on your memory, to passing bad data to your library so it stomps on user's memory, etc. etc.

None of these have anything to do with binary compatibility though.

You need to have the end-user explain what exactly they are seeing. This may be easier said then done, as the end-user may have a "broken phone" between you and the person actually observing the failure. But it has to happen or you will never make progress.

Can adding a static variable break binary compatibility on Linux?

2 Answers