Interesting! So help me understand: what’s really needed is a .mod + an ABI model for each compiler, not the .mod only. Unless for bind(C) stuff which I believe should always work?
2 Likes
Is that a sane route to take?
I mean, UNIX-compatible C/C++ compilers follow the Itanium ABI and therefore the std*.h headers are the ultimate source of truth —but that assumption breaks with MSVC.
Fortran compilers have their own assumptions, but also consider the ABI of the “companion processor”.
And also, I think it’s safe to say that even having the .mod and .o|.obj files for one compiler is not enough —you still need to map the optimization-related assumptions for each object file, the interprocedural optimizations, the debug info (or lack thereof), etc.
…Or am I way off and it is totally doable? 
Same in my experience is with g++ vs. clang++, I stumbled upon some cases where their ABIs and system headers are incompatible.
I believe these should be internals? I don’t think optimization does anything to the public object definitions? What you mean is perhaps how could LTO be done in a case like this. Now that’s what I would call a moving target!
What I have no skills to evaluate is what of the ABI surface area is actually compatible across the different compiler toolchains. But that still leaves aside the issue that creating a general interpreter for any .mod files seems well within reach. Besides LFortran, gfort2py does exactly that.
I was referring to
My point is that there’s no real benefit in pretending .mod files behave the same as headers: if you know the format of the .mod from compiler X, then a source file, containing only interfaces, can be safely generated —although, if your goal is to use compiler Y, you still need the whole source, so there’s no real benefit there imho.
(As for the “.mod files are not headers”: in my custom build system, I went as far as eliminating the need for include or modules subdirectories —i.e., the .mod and .smod files can always be found alongside the libraries. The layout is only build/{bin,lib}/ and the -I and -L flags are usually the same.)
1 Like
Yes, exactly. I think it’s not worth doing, because might as well just use the same compiler for everything. The use case of mixing compilers would be that you use one to compile a library, install it (say in a binary distribution), and you use another one to use it. But the problem is that even with such an adapter, it will not be as efficient as using the same compiler for everything, due to all the ABI conversions.
2 Likes