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

[Florian Klämpfl]

Am 07.02.2015 um 14:31 schrieb Sven Barth:
>> 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...

Well, quiet logical if we depend on other utils.

> 
>>>
>>> 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...

But not the only one, libgdb is a good example what the issue with external libraries in core parts
of FPC. Typical procedure before release building for win32: try randomly mingw and gdb versions to
find a pair which compiles a libgdb *and* results in an IDE with a working debugger. Unfortunaly,
even if everything runs at a first glance, there is no guarantee that things work flawless as before
because something in the C header could have changed causing random crashes. 700 lines defines and
ifdefs (!) at the start of gdbint.pp tell the story.