AC_CHECK_FUNCS([utime]) fails with rumpapp-xen-configure

[mato]

Adding AC_CHECK_FUNCS([utime]) to tests/configure/configure.ac results in the configure test for utime() failing when it should succeed. Originally found when trying to build PHP, this causes the build to fail and requires manual modification to the generated config.h to succeed.

The test program used by configure looks like this:

/* Define utime to an innocuous variant, in case <limits.h> declares utime.
   For example, HP-UX 11i <limits.h> declares gettimeofday.  */
#define utime innocuous_utime

/* System header to define __stub macros and hopefully few prototypes,
    which can conflict with char utime (); below.
    Prefer <limits.h> to <assert.h> if __STDC__ is defined, since
    <limits.h> exists even on freestanding compilers.  */

#ifdef __STDC__
# include <limits.h>
#else
# include <assert.h>
#endif

#undef utime

/* Override any GCC internal prototype to avoid an error.
   Use char because int might match the return type of a GCC
   builtin and then its argument prototype would still apply.  */
#ifdef __cplusplus
extern "C"
#endif
char utime ();
/* The GNU C library defines this for functions which it implements
    to always fail with ENOSYS.  Some functions are actually named
    something starting with __ and the normal name is an alias.  */
#if defined __stub_utime || defined __stub___utime
choke me
#endif

int
main ()
{
return utime ();
  ;
  return 0;
}

Building the above as configure would do it, rumpapp-xen-cc.configure -o test test.c results in the link failing with an undefined reference to utime. Running the same test on NetBSD-current succeeds, looking at what libc provides there:

compat_utime.o:
                 U __utimes50
0000000000000000 T _utime
0000000000000000 W utime

The rumprun-xen libc does not provide these symbols at all. Any ideas on how to fix this?

[justincormack]

So the symbol is from compat, which we don't build. Does PHP really not have a fallback for no utime? "POSIX.1-2008 marks utime() as obsolete" says the man page, it should at least fall back to utimes.

[anttikantee]

The problem is the NetBSD libc/compat is both for versioned interfaces and obsoleted interfaces. We're not interested in old versions of versioned interfaces, but we might be interested in obsolete libc stuff (as we can observe above ;)

Apart from plowing through src/lib/libc/compat and separating the two (and mounting the crusade to get that into NetBSD), I don't currently have a good solution.

[mato]

Nope, no fallback at all. Additionally, due to the way the #ifdefs work in the PHP code, it fails to define a "virtual utime" macro and the buld fails with VCWD_UTIME being undefined.

[mato]

unsetenv() also fails a similar test, this time with the Hiawatha web server which uses CMake to build.

[justincormack]

On Jan 20, 2015 1:16 PM, "Martin Lucina" notifications@github.com wrote:

Nope, no fallback at all. Additionally, due to the way the #ifdefs work in the PHP code, it fails to define a "virtual utime" macro and the buld fails with VCWD_UTIME being undefined.

We could work on splitting NetBSD compat between userspace and kernel compat. For this case I would be more inclined to upstream a patch to php though.

[anttikantee]

I would sort of be inclined to do both. However, upstreaming a patch to php is much simpler, so I'd also be inclined to do that first ... assuming I'd be actually doing anything, that is ;)

[ijackson-citrix]

Antti Kantee writes ("Re: [rumprun-xen] AC_CHECK_FUNCS([utime]) fails with rumpapp-xen-configure (#21)"):

I would sort of be inclined to do both. However, upstreaming a patch to php is much simpler, so I'd also be inclined to do that first ... assuming I'd be actually doing anything, that is ;)

I'm not very convinced by patching php as an approach. That way lies fighting every application or library individually. We want rumpkernels to be easy to port to, which means including functions which some people think are obsolete.

Ian.

[anttikantee]

On 22/01/15 18:17, Ian Jackson wrote:

Antti Kantee writes ("Re: [rumprun-xen] AC_CHECK_FUNCS([utime]) fails with rumpapp-xen-configure (#21)"):

I would sort of be inclined to do both. However, upstreaming a patch to php is much simpler, so I'd also be inclined to do that first ... assuming I'd be actually doing anything, that is ;)

I'm not very convinced by patching php as an approach. That way lies fighting every application or library individually. We want rumpkernels to be easy to port to, which means including functions which some people think are obsolete.

Agree. That's why I said "both".

However, digging into the NetBSD tree and justifying changes like this takes a fair amount of time and energy, and I don't have that to spare at least in the coming week.

[mato]

I'm inclined to agreed with @ijackson-citrix on this. While I can submit a patch to PHP, as we know build systems are fragile, who knows where else it'll break, etc etc. There's no hurry to fix this, the way I'm doing things so far with rump-php and other software is just keeping the patches in the related git repository.

[mato]

More examples of the same problem: When trying to build lighttpd, it can't find localtime_r() or gmtime_r(), and the build fails.

[mato]

Confirmed fixed by 8af836e, closing.