Hi,

Just thought I would mention, yesterday Delphi 10.2 was released which includes Linux support (I assume a cross-compiler). It is only available in the Enterprise edition product line though, and only Linux Server style apps are supported (no GUI/desktop apps).

Just my 2c worth ;-)

Regards,
Graeme

Hi,

Graeme Geldenhuys wrote

Just thought I would mention, yesterday Delphi 10.2 was released which includes Linux support (I assume a cross-compiler). It is only available in the Enterprise edition product line though, and only Linux Server style apps are supported (no GUI/desktop apps).

I can't wait until we get the blame that Free Pascal on Linux is now incompatible with Delphi on Linux...

Charlie

At least not from me, I felt already ripped off by Embarcadero by not delivering on their promise to bring Linux last summer (Fortunately I did not renew my Pro-Subscription). Seeing that they wanted to do a 2nd rip off by only giving it to Enterprise customers reassured me that that decision was a good one.

So for me Freepascal is the master, not only on x86_64 linux but also on armhf-linux, arm embedded, wonder how long it takes Embarcadero to make their product available on arm-linux.....

So guys, pleae keep up your phantastic work, and goodby Delphi, we have been together since the good old Turbo-Pascal times, but you have changed into a money sucking beast, it breaks my heart but I am gone.....

Michael

Karoly Balogh wrote

I can't wait until we get the blame that Free Pascal on Linux is now incompatible with Delphi on Linux...

That crossed my mind too. God(*) help us all!

* - place with whatever name suites you.

Regards,
Graeme

When did FPC started to run on Linux? 1999?

Mattias

Graeme Geldenhuys wrote

* - place with whatever name suites you.

Anders Hejlsberg :)

-Michael

In our previous episode, Mattias Gaertner said:

It was there already in 1997. From the copyrights in the old units I think it is rather 1995. The old pre 2.0 Linux unit even had kernel 1.xisms in it.

Afaik the Embarcidera Delphi Linux is ARC based btw.

I got the first "hello world" around 1995-1996, I think, together with Mark May. (if memory serves well)

Michael.

Well, Delphi didn't start with a "Hello World". So that would be a little unfair as comparison.
What about the time when FPC was able to compile itself?

Mattias

Hi,

Well, there was Kylix anyway around 2001 or so, wasn't it? So not like supporting Linux is a rocket science, although FPC was definitely first.

My remark was more about, I still remember, Kylix had his own LibC unit, but because of (un)portability reasons, FPC never supported that anywhere but on i386. And that was already a source of massive whining, when people started to use x86_64 and other platforms, and they tried to compile their i386-only Kylix code elsewhere with FPC, and of course FPC was stupid and ugly for not supporting the LibC unit elsewhere.

So if this Delphi for Linux sticks around for a while, I predict the same happening all over again (just with feature X)... And I "pray" to be wrong on this.

Charlie

Am 23.03.2017 13:05 schrieb "Graeme Geldenhuys" <

In the end you'll just need the correct units to do GUI applications as well though one would need to do everything by hand as there'd be no VCL or FM :P

Regards,
Sven

Pretty soon after that. So end of 1996, I think.
I never liked cross-compiling.

Michael.

Il 23/03/2017 17:19, Sven Barth via fpc-pascal ha scritto:

In the end you'll just need the correct units to do GUI applications as well though one would need to do everything by hand as there'd be no VCL or FM :P

IOW with the newest Delphi for Linux you're in a worse condition than using old Kylix!

We are still supporting a lot of old Kylix applications, and, when I'm too lazy to bring up a VM with an old Linux supporting the Kylix IDE, I just edit the files using Lazarus, and then compile the app using dcc which still runs on today's distro's (provided you supply it the required Kylix libraries). Even the app runs on today distro's, provided you feed it with its 32 bit libraries.

Whenever possible we migrate the app to Lazarus, and then you feel like updating a Lazarus 0.9x app to Lazarus 1.6!

Giuliano

In our previous episode, Karoly Balogh (Charlie/SGR) said:

It didn't help that some component maintainers like Synapse stuck to the libc format way too long. Only in 2007-2009 when FPC on OS X got important that changed, I still use Indy(10) that switched much earlier to this day.

The fact that it took Inprise really long to spell out that Kylix was dead didn't help either.

Note that the Linux unit in 1.0.x had the same faults as unit libc, except its size. (and that includes being outdated, but I guess that goes for the 2.x style *nix rtl now too, since it is 13 years old last christmas)

The BSD maintaince of 1.0.x was truly a horror compared to 2.x, as the 1.0.x BSD rtl was more a ifdefed version of the Linux RTL than something in its own right.

9th august 1996 :)

Mail from Michael:

[...]

[...]

I take it this was before a version control system was used? :P

Regards,
Sven

Yes, we started to use cvs end of November 1997.

Marco van de Voort wrote

It didn't help that some component maintainers like Synapse stuck to the libc format way too long. Only in 2007-2009 when FPC on OS X got important that changed, I still use Indy(10) that switched much earlier to this day.

Having just removed the last vestiges of Libc.pas usage from our own project, this is entirely on the heads of the FPC maintainers. Whatever the concerns regarding Libc.pas, it's usage was simple: Add "Libc" to your uses clause, look up (extensive) function documentation and sample code in the standard Posix man pages and StackOverflow.

The recommended FPC approach, on the other hand, is a combination of "Use functions from the RTL, BaseUnix, or other random packages" and "Import the relevant functions yourself", and the documentation is "Hope some exists or that adding an fp prefix works". Add to that, sometimes the RTL does have the imports/record translations you need, but doesn't bother to expose them publicly.

