I have to import the math.h libc functions listed here <http://pubs.opengroup.org/onlinepubs/009695399/toc.htm>. What is the recommended way to do this for general Linux compatibility ? Simply declare them external ? Load them from libc dynamically ? Anything else ? I know that the FPC runtime lib itself jumps through some hoops to be as independent of libc (or a specific version of libc) as possible.

Regards,

Adriaan van Os

Hi,

We actually link against libc and pthreads when multithreading is involved
on Unices. You need to declare all functions cdecl; external;

See the cmem unit in the RTL for example, which provides simple link-against-C examples for a number of platforms, both dynamic and static linking case (pick the option which fits best your usecase):

https://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/rtl/inc/cmem.pp?view=markup

Charlie

In our previous episode, Adriaan van Os said:

I have to import the math.h libc functions listed here <http://pubs.opengroup.org/onlinepubs/009695399/toc.htm>. What is the recommended way to do this for general Linux compatibility ?

Not do this ? :-)

Simply declare them external ? Load them from libc dynamically ?

Just declare them external in a separate unit, mathc or so and keep them in your project.

Anything else ?

Macros, structured constants etc, obviously might require extra work(and mathh has some, like the is* functions are typically macros)

Long double is probably 10-byte extended, but verify that by compiling and running a small C program for your distro.

I know that the FPC runtime lib itself jumps through some hoops to be as independent of libc (or a specific version of libc) as possible.

The FPC RTL can use libc (compile with -DFPC_USE_LIBC), but this is nowadays little tested outside of OS X, and maybe a couple of smaller targets.

The libc policy is due a multitude of small issues, some of which might be historic, and the idea was to allow the maintainer to chose what approach fits his target best.

Anyway it only touches redistributable code to be merged with FPC to keep the .tar somewhat distribution indepedent. For your private stuff you don't have to worry about it.

Marco van de Voort wrote

Long double is probably 10-byte extended, but verify that by compiling and running a small C program for your distro.

I assume that the FPC clongdouble type has the right size ? I checked on OS X (x86) where FPC longdouble is 10-byte, FPC clongdouble is 16-byte and GCC long double is 16 byte too. So, as long as I use clongdouble for the external declarations, there should be no problem (I hope).

Thanks for the reply regarding the other issues.

Regards,

Adriaan van Os

In our previous episode, Adriaan van Os said:

> Long double is probably 10-byte extended, but verify that by compiling and > running a small C program for your distro. I assume that the FPC clongdouble type has the right size ?

Define "right".

I checked on OS X (x86) where FPC longdouble is 10-byte, FPC clongdouble is 16-byte and GCC long double is 16 byte too.

Maybe a heritage of PPC that did have a 128-bit fp type. But x86/x86_64 to my knowledge doesn't have such type, and I just tested and Linux

uses unixtype;
begin
  writeln(sizeof(clongdouble));
end.

writes "10".

Afaik some work has gone in softfloat in the last years, and maybe there is an emulated 128-bit type now, but that is news for me. (Florian,Jonas: ?)

So, as long as I use clongdouble for the external declarations, there should be no problem (I hope).

glibc might have changed from ye old days when it was 80-bit. Which is why I recommended to double check in the first place.

Well, a cxxx type is "right" if FPC cxxx and GCC xxx have the same size, which after all is the purpose of having these types in FPC.

When I look at the source of GCC and GPC for OS X, I believe it is a 10-byte extended stuffed into a 16-byte type. Calling e.g. sinl works fine on OS X when declared either "wrong" with 10-byte or "right" with 16-byte parameters.

glibc might have changed from ye old days when it was 80-bit. Which is why I recommended to double check in the first place.

Will do so.

Regards,

Adriaan van Os