答案 0 :(得分：9)
正如Mason所说，我们将CrossKylix用于Beyond Compare的Linux版本，但仅适用于从FinalBuilder启动的版本构建。对于这种用法，它很棒。我们确实尝试在Windows上进行CLX开发一段时间，但是CLX for Windows与Linux的CLX有不同的错误，因此它不值得长期使用。
我们的实际Linux开发仍然使用在SuSE 10虚拟机上运行的Kylix 3完成。我们使用GDB和Kylix调试器进行调试，尽管Kylix调试器不再适用于后台线程。我们很久以前就放弃了CLX设计时支持，因此几乎所有的功能开发都是在Delphi 2007和VCL中完成的。
我也积极使用Simon的其他项目CrossFPC作为我们的64位Windows shell扩展，并且它运行良好。
答案 1 :(得分：8)
我正在使用CrossKylix多年，它对我来说就像一个魅力。 这是我喜欢在源代码中保持Delphi 7兼容性的原因之一，因为Kylix 3基于与Delphi 7相同的编译器：只有后端生成本机ELF文件而不是EXE。
对于服务器应用程序和命令行工具，即使是一个小的cgi程序，CrossKylix也很棒！您可以在Windows下使用Delphi进行开发和测试，然后对其进行交叉编译，并在Linux下运行可执行文件没有问题。 我已经在法语“dedibox”上使用了多年，在Via C7（现在更快的Nano）CPU下运行，并且以每秒1500 KB的速度对数据进行AES和SHA加密（是每秒KB，不是每秒字节数）这要归功于PadLock引擎！
我在现代linux下发现了Kylix RTL和WideString的一些问题：如果您的Linux使用UTF-8编码进行配置（现在是大多数发行版的标准），则WideString使用失败。所以我在Kylix system.pas中已经纠正了这个问题。事实上，我们的增强型RTL是跨平台的，可以与Delphi 7和CrossKylix一起使用。 见http://synopse.info/forum/viewtopic.php?id=66
答案 2 :(得分：3)
在one of Jim McKeeth's early podcasts,中，他采访了Scooter Software的Craig Peterson，他是BeyondCompare的编码员之一。他提到了他们如何将CrossKylix用于BeyondCompare的Linux端口。