15

Our company will purchase a large and very complex piece of source code for satellite communications.

It is coded in C++ and we will code additions to it, also in C++, linking our code with the purchased code into a single executable unit.

  • Is it necessary that we use the same compiler and same compiler version as was used to develop the purchased code?

  • Is it necessary that we use the same version of C++ as the purchased code? If it is not using 2014, we _might_ want to use some features of it, but not if there might be some problems with mixing different versions.

In theory, of course, it ought not to matter, especially the language version, but it is conceivable that different versions of the compiler will generate different object code, potentially leading to timing differences, etc.

What should we be aware of?

  • 7
    I hope you not only are buying the source code, but some support (by qualified persons) on it. – Basile Starynkevitch Feb 16 '17 at 18:21
  • 1
    Indeed, we are. And, of course, I have asked this question of the supplier too. But I thought that it would be a good discussion point here, and a good future reference for others in future. – Mawg Feb 16 '17 at 20:30
  • 2
    Are you talking about compiling the third party code using an unsupported compiler, or are you talking about compiling different parts of code using different compilers (e.g. using the supported one for the code you're buying and a newer one for your own code and then linking them)? Or is deciding between those part of the question? – jpmc26 Feb 17 '17 at 1:07
  • 3
    Even the language version may matter, see gcc.gnu.org/wiki/Cxx11AbiCompatibility for a list of (older) compiler versions and tiny differences in the ABI. In other words: same compiler, but different c++ language setting (c++03 s c++11) may matter. – André Feb 17 '17 at 8:05
  • 2
    And with MSVC, it is in general not safe to pass along standard library objects across (dynamic) library boundaries. See for example stackoverflow.com/q/5661738/417197 – André Feb 17 '17 at 8:06
9

Is it necessary that we use the same compiler and same compiler version as was used to develop the purchased code?

It depends.

Compilers generate code targeting an ABI. Some are using a common ABI (for instance, if I'm not mistaken, both clang++ and g++ target to called Itanium ABI) and you should -- there may be bugs preventing you to do so -- be able to use the object code from both in a same program (assuming of course that you are using versions which target the same version of the ABI). The same is true between compiler version: some pay more attention to keep the same ABI between version than other. Obviously, they all need sometime an ABI change, and they may be forced to do so in an non compatible way. And obviously, some settings like the choice of a language standard may have an influence on the choice of the ABI.

Then there is the issue of the standard library. The compilers (or different versions of the same compiler) themselves may use the same ABI, and yet their standard library may be incompatible (and some compiler like clang++ may be usable with several standard libraries). Being able to make it works may depend on what is used in the interface.

In other words, you have to dig and find the information for the specific case you are in. As an starting point and an example of what kind of information you should look for, here is the information provided by libstdc++ (the library used by g++ and in some configuration by clang++)

  • 10
    ABI = Application Binary Interface – Simon B Feb 16 '17 at 17:00
  • 2
    This answer is about compatibility of object code. OP is buying source code. – Lightness Races with Monica Feb 16 '17 at 20:51
  • 7
    @LightnessRacesinOrbit The question talks about using different compilers to generate a single executable. It's not a big leap to think, "They mean compiling the third party code with one compiler (probably a 'supported' one) and their own code with a different compiler (probably a newer one)." (This is definitely what I understand the OP to be asking; if you read it differently, you may want to ask the OP to clarify.) In that possibility or other similar ones, compatibility of object code seems highly relevant. – jpmc26 Feb 16 '17 at 23:32
  • 1
    @jpmc26: "This is definitely what I understand the OP to be asking; if you read it differently, you may want to ask the OP to clarify." OP clearly stated that their company "will purchase a large and very complex piece of source code". Furthermore, with statements such as "it is conceivable that different versions of the compiler will generate different object code, potentially leading to timing differences", they are asking about what changes when they compile the purchased code with different toolchains, not just their own. I don't think there's much room for interpretation there! – Lightness Races with Monica Feb 17 '17 at 0:53
8

Is it necessary that we use the same compiler and same compiler version as was used to develop the purchased code? Is it necessary that we use the same version of C++ as the purchased code?

This is not mainly a technical question. It is a legal question about what you write in your contract. Make sure the software vendor provides you with a version guaranteed by him to be usable in your environment. Otherwise, there will always be a certain risk of running into trouble with a different compiler, compiler version, or language version.

This is especially important when you purchase the component or parts of it as closed source. Even if your supplier guarantees you can use the component with your current compiler environment, does he guarantee he will provide you with updates if you want to switch to a newer compiler version in the future? If you don't have access to the full source code, you will probably not have much luck in trying to solve any compatibility problems by yourself. That is why you should not just buy the software, but also think about a long term maintenance contract with your supplier.

  • This is actually a pretty good advice! – T. Sar - Reinstate Monica Feb 16 '17 at 19:01
  • It is indeed, but, alas, too late. As I remarked to Basile's comment, I have asked this question of the supplier too. But I thought that it would be a good discussion point here, and a good future reference for others in future – Mawg Feb 16 '17 at 20:32
4

Our company will purchase a large and very complex piece of source code for satellite communications. It is coded in C++ and we will code additions to it, also in C++, linking our code with the purchased code into a single executable unit.

Sounds good!

Is it necessary that we use the same compiler and same compiler version as was used to develop the purchased code?

Speaking generally, no it is not necessary. The purpose of C++ is to act as an abstraction over these kinds of things, so a well-written C++ program will compile just as well on your toolchain as it did on the original author's, and the resulting program will have the same result. The performance may vary, because different compilers are good at different things, but the fundamental behaviour of the program should not change.

However, badly-written software may rely on implementation-specific behaviour, or even undefined behaviour. It may make assumptions about the built-in types, or about the platform's endianness. Even well-written software may have no choice but to rely on non-standard extensions that aren't available on your chosen toolchain, or it may do so because there was simply no need to spend time on adding a portability layer within the duration of the original project.

Ultimately, you will need to ask the author/vendor what the source code is written for. If they claim that it is specifically written against, say, Visual Studio 2015, and requires Windows API features, you should probably stick with that. But if they claim that it is portable, standard C++, then use whatever compiler you like. Make sure your purchase agreement includes a support arrangement so that you can get free help when it turns out the vendor was lying.

Is it necessary that we use the same version of C++ as the purchased code? If it is not using 2014, we might want to use some features of it, but not if there might be some problems with mixing different versions.

Probably. Maybe.

C++03 is forward-compatible for the most part so, if the code is C++03, then you're unlikely to have a problem. (Though some tweaks may be required.)

But features introduced in C++11 and C++14 are not backward-compatible so if the vendor used, say, C++11 lambdas, and you try to build their code in a C++03 compiler, that just won't work.

In theory, of course, it ought not to matter, especially the language version, but it is conceivable that different versions of the compiler will generate different object code, potentially leading to timing differences, etc.

Absolutely. If the code relies so much on a specific implementation in order to obtain expected results, then it is up to the vendor to be responsible and inform you of that. Since we live in the real world, I recommend being diligent and asking them first.

And I'll echo what others have said: ensure that you have some sort of support recourse, so that if they misrepresented any of the responses to these questions (whether intentionally or otherwise) you do not end up shouldering the resulting cost.

  • Worth noting: linking is not fully covered in the C++ specifications. While the code may compile in multiple conforming compilers, it's not guaranteed that you can just link them together and have it work. – Cort Ammon Feb 17 '17 at 0:33
  • 1
    @CortAmmon: You should/must compile all components of the resulting distribution with toolchains that share an ABI. ABI standards are out of the scope of C++. I don't think the OP is asking about mixing toolchains anyway. – Lightness Races with Monica Feb 17 '17 at 0:54
2

You don't link code, you link compiled object files.

In this case yes, using different C++ compilers (or even settings like debug/release builds), or different versions of them, or different (versions of) standard libraries when building parts that will interact at a binary level is highly likely to break the application if the parts communicate with each other using more than C APIs.

Features like containers or exceptions provide the same interface but, at a binary level, can be implemented in many different, incompatible ways.

Using a different compiler to compile the entire code is a different issue however. Questions to consider:

  • What platform/architecture does the code target?
  • For which standard was it written?
  • Does it use any non-standard compiler features?
  • Does the code contain hard-coded platform specific assumptions (like always considering that pointers occupy 2 bytes)?

There is also the risk that code may contain parts that result in undefined behavior. These could appear to be working fine when using one compiler but fail in mysterious ways when using a different one.

  • OP is building the code, not the vendor. OP is asking how changing build environment (cf. the vendor's) may affect code generation given the same codebase. – Lightness Races with Monica Feb 16 '17 at 20:52
1

Is it necessary that we use the same compiler and same compiler version as was used to develop the purchased code?

Well, switching compiler, can lead to some problems; currently in my company, we use Clang and MSVC, and we have error in one compiler that the other one doesn't mark as such.

Is it necessary that we use the same version of C++ as the purchased code? If it is not using 2014, we might want to use some features of it, but not if there might be some problems with mixing different versions.

It' not necessary, but of course you compiler should support the C++ version that you want to use. C++ guarantee retro compatibility starting from all version.

  • Pretty much my thinking. What about compiler verions - if they use GCC version x and the latest is x+2 , for instance ? – Mawg Feb 16 '17 at 15:51
  • 1
    Well if they use an older version of the compiler that you want to use, there are no problem, because there is no such thing as deprecated stuff, the problem could raise if they were using a newer version of your compiler. – LaboPie Feb 16 '17 at 15:55
  • But how? I, too, woudl prefer not to. But are you aware of any type of problem that could occur? – Mawg Feb 16 '17 at 15:59
  • But are you aware of any type of problem that could occur? If they were using some function that our compiler will not support, the code simply will not compile. – LaboPie Feb 16 '17 at 16:15
  • 1
    A little appendix, of course the problem become greater if the compiler used from the other office was not a major one. E.G. an old console compiler, or something that works with subset of language. – LaboPie Feb 16 '17 at 16:55
1

One big problem when changing compilers is undefined behaviour: If the code that you receive invokes undefined behaviour, then anything is possible - including that the code works just fine and passes all their tests when using their compiler, and goes terribly wrong with your compiler.

That's possible, but in that situation you might also run into problems if you change optimisation levels, use the next version of the same compiler and so on. So nothing you can avoid.

  • This is a good argument for using lint and maybe valgrind. – user22815 Feb 17 '17 at 0:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.