(draft) libc: Use __sym_compat() to fix references to compatibility system calls

[olce]

Summary

The stance used in commit f72908c94df9 ("libc: properly reference
setgroups@FBSD_1.0 in initgroups@FBSD_1.0") is peculiar, and the
__weakref__ attribute requires the symbol to be internal (which poses
a problem for static linking, but for some reason not for dynamic
linking).

Instead, use the existing __sym_compat() stance, which works as long as
the referenced symbol does not have the same name as some in 'libc'.

Explain in libsys' Symbol.sys.map that exporting older system calls by
their internal name does not work in libc, and is only for the sake of
other libraries/programs.

Sponsored by: The FreeBSD Foundation

[olce]

Spawned after experimenting around D52672. More explanations on why some things work and some others don't are more than welcome.

[kib]

lib/libc/gen/gen-compat.h

66

This really cannot work, it would try to version the libc symbol, instead of forcing libc link to external versioned symbol.

lib/libsys/Symbol.map

19

In fact these exports should be killed. libc can and shall properly link against versioned public exports, which I do in D52687

[olce]

lib/libc/gen/gen-compat.h

66

It works in practice, as shown by my tests, that's why I'm proposing it.

Yes, it versions the libc symbol, but why is that a problem?

But the question of why this is needed remains. Even if the freebsd14_setgroups() syscall is also defined in libc, auxiliary filtering should still find and use the same symbol in libsys, and everything should have worked since my first commit.

I'm now wondering if it's in fact filtering in rtld that is broken somehow.

lib/libsys/Symbol.map

14–19

Shouldn't we just remove these?

19

Yes. But the question of why these exports have not worked remains.

[olce]

lib/libsys/Symbol.map

14–19

Shouldn't we just remove these?

Old comment that was sent with the last batch but predated your own "In fact these exports should be killed".

[olce]

Fixed in D52687.