[m-users.] Can't compile sample programn

[Julien Fischer]

Hi Peter,

On Wed, 20 Mar 2019, Peter Wang wrote:

> On Wed, 20 Mar 2019 23:23:47 +1100, Peter Wang <novalazy at gmail.com> wrote:
>> On Wed, 20 Mar 2019 12:44:28 +0100, Volker Wysk <post at volker-wysk.de> wrote:
>> > 
>> > I've tried it with --link-object posix_workarounds.o and --extra-library-
>> > header posix_workarounds.h, like you've written. This works. But I think this 
>> > shouldn't be necessary to specify every time, after the library has been 
>> > correctly installed. Am I right?
>> > 
>> 
>> The workarounds for the FD_* macros might not even be required on any
>> modern systems. It will take some effort to confirm. The easiest option
>> would be to just remove the workarounds and put them back only as
>> reports come in, if they do.
>
> And if we do need to reinstate any workaround, it may be done in a
> different way. IIRC, the only problem was FD_ZERO being defined with
> inline assembly in glibc headers, where the assembly code conflicts with
> low-level C grades using gcc global register variables. We could just
> use memset (or MR_memset) instead of FD_ZERO, for example.

For FD_ZERO we could just use MR_fd_zero from the runtime; we use both
FD_SET and FD_ISSET in the runtime already without any workarounds.
That leaves only FD_CLR.  I think we should just remove
posix_workarounds and if any of FD_{SET,ISSET,CLR} prove problematic,
just add them runtime/mercury_reg_workarounds.

Julien.