libutil: move ftime to libutil

[oshogbo]

Summary

It seems that there are still some applications that use ftime(3)
(for example, science/siconos, and sysutils/lcdproc). The issue
is that we don't build libcompat as a shared library anymore.
The easiest solution is to move it to libutil, until we
deprecate it for good.

This solution was proposed by kib@ in
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257789.
Author of that bug refers to the issue with science/siconos,
and recently I had similar issue with sysutils/lcdproc.

[oshogbo]

Update description.

[kib]

The easiest solution is to move it to libc, until we deprecate it for good.

If we export something from libc, it is there forever. AFAIR this was the main reason why I left it untouched.

Might be, move it to libutil instead?

lib/libcompat/4.1/ftime.c

41

This is too rude, and in principle could cause a grief from the compiler. Perhaps a better approach would be to change sys/timeb.h to do something like this

#if !defined(_IN_LIBC) && defined(__GNUC__)
#warning
#endif

Then define _IN_LIBC before including the header.

[oshogbo]

Move to libuitl

[oshogbo]

kib@ thank you. Moved to libuitl.

[kib]

lib/libutil/ftime.c

36

I suggest to change the protection symbol name to _IN_LIBUTIL, this way it is more consistent with existing practice of IN_RTLD/IN_LIBSA/IN_LIBDL

[oshogbo]

Yes, thats make sense. Thank you.

[kib]

lib/libcompat/Makefile

12

Did you checked that buildworld succeed?

Anyway, eventually you might want to move ftime sources to lib/libutil.

[oshogbo]

@kib

lib/libcompat/Makefile

12

Yes, I have.

I have moved it to the lib/libutil, maybe phabricator didn't refresh your cache or something:
{F61226090}

[kib]

lib/libcompat/Makefile

12

I see what you did now. The compat/4.1 confused me, and is it needed? libutil is single-directory library, why add the complication?