Technical problems that need to be solved
Most problem reports about Kylix have been about its IDE. As a Linux IDE is not part of the suggested strategy, the number of problems that need to be resolved also are rather small.
First of all, the Linux compiler needs to be ported to Win32, becoming a cross-compiler. As explained above, this will be a rather easy task.
The only important difference between Linux and Windows compiler-wise really is that Linux shared libraries (.SO, the equivalent of a Windows .DLL) use position-independent code. While Windows DLLs need to be relocated when loaded, Linux .SO only use relative addressing, and therefore may be loaded to any memory location.
A detailed explanation of the process can be found here:
http://en.wikipedia.org/wiki/Position_independent_code
For the compiler, this means that whenever a library is compiled, one register less may be used.
All these changes to the Delphi compiler that were required to port it to Linux also ended up as improvements to the Delphi code base as far as I know.
Therefore there aren’t any blocking issues to be expected in this area.
Next topic is the linker: As the ELF binary format doesn’t feature a resource-embedding system like Windows’ PE file format does, Borland was required to add their own extensions to ELF. This required them to write their own linker instead of using the standard Linux one (gnu ld). This now is a major benefit: The Kylix ELF linker was written from scratch, and does not have any external dependencies. This means that it’s technically pretty cross-platform ready – it probably will compile under Windows with only minimal changes.
There are a few small issues that will need to be fixed, though. The most important one is the oversight that the linker puts a small part of start-up code into a data segment not marked for execution – on security-hardened Linux kernels code inside segments not marked for execution won’t be executed.
This Problem is explained in detail in my article “Fix for Kylix-built applications crashing under Linux 2.6.8 Kernels with Exec-Shield enabled” at
http://crosskylix.untergrund.net/execshield.shtml
The article also includes workarounds and possible fixes for the issue.
Another issue is that back when Kylix was released, symbol versioning for shared objects got introduced to Linux. This versioning scheme allows several versions of a shared object to exist on a single system, with the application requesting the shared object stating which version of the library it needs compatibility with. A newer library may then export symbols with different versions, providing backward-compatibility. The system has turned out to work really good, sadly it wasn’t implemented in the Kylix linker. Due to Kylix-linked executables missing the version information tags, the Linux dynamic linker falls into a GLIBC2.0 compatibility mode for Kylix applications under many Linux distributions. This results in Kylix executables getting bound the oldest possible GLIBC shared object symbols. And this again results in Kylix-linked executables not getting access to all improvements in GLIBC during the last few years – the most important being the extremely high-performing Native Posix Thread Library that Kylix already is compatible with.
To solve this issue, the linker will not need to fully implement the versioning system of glibc – actually it will be perfectly fine not to emit those version symbols at all for Kylix-created shared objects. The only thing that’s really needed here is that for all linked executable, the GLIBC ELF version tags are included in the binary, and all GLIBC imports (libc.pas) get an adequate version assigned.
Implementing this should probably be doable in 100-200 lines of C source at max.
The Delphi RTL still is a cross-platform Windows/Linux one. However, for all changes done to it after Delphi 7, changes compatibility with Linux have not been tested. It’s expected that especially a few of the FastCode RTL replacement routines will be in need for some modifications.
The FastMM memory manager now shipping with the Delphi RTL already is verified to be Linux compatible.
This will need some research, but as DBExpress had been designed fully with cross-platform support in mind, getting it to support Linux again probably will be a rather easy task.
Both Indy and IntraWeb are Linux-compatible. What other technologies part of Delphi could be interesting to have server-side Linux support needs to be researched. Getting support for the creation of Apache modules will be important.
Just forget about it. CLX had some fundamental problems:
The VCL got tested by Borland by using it when developing the IDE itself. This improved stability a lot. This wasn't done with CLX, as the Kylix IDE didn't use CLX but VCL via WineLib. The result was the CLX wasn’t really ready for prime time. What’s more, CLX got back-ported to Windows, using QT on that platform, too. In reality, nobody wanted to use CLX on Windows, because it felt non-native on that platform. Therefore, most people ended up in having IFDEFs in their code to use VCL for Windows and CLX for Linux. Not quite convenient.
The better way to one day support cross-platform Desktop GUI development would be to have VCL and CLX single-sourced. Components would need some kind of “platform” mark to show which platforms they are compatible with.
Anyway, this is nothing of immediate worry – using Delphi as a cross-compiler for GUI applications would be a future task. And probably most of this work could be done by a community project at a later time.