Free Pascal has done great things, and I absolutely appreciate all of it, but not having a good alternative to Libc.pas or Delphi's new Posix.*.pas APIs has definitely been an annoying pain point.

Sven Barth wrote

In the end you'll just need the correct units to do GUI applications

Yeah, but I don't see Embarcadero going down that route any time soon [years if at all]. They already can't handle the amount of bug reports, plus no native IDE for non-Windows platforms (you try and convince a Linux developer to install Windows just to compile Linux applications).

Regards,
Graeme

The idea was, and is still today, that you can write applications that are independent of libc, and talk to the kernel directly.

No-one has ever offered to maintain a Libc import unit. It was provided only as a courtesy to Kylix devs.

That said, if someone steps up and offers to update Libc for all supported architectures, she/he is welcome. But be warned that this will not be easy. The structures depend highly on the CPU. Delphi supports only 2 CPUs (64-bit and ARM). FPC slightly more...

Michael.

In our previous episode, Zo? Peterson said:

The recommended FPC approach, on the other hand, is a combination of "Use functions from the RTL, BaseUnix, or other random packages" and "Import the relevant functions yourself", and the documentation is "Hope some exists or that adding an fp prefix works".

The baseunix unit was documented from the start and actually adheres better to manual pages than unit libc (which quite often uses artefacts from old kernels and not current mechanisms. Even current by 2003-4 standards)

And the fp prefix, while much maligned is at least systematic. No need to call _write or so.

Yes, it is less complete, but for that it is portable.

Could you name the mantis items with improvements/problems ?

In our previous episode, Michael Van Canneyt said:

And did so in different, less orthogonal times.

Michael Van Canneyt wrote

The idea was, and is still today, that you can write applications that are independent of libc, and talk to the kernel directly.

While this usually is the obvious way to go, there are some Arch and OS dependent user space things that are hard to perfectly manage in the fpc-RTL, but are optimizedly provided in the Arch and OS dependent library versions (e.g. Futex and (maybe) threadvar and "Atomic" support). I remember that since some time, the Linux Kernel itself offers "user space system calls" i.e. a "static" library used to do as well certain user space stuff as system calls wrapped in normal procedure calls. Astonishingly, last time I checked, Futex has not been included in that "library".

-Michael

First off, I’m sorry for implying that the current units are insufficient. I just looked through our code and we’re using far fewer “external ‘c’” definitions than I thought we were. The documentation generally looks good too, so I assume most of trouble was from not being as familiar with Free Pascal’s RTL layout and using search techniques that worked better for Delphi/Kylix than for it. We had to maintain both FPC and Kylix code in parallel for several years too, and that undoubtedly made things more complicated than they would have been otherwise. I’ll keep that bias in mind in the future.

Michael Van Canneyt wrote

No-one has ever offered to maintain a Libc import unit. It was provided only as a courtesy to Kylix devs.

That's probably because the Wiki says:

"The libc unit is deprecated, and frozen in time for Kylix compatibility, and won't be ported to other architectures or operating systems."

It also has a long list of other reasons why the entire idea is flawed. We had a rough port to both Linux64 and Darwin32 but never tried to submit those changes back for that very reason.

That said, if someone steps up and offers to update Libc for all supported architectures, she/he is welcome.

This is another instance where you’re (possibly unconsciously) discouraging people from submitting patches. By saying “update ... for all supported architectures”, you’re implying that adding Linux64 or Darwin isn’t worth it unless they also spend time on ARM, Haiku, and uclibc. I certainly understand that from a idealogical point of view, but if someone doesn’t have the time or knowledge to cover everything, it does make it seem like a partial patch wouldn’t be welcome. OTOH, maybe that is intentional, and I can’t say it’s wrong, since it does provide a high barrier to expanding the scope of that unit.

In any case, it’s not relevant for us now. As I said, we recently removed all of our Libc.pas usage.

Marco van de Voort wrote

Could you name the mantis items with improvements/problems ?

No, though I’ll try to submit some for the cases where there could be improvement.

The only thing I can think of that would have been retroactively useful is if Libc.pas had included deprecated declarations with messages saying where the replacement units/methods are.

—
Zoë Peterson
Scooter Software

In our previous episode, Zo? Peterson said:

It is important to realize that the libc unit was never FPC's primary api.

It was _always_ merely a kylix compatibility unit. Before the current set the primary api was the "linux" unit, which was later renamed to "unix".

These units already supported *BSD before Kylix even existed.

It also has a long list of other reasons why the entire idea is flawed. We had a rough port to both Linux64 and Darwin32 but never tried to submit those changes back for that very reason.

I still think that is a good thing (abandoning unit libc). While individual calls might be fixable, as a whole it isn't.

If a new effort was made, I'd rather have new libc.so importing units that were fairly portable to all *nix targets.

Yes. Which is why at least I tried to discourage that whole idea.

It is not just ideological, merely practical. By indicating you are accepting partial patches you risk either committing them before the other platforms are ready and setting a bad api/precedent, or leaving the patches to linger in mantis forever.

Better direct the efforts to something better managable.

The only thing I can think of that would have been retroactively useful is if Libc.pas had included deprecated declarations with messages saying where the replacement units/methods are.

The libc unit has had that status since 2003-2005. Deprecated and even more deprecated-with-messages was a much, much later feature (2.4, 2010?). There had been only the most minimal patches for unit libc (and virtually no indications of serious usage) for years by then.

I think a better solution would have been to support large parts of the FPC api on top of Kylix. But when I reacted with comments like that I was usually met with a reluctance to invest in you get a catch-22 with still supporting kylix but not investing it, not even to manage its legacy.