Forwarded message from marcov@stack.nl (Marco van de Voort):

Subject: Re: c library imports revisited In-Reply-To: 1109917477.4701.80683@goedel.fjf.gnu.de To: Frank Heckenbach ih8mj@fjf.gnu.de Date: Mon, 7 Mar 2005 13:12:30 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL118 (25)]

: We do offer a limited selection of Unix calls though, but these are targeted : for specific Unix use, and in no way a substitute for the general calls in : e.g. an unit sysutils. They are prototyped roughly as the C calls, but : with "fp" prefixed, so manual pages still apply.

This probably explains what Rick was wondering about. If even glibc interfaces changes frequently (I suppose so, I'm not following them closely myself), other system's libcs are vastly different ...

About half the breakage occurs in startup files, mangling, and dealing with stuff like tls and threadsafe errno workarounds. GPC being gcc based might have less problems with that. OTOH GPC will typically rely heavier on libc, which might also cause different problems. (for FPC, the only thing that matters is the binary api, no C code)

The other half are more definitions changing, and distro maintainers that retire legacy calls earlier than others.

constant, rewriting) AFAICS would be either to have a 100% automatic translator that handles everything that occurs in some libc headers (which is likely to be all of standard C + extensions, via macros and inline functions), or to write wrappers in C that use the libc routines in the C way (thus being able to include headers as designed) and provide a well-defined C/Pascal interface. That's basically what we do in the RTS for a subset of libc (sometimes providing a bare-bones interfaces, sometimes higher-level).

This is extremely difficult (we also thought/tried this). Personally, I have given up on C2pascal like programs being fully automatic, and consider them more as a tool for manual translation. Even if it works, the output is horribly ugly, comments are stripped etc.

For the commctrl windows header,

1) I wrote a simple (200 line) pascal program that did some basic conversion and stripping of microsoft directives etc, sorting constants, structures and procedure defs into separate files, expanding simple macro's (that only were a bunch of typecasts). All done very simple, basic on heuristics, and modifying till output is ok.

2) Then I postedited the individual files with some global search and replace, and ran them through h2pas for the basic conversion (for the structs). The constants I fully converted using block-editor commands and search-n-replace.

3) Then again search and replace time and some simple filter procs (e.g. external clauses in calls)

4) Then manually merging, checking and fixing (days of work, but these are 10000+ lines), converting more complex macro's etc.

(the commctrl macro's where very picky about typing. They contained such systematic typecasting, one could infer the parameters typing, greatly increasing the automatic conversion ratio)

The basic problem with this process is the amount of manual labour (I did it in lost hours in trains etc), and the batchwise operating. Noticing an error in the conversion of (1) can't be corrected by redoing (1) since then all manual editing must be redone.

The trouble with C to pascal parsing is that everybody tries to go for the silver bullet of 100% automatic conversion. They all fail, and nobody is interested long enough to try a second approach, something what is more a construction kit for converting headers or so, or a scriptable or assisted system.

As I wrote the other day, automatic translation for most other C libraries is probably a whole lot easier (as glibc headers contain some of the most complicated macros I've seen so far in external headers, apart from the Linux kernel headers) ...

Try *BSD startup binary sources (crtbegin/crt0 etc) I once had 6 pages (roughly 100-150 lines) that became 12 asm instructions. They have cleaned up a bit since though.

The big funny thing was that it was a portable wrapper for syscalls. However the file was marked as "i386 only". Even if it was portable, it was so complex that I only figured it out by comparing 1) objdumped assembler files, 2) -S output 3) the source

P.s. Jedi also did an attempt at a header convertor, based on an experiment of dr Bob:

http://delphi-jedi.org/TEAM_DARTH_HOME or search for "headconv"

Afaik it is roughly the same principle as the FPC one, but less maintained (and the FPC one is already essentially unmaintained)