Integrating libraries or exe's complied on different compilers

[shyam.lingegowda]

Hi all,

If I have two c++ programs and I compile that using two different
compilers on Unix. Is it possible for these two exe's to communicate
with one another. Since the way the exe's are generated by two
different compilers are different is it possible to communicate at
all. Is there any alternative for the same. What about libraries
compiled with two different compilers. If someone can give some
feedback on the same it will be of great help.

Regards,
Sh

 

[Juha Nieminen]

If I have two c++ programs and I compile that using two different
compilers on Unix. Is it possible for these two exe's to communicate
with one another.

Maybe you should first explain to us exactly how you expect two
programs compiled with the *same* compiler to communicate with each
other, and then maybe we will understand a bit better exactly what is
the problem you are seeing with two programs compiled with *different*
compilers in this regard.

 

[Ian Collins]

Hi all,

If I have two c++ programs and I compile that using two different
compilers on Unix. Is it possible for these two exe's to communicate
with one another. Since the way the exe's are generated by two
different compilers are different is it possible to communicate at
all. Is there any alternative for the same. What about libraries
compiled with two different compilers. If someone can give some
feedback on the same it will be of great help.

Assuming communicate == link then the only safe way is through functions
with extern "C" linkage.

 

[James Kanze]

(e-mail address removed) kirjutas:

[...]

You probably mean whether you can link together C++ libraries
compiled by different compilers. This is undefined by the
standard, meaning that you cannot do this portably.

It is only possible if both compilers follow the same ABI
(application binary interface). The ABI is typically defined
for a certain combination of a language platform, e.g. C++ ABI
for Linux on x86_64. I believe there are some platforms with
standardized C++ ABI, so if both compilers follow this, they
should be able to talk to each other.

However, this is not enough. For example, if one library uses
small- string optimization for std::string and the other does
not, then any attempt to pass a std::string from one library
to another will most probably fail miserably. This is where
the one-definition-rule of C++ kicks in, I guess - if the
libraries are using different std::string definitions, the
result is undefined.

The physical layout of std::string is part of a C++ ABI, so if
their is a C++ ABI, there should be no problem. (On the
platforms I work on, there isn't, and this doesn't work. In
fact, the C++ ABI even depends on compiler options, and you
can't necessarily link two libraries compiled with the same
compiler. From what I understand, this is more or less
general.)

Using only C types and extern "C" functions may be helpful,
because C ABI is standardized for more platforms. I am not too
sure what the C ABI says about things like struct
padding/packing, I would probably avoid them for any case and
use arrays instead.

A C ABI must define how struct's are laid out. All that I know
do. (In particular, both Windows and Posix do, since both use
struct's in their system ABI.) Of course, a compiler still
might have options, or pragmas, to break this compatibility.

 

[Ian Collins]

Even that's not safe, because they may have different ABIs into the
Standard Library

Which systems would that apply to?

 

[red floyd]

Which systems would that apply to?

Windows? Possibly any Unix that has both a proprietary compiler and gcc?

 

[Ian Collins]

Windows? Possibly any Unix that has both a proprietary compiler and gcc?

Unless the platform is really FUBAR, all C compilers for that platform
follow the platform's ABI conventions. Otherwise they wouldn't be able
to use any of the platform's standard headers.

 

[Ian Collins]

The point was that different implementations of the standard library may
have, for example, different implementations of std::string.

If the only interaction between modules is through extern "C"
interfaces, why would that matter?

 

[red floyd]

If the only interaction between modules is through extern "C"
interfaces, why would that matter?

Because extern "C" doesn't preclude the use of new or delete. Consider:

/* COMPILED WITH COMPILER A */
extern "C" T* get_a_buffer()
{
return new T[20];
}


/* COMPILED WITH COMPILER B */
void f()
{
T* p = get_a_buffer();
/* use p */
delete[] p;
}

 

[Ian Collins]

Because extern "C" doesn't preclude the use of C++ classes.

extern "C" void f(std::string*);

Fair point. I always use extern "C" for functions that can be used by C.