[fpc-devel] RTTI interface & variant late binding issue (mORMot)

[Jonas Maebe]

On 07/02/15 14:13, Florian Klämpfl wrote:
> Am 07.02.2015 um 13:59 schrieb Jonas Maebe:
>> On 07/02/15 13:19, Michael Van Canneyt wrote:
>>>
>>> On Sat, 7 Feb 2015, Jonas Maebe wrote:
>>>
>>>> The libffi license is basically a BSD license, that's no problem at all:
>>>> https://github.com/atgreen/libffi/blob/master/LICENSE
>>>
>>> I am not a proponent of third-party dependencies.
>>
>> I am not a proponent of reimplementing everything but the kitchen sink
>> because of other people's adversity to reusing existing solutions.
> 
> Indeed, but even leaving the very unpleasant license aside, depending on third party libraries
> depending on libc is an issue on linux and an even bigger issue on windows not to mention rare
> platforms like amiga or msdos.

Then these rare platforms can use something else, that's why I proposed
a manager-style solution. And in spite of all the comments in the
previous thread regarding cthreads/cwstring, I did not see a single
point that argued that simply having a dependency on libc (especially
via something as basic and portable as libffi) would cause problems
other than for cross-compiling, even on Linux. It does not depend on
particular versioned libc functionality, and this is not 199x anymore
where even the name of the Linux (g)libc library was changed every full
moon.

Besides, many FPC programs for Linux already depend directly or
indirectly on libc anyway via the LCL, cthreads, cwstring, clocale,
database units and whatnot. I really think the fear of problems due to
this is way overblown (and note that I'm not proposing to have a
complete RTL always based on libc — which was another misunderstanding
raised in that previous thread; I'm just talking about making use of
certain extra functionality used via C libraries).

> While using libffi might work for the platforms you are mainly using,
> for most other platforms third party dependencies are a pain.

What would be a pain is that every time I want to modify something to
the implementation of the parameter manager, I would have to go through
the RTTI dispatch code of all of our platforms to fix them up (because I
know how frustrating it is to have your platform broken all the time if
other people change things; that's also why I implemented the
codepage-aware functionality for all platforms at the same time, or at
least tried to make sure that those changes didn't break them).

What would also be a pain is that every time I add support for a new
platform, I would have to implement and debug the parameter
loading/dispatching code twice: once in the compiler and once in the RTL.

Regarding some of the other remarks:
* Florian
- libgdb is an officially *unsupported* and extremely low level and very
OS-dependent interface to GDB. The problems with using that library are
related to specifically depending on that, library not on depending on C
libraries in general. I fully agree it's a mess, which is one of the
reasons I never even tried to get it working on Mac OS X.
* Marco
- the libffi license is not GPL-incompatible. The requirement to ship
the license with binaries is also in the modified BSD license, which is
GPL-compatible per the FSF.
- Their "rtti" consists basically of integers of various sizes, arrays,
structs (which are plain arrays of elements) and pointers. You can't get
more basic than that, and we already have to convert everything down to
that level inside the compiler anyway to map Pascal types to the
official platform ABIs. It is nevertheless true that an API version
change in libffi could break compatibility with existing programs, so
you would have to ship libffi together with your program if you'd want
to avoid that.
* Michael:
- support for "register" and "pascal" calling conventions is listed in
libffi's readme (https://github.com/atgreen/libffi/blob/master/README )
- "As far as I can see the compiler just needs to simply write a small
block with the needed info in the generated executable. The RTL just
needs to match this. .. That this changes from time to time, I consider
much less of a problem. The .ppu files also change regularly, that is
just how things are..."  -- I think that is quite an insensitive
statement, because you won't be the one that will need to make such a
change or fix things as a consequence. And it's by no means comparable
to a ppu file change. It's only "a fact of life" that such a change
would have huge consequences if we choose so.

Look at the code of libffi (or better, don't — see below): we would
basically have to duplicate all of that code for the platforms we
support into the RTL, since all it does is dispatching and that's
exactly what we need. Well, not duplicate, since then we have the same
licensing issue as using that library — we have to implement it from
scratch without looking at its source code. And in case of x86-64, you
won't even be able to base yourself on the compiler source code, because
I translated the libffi code largely into Pascal to implement its
parameter manager. Seriously: it would mean I can't use libffi anymore
for my compiler work, or not work on the dispatching code in the RTL for
the same platform. Which means that I either cannot do complete ports by
myself anymore, or I cannot make use of the knowledge in libffi when
doing so (I also looked a lot at libffi for AArch64, so I won't be able
to work on RTL dispatching code for that platform either, even if I
wanted to).

Just like I may not be sensitive enough to people's issues with external
dependencies on some platforms, I'd like to ask other people to be more
sensitive to the work required to add and maintain support for a
particular platform in FPC (both compiler and RTL).


Jonas