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 _______________________________________________ fpc-devel maillist - [email protected] http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
