1

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:

  1. added a protected static member variable to a class (didn't really need to be protected)
  2. added a private static member to a class
  3. 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();
}
default
  • 2,637
  • 21
  • 44
  • 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? – πάντα ῥεῖ Apr 26 '16 at 18:55
  • 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 Apr 26 '16 at 18:59
  • 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 Apr 26 '16 at 18:59
  • 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 Apr 26 '16 at 19:01
  • So i will add this info the the question, but i reverted my changes and they were able to run when i built again. I add back in my changes and they are not able to run. The changes are very trivial (I might try to post some example code) but are basically adding in a static mutex and calling some methods on in a couple class methods. But i am pretty confident that it is not simply my build process that is the problem. – default Apr 26 '16 at 19:04
  • Does the user not report any specific error message? "It doesn't work" and the steps the user thinks may be necessary to resolve the situation aren't much to go on. – John Bollinger Apr 26 '16 at 19:08
  • I agree. I'm not 100% sure of the symptoms but they said whatever they are seeing is the same thing they saw when they previously had a binary compatibility issue. 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?" – default Apr 26 '16 at 19:13
  • 2
    `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 Apr 26 '16 at 19:25
  • Of course, your new version of the library doesn't behave the same as the old one -- that's the point, after all. It may be that the behavioral changes are causing trouble for your end user. That would indeed be a compatibility issue, but not really a *binary* compatibilty issue. – John Bollinger Apr 26 '16 at 19:30
  • Thanks, your last two comments are basically the answer I was looking for. – default Apr 27 '16 at 14:32

2 Answers2

1

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.

Employed Russian
  • 199,314
  • 34
  • 295
  • 362
0

"Binary compatibility" is probably related to save/load or network packets. Or may be they have issues with compilation - in this case, probably, you built it with different compiler/compiler version.

Also consider struct pack value. You can have different same struct size with different struct pack settings.

Oleg Kuznecov
  • 11
  • 1
  • Yeah i believe there is some confusion in the answer here. I am talking about "an ability of two hardware/software systems to run the same binary code without the need to recompile." – default Apr 26 '16 at 19:01