[fpc-devel] Proposal to adapt search patch under Haiku using a target specific option (-WH).

Karoly Balogh (Charlie/SGR) charlie at scenergy.dfmk.hu
Wed Jan 2 18:42:38 CET 2019


On Wed, 2 Jan 2019, Olivier Coursière wrote:

>> Should linking without libc (as in, libroot) be supported?

> I have only maintained the libc/libroot part since the beginning of
> Haiku port ten years ago.

Well, we do have other libc-only ports, like the macOS/Darwin version.
It's best to remove it then. That code looks really old anyway, and not
made with the current compiler in mind when it comes to asm capabilities
for example, so if anyone wants it, probably best to re-add from scratch.

(Which actually leads us to the question of BeOS port, I'm not sure if
there's interest to bring it up to speed again in any way.)

>> - see the legacy comments in si_c.pp and si_dllc.pp and figure out what
>>  to do with those. (Probably only needed to support BeOS, but not
>>   Haiku?)
> This comment on a Haiku's commit might help you in that area :
> https://git.haiku-os.org/haiku/log/?id=22ca923f71dd2d59d7f314d186801acb50524106&showmsg=1&qt=grep&q=23975
> "BeOS R5's glue code incorrectly calls _thread_do_exit_notification()

Yeah, I was already suspecting something like this, after looking into the
libc exit code, thanks. The exit notification stuff can be remove then.
(Now that it's in Pascal, it's quite easy! :)

 > - clean up the old linker support
> I don't know what you mean here. fpc currently use Haiku's ld under Haiku.

I mean the linker code still aims to support non-libc linking, which is a
bit confusing. If no one has worked on it for 10 years and known to be
broken, and no benefits to fix it, maybe it's time to remove it. :)

> - move to a "buildrtl" system for easier future maintenance
> It is simple enough for me so far at the current rate (a few commits a
> year in the Haiku area). But if it could be easier, shared and
> consistent with other platforms, + 1 !

Well, it makes the bulk of the RTL a bit easier to rebuild with Lazarus at
least, and a tiny bit faster from the command line, because it only makes
one compiler invocation from then on for most of the units. But not all
platforms use it, so it's up to the platform's maintainer to decide. :)

> - port/fix to 64bit
> With the already proposed changes to simplify the initialization part,
> it is probably "just" a matter of :
> (...)

Yup, that list sums it up. Also I'm not sure the do_syscall code is still
used in Haiku RTL at this point, but if yes, it needs to be adapted to
64bit too. (Or remove if not needed.)


More information about the fpc-devel mailing list