View Issue Details

IDProjectCategoryView StatusLast Update
0036778FPCCompilerpublic2020-04-08 23:55
ReporterNoName Assigned ToMarco van de Voort  
Status closedResolutionwon't fix 
Product Version3.3.1 
Summary0036778: Define FPC_USE_LIBC on Linux by default
DescriptionThe define FPC_USE_LIBC isn't set by default for Linux even if libc is always available in a recent version (no issues with non-availability of functions).
All the information available about this define is from 0001641:0002006 (see below).
The fpc syscall, which is done when define is not defined, slows down the function calls a lot which affects a lot of stuff which is provided by libc (
Additional Information
TagsNo tags attached.
Fixed in Revision
Attached Files



2020-03-09 22:59

reporter   ~0121510

Last edited: 2020-03-09 22:59

View 2 revisions

No idea why it changed '~ 2006' (w/o whitespace) to 'from 0001641:0002006 (see below).' :o

Marco van de Voort

2020-03-09 23:08

manager   ~0121511

Last edited: 2020-03-09 23:10

View 3 revisions

FPC_USE_LIBC was done as a fallback, and quick port solution. It actually originates on FreeBSD, but when the linux RTL was redone, it also got it.

The general consensus is that the syscall binaries are more cross *nix (both distro and distro version) portable, it has nothing to do with availability of libc or not. There some exceptions like Mac OS X, because OS X is quite decent with multiple SDK version support.

Your speed claims are unsubstantiated.

Maybe discuss things with wide consequences like this on the maillist first before filing a bugreport.


2020-03-09 23:11

reporter   ~0121512

Are you sure? Wouldn't say that factor 60 is unsubstantiated

GetTickCount64 fpc 2 494 563 op/sec
GetTickCount64 libc 119 919 893 op/sec

Marco van de Voort

2020-03-09 23:54

manager   ~0121514

Last edited: 2020-03-10 00:01

View 2 revisions

Well, first you didn't mention that in the original report. Second it is only one unrelated call, and third a not very important one, performance wise. Fourth, if for some reason you are for some strange reason performance bound in gettickcount64, you can just import the relevant calls.

Using a syscall based RTL doesn't prevent importing libc functions if the need arises

Tomas Hajny

2020-03-10 00:07

viewer   ~0121516

You don't mean the GetTickCount64 example as a generic proof of your claim, do you? Do you have some real-world applications which show tangible performance increase if using LibC based RTL on Linux?

As far as use of older syscalls is concerned - the possible approaches described on the Wiki page are indeed valid (including the described pros and cons). If a particular old syscall causes issues on newer kernels, it's possible to create either a dynamic solution (with the correctly described drawbacks of slower startup and broken smartlinking), or a static one using a special build of RTL with an IFDEF (again correctly described as resulting in the drawback of broken compatibility of the built binary with older kernel versions). Using LIBC doesn't make a big difference with regard to that (well, you could get both slower startup and incompatibility with older versions at the same time that way, but I wouldn't call that an advantage ;-) ).

Apart from that, FPC_USE_LIBC is available and anybody may decide to recompile FPC RTL this way without forcing the same change to others.

Sven Barth

2020-03-10 09:40

manager   ~0121525

I definitely prefer that FPC_USE_LIBC is *not* set by default as this easily allows a FPC binary to be used on different systems. In fact it easily allows to test different architectures thanks to QEMU's userspace emulation without the need to set up a userspace with libc for that architecture.
Also thanks to the Android target we don't have to fear degradation of the Linux LibC support anymore (which was a potential danger before that target came along) while if we enable FPC_USE_LIBC by default the non-LibC variant would likely degrade.

That said this doesn't stop us from improving functions like GetTickCount64 (or more precisely the syscalls that function uses).

Marco van de Voort

2020-03-10 11:21

manager   ~0121529

Last edited: 2020-03-10 11:24

View 3 revisions

Changing to FPC_USE_LIBC is a momentous change for a single function's performance difference, that is easily worked around. Moreover the bugreport only argues about one thing being faster, without specifying what is good enough and why.

However the big issue is that not much is known about the /detail/ practicalities of FPC_USE_LIBC on Linux. To fix this minor thing, 20 major ones might pop up in packaging for various distributions. The syscall decision was made in times when some distributions (Mandrake) shipped beta libc with all legacy options turned off, while at the same time the last debian stable was half a decade old branch. It is possible that that decision is outdated, BUT

Most knowledge is either old, based on assumptions and/or gut feelings. In practice we simply don't know how many users will get into problems if we change over, and how common these problems are. IOW how portable is a non trivial libc program in practice? Can we work around some of the issues with separate bootstrap compilers that are syscalls only?

So first quite some (non anecdotal) experience would have to be built up with releases built this way (either by FPC releases, or releases prepared by friendly projects). This makes it a multi-year process.

For further discussion I refer you to the maillist and/or forum.

Issue History

Date Modified Username Field Change
2020-03-09 22:55 NoName New Issue
2020-03-09 22:59 NoName Note Added: 0121510
2020-03-09 22:59 NoName Note Edited: 0121510 View Revisions
2020-03-09 23:08 Marco van de Voort Note Added: 0121511
2020-03-09 23:09 Marco van de Voort Note Edited: 0121511 View Revisions
2020-03-09 23:10 Marco van de Voort Note Edited: 0121511 View Revisions
2020-03-09 23:11 NoName Note Added: 0121512
2020-03-09 23:54 Marco van de Voort Note Added: 0121514
2020-03-10 00:01 Marco van de Voort Note Edited: 0121514 View Revisions
2020-03-10 00:07 Tomas Hajny Note Added: 0121516
2020-03-10 09:40 Sven Barth Note Added: 0121525
2020-03-10 11:21 Marco van de Voort Assigned To => Marco van de Voort
2020-03-10 11:21 Marco van de Voort Status new => resolved
2020-03-10 11:21 Marco van de Voort Resolution open => won't fix
2020-03-10 11:21 Marco van de Voort FPCTarget => -
2020-03-10 11:21 Marco van de Voort Note Added: 0121529
2020-03-10 11:23 Marco van de Voort Note Edited: 0121529 View Revisions
2020-03-10 11:24 Marco van de Voort Note Edited: 0121529 View Revisions
2020-04-08 23:55 NoName Status resolved => closed