Change Details

libc: move ftime to libc 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. And even if we did, these applications are not linked to it. The easiest solution is to move it to libc, 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.

libc: move ftime to libc 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.

libc: move ftime to libc 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. And even if we didThe easiest solution is to move it to libutil, these applications are not linked to it.until we The easiest solution is to movdeprecate it to libc, until we deprecatefor good. 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.