On 02/01/15 15:59, Jeppe Græsdal Johansen wrote: > Den 02-01-2015 kl. 15:07 skrev Jonas Maebe: >> After just having spent 2 days debugging an issue in fcl-res that could >> have been avoided by just using the assembler instead of by >> reimplementing object writers from scratch, I'm even more strengthened >> in my conviction that it is a mistake trying to implement and >> reimplement everything just to make cross-compiling somewhat easier, or >> to avoid libc version compatibility problems on Linux that were common >> 15 years ago. >> > I pretty much disagree on all points. Maybe it's nice if you sit on some > popular flavour Linux,
Our basic "manager" units are independent of Linux flavours and should not introduce any dependencies on a particular flavour or version of Linux. > but relying on GNU tools and libraries is a pain > point on Windows and for crosscompiling in general. We have never relied on GNU libraries on Windows, and I didn't mean to imply that we should. On Windows, we do however rely on standard OS library functionality for threading, localisation etc rather than implementing it ourselves. That's what I'm in favour of. As to assemblers/linkers: in the compiler, the internal assemblers and linkers are optional, so there it doesn't really bother me. > For library components such as cthreads, cwstring, clocale, etc. it's > nice to have a choice whether you want libc provided units. We have > those already, and they mostly seem to work(?). But I think it would be > nice to have both, so you could at least have a choice whether you would > want to skip right over building a bunch of C. You don't have to build a bunch of C. You copy over the libraries from the Unix system you want to deploy on. If you don't have access to such a system, then you can't test your program either and you have bigger problems than a lack of libraries. > For object writers and assemblers, sure. There are probably lots of > problems, but I haven't had any big issues on Windows with FPC for soon > a decade. I hope that can become the case for ARM/Linux/Embedded too > soon :) I've had major problems with the integrated object writer of fcl-res both with the AIX port in the past and now with the Darwin/AArch64 port. It's not because its architecture is bad (it's not), but because it's a lot of fiddling with low level stuff for which barely any debugging tools exist, and for some details also documentation. It's just completely wasted time and effort on my part that I could have spent on doing useful things. And to top it off, you'll still need the libraries and cross-binutils (to the extent that they exist) for both targets, because neither Apple nor IBM supports syscall compatibility across OS versions (libc is their "system call interface"), and maintaining a binary writer and linker for Apple's ever changing stuff would be more or less a full time job by itself (maybe for AIX it would be more doable). > It just need some testing on a wider scale for all the bumps to be > ironed out. If you never add new targets and your existing targets stay completely static, maybe. Otherwise you keep encountering new bumps because things change slightly, or you have to implement support for new targets, which in turn also adds new bumps. Jonas _______________________________________________ fpc-pascal maillist - [email protected] http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
