On Wednesday, 8 May 2019 at 13:38:23 UTC, Ron Tarrant wrote:
> On Tuesday, 7 May 2019 at 18:13:08 UTC, H. S. Teoh wrote:
>
>> And I would think it shouldn't matter which compiler you use as long as your code doesn't depend on compiler-specific features; you could just recompile with a different compiler if need be, and go along your merry way.
>
> Is this also the case for libraries? A library compiled with (for instance) DMD can't be used from an application compiled with GDC?

On Tuesday, 7 May 2019 at 21:13:57 UTC, Johannes Pfau wrote:
> It is probably not necessary to be compatible on object file level, but at least shared libraries need to be compatible between compilers. Otherwise you will force linux distributions to choose only one compiler, as nobody wants to have 3 packages for every library (one for every compiler).


Well, that'll teach me to read the replies to the post I'm replying to before replying... if that makes any sense.

On Tue, May 07, 2019 at 09:13:57PM +0000, Johannes Pfau via Digitalmars-d wrote:
> Am Tue, 07 May 2019 11:13:08 -0700 schrieb H. S. Teoh:
[...]
> > I think it's generally accepted that you have to use the same compiler to compile an entire program.  I've never heard of it being considered a bug that the output of two different compilers are incompatible.  It'd be great if it could somehow still work anyway, but generally I don't think it's expected to.
> 
> Are you talking about D specifically or about any language in general? gcc and clang are abi compatible as far as I know and the same should be true for clang and msvc.
> 
> It is probably not necessary to be compatible on object file level, but at least shared libraries need to be compatible between compilers. Otherwise you will force linux distributions to choose only one compiler, as nobody wants to have 3 packages for every library (one for every compiler).

That's a very good point.  If we stick to platform ABI conventions (and we have to, and do, because that's the only way we could interoperate with C/C++), then in theory libraries should be compatible at the ABI level. But there's a grey area where D features may not have a fixed implementation in the platform ABI, and different compilers may implement such features differently, causing ABI incompatibility.

So I retract my statement about compiler incompatibilities.  Still, I ran into linker problems with '*-personality-*' symbols, which appear to be caused by different compiler quirks / implementation choices. But I only tested with object files, so perhaps that's not a fair comparison. I'd expect at the .so level gdc and ldc compiled code ought to be able to interoperate.


> However, I don't think there are many compiler specific runtime hooks, so it should be possible to get e.g. gdc compiled code linking to a ldc compiled druntime. I guess the biggest problem here is exception handling.
[...]

What is it about exception handling that causes problems?


T

-- 
An imaginary friend squared is a real enemy.

Am Wed, 08 May 2019 09:46:55 -0700 schrieb H. S. Teoh:
>> 
>> It is probably not necessary to be compatible on object file level, but at least shared libraries need to be compatible between compilers. Otherwise you will force linux distributions to choose only one compiler, as nobody wants to have 3 packages for every library (one for every compiler).
> 
> That's a very good point.  If we stick to platform ABI conventions (and we have to, and do, because that's the only way we could interoperate with C/C++), then in theory libraries should be compatible at the ABI level. But there's a grey area where D features may not have a fixed implementation in the platform ABI, and different compilers may implement such features differently, causing ABI incompatibility.

The personality functions are used by compilers for exception handling, but as the function itself is in druntime you will always have problems to use druntime of compiler X with any other code using exceptions compiled with compiler Y.

> 
> So I retract my statement about compiler incompatibilities.  Still, I ran into linker problems with '*-personality-*' symbols, which appear to be caused by different compiler quirks / implementation choices. But I only tested with object files, so perhaps that's not a fair comparison. I'd expect at the .so level gdc and ldc compiled code ought to be able to interoperate.
> 
> 
>> However, I don't think there are many compiler specific runtime hooks, so it should be possible to get e.g. gdc compiled code linking to a ldc compiled druntime. I guess the biggest problem here is exception handling.
> [...]
> 
> What is it about exception handling that causes problems?
> 
> 
> T

The (name of the) personality functions ;-)
I guess the actual exception handling implementation might also differ a
little between compilers. But as all compilers use libgcc's unwind
functions on linux, AFAIK, it should be possible to merge the different
implementations.

-- 
Johannes

On Friday, 3 May 2019 at 20:16:05 UTC, Walter Bright wrote:
> I can't thank Iain and Johannes enough! It's a critical achievement for D's future. It will open a lot of doors for us.

This is major news for me, a lurker in these parts. Kudos to Iain and Johannes for achieving this (and to Walter for decoupling the frontend in the first place). Does GTK's Vala need to exist now!