[fpc-devel] RTTI interface & variant late binding issue (mORMot)
Sven Barth
pascaldragon at googlemail.com
Sat Feb 7 14:31:03 CET 2015
On 07.02.2015 14:27, Florian Klämpfl wrote:
> Am 07.02.2015 um 14:17 schrieb Sven Barth:
>> On 07.02.2015 13:54, Michael Van Canneyt wrote:
>>>
>>>
>>> On Sat, 7 Feb 2015, Jonas Maebe wrote:
>>>
>>>> On 07/02/15 11:58, Florian Klämpfl wrote:
>>>>> Just an idea: What about serializing TCGPara/TCGParalocation?
>>>>
>>>> The main issue I see with that is that this format changes from time to
>>>> time. I'll probably have to change it again to fully support the ppc64le
>>>> ABI.
>>>
>>> Nevertheless, Florian's proposal seems to me like the optimal solution.
>>>
>>> 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...
>>>
>>> As soon as a new platform appears you need to wait for libffi etc;
>>> the correct version needs to be installed and whatnot. I doubt this will
>>> cause less problems.
>>
>> Considering that we aren't the fastest to implement new platforms I don't think that this will be
>> much of a problem.
>
> Actually, FPC had win64 support before gcc/binutils.
Yes, that was one of the glorious exception that I still like to quote
when talking about Free Pascal :D
But other then that we aren't normally the first to implement a platform...
>>
>> Looking at their site I noticed however that there are a few platforms that we support that they
>> don't. For example m68k-amiga, i8086-msdos, arm-wince and some of the more exotic targets that we
>> have (GBA, NDS, Wii for example).
>>
>> So in the end a manager approach as Jonas suggested might be the best approach. Then we can for now
>> implement the main platforms using libffi and implement full FPC ones one at a time.
>
> As long as we have no realiable approach to prevent people to violate the libffi license, I wouldn't
> recommend to do so. Besides this I do not want either that every FPC compiled binary needs to come
> with a libffi license text.
Yes, the license might be the biggest problem here...
Regards,
Sven
More information about the fpc-devel
mailing list