Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

error: conflicting types for ‘gettimeofday’ #69

Closed
ghost opened this issue May 6, 2020 · 5 comments · Fixed by #78
Closed

error: conflicting types for ‘gettimeofday’ #69

ghost opened this issue May 6, 2020 · 5 comments · Fixed by #78

Comments

@ghost
Copy link

ghost commented May 6, 2020

Build fails on Arch Linux:

/home/user/build/src/preeny/src/detime.c:24:5: error: conflicting types for ‘gettimeofday’
   24 | int gettimeofday(struct timeval *tv, struct timezone *tz)
      |     ^~~~~~~~~~~~
In file included from /home/user/build/src/preeny/src/detime.c:6:
/usr/include/sys/time.h:66:12: note: previous declaration of ‘gettimeofday’ was here
   66 | extern int gettimeofday (struct timeval *__restrict __tv,
      |            ^~~~~~~~~~~~
make[2]: *** [CMakeFiles/detime.dir/build.make:83: CMakeFiles/detime.dir/src/detime.c.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:688: CMakeFiles/detime.dir/all] Error 2
make: *** [Makefile:104: all] Error 2
==> ERROR: A failure occurred in build().

Thanks in advance!

@zardus
Copy link
Owner

zardus commented May 6, 2020

I don't have arch. Be the change you want to see in the world :-)

@ghost
Copy link
Author

ghost commented May 6, 2020

@zardus what information could I provide to help you? :)

@SjonHortensius
Copy link

this is caused by glibc-2.31

  • The gettimeofday function no longer reports information about a
    system-wide time zone. This 4.2-BSD-era feature has been deprecated for
    many years, as it cannot handle the full complexity of the world's
    timezones, but hitherto we have supported it on a best-effort basis.
    Changes required to support 64-bit time_t on 32-bit architectures have
    made this no longer practical.

    As of this release, callers of gettimeofday with a non-null 'tzp' argument
    should expect to receive a 'struct timezone' whose tz_minuteswest and
    tz_dsttime fields are zero. (For efficiency reasons, this does not always
    happen on a few Linux-based ports. This will be corrected in a future
    release.)

    All callers should supply a null pointer for the 'tzp' argument to
    gettimeofday. For accurate information about the time zone associated
    with the current time, use the localtime function.

    gettimeofday itself is obsolescent according to POSIX. We have no plans
    to remove access to this function, but portable programs should consider
    using clock_gettime instead.

Changing the second parameter of the gettimeofday overload to void *__restrict tzp will fix it for glibc-2.31+

@martinclauss
Copy link

I encountered the same problem with Fedora 32 today!

Best
Martin

@sudhackar
Copy link
Contributor

sudhackar commented May 30, 2020

As pointed out by @SjonHortensius builds can be possible with

diff --git a/src/detime.c b/src/detime.c
index 441b584..5c9a8ce 100644
--- a/src/detime.c
+++ b/src/detime.c
@@ -21,9 +21,9 @@ time_t time(time_t *res)
 }
 
 #ifdef __unix__
-int gettimeofday(struct timeval *tv, struct timezone *tz)
+int gettimeofday(struct timeval *tv, void *__restrict tzp)
 {
-       
+       struct timezone *tz = (struct timezone *) tzp;
        char *sec_str = getenv("TV_SEC");
        char *usec_str = getenv("TV_USEC");
        tv->tv_sec = sec_str ? atoi(sec_str) : 0;

But since now gettimeofday will always zero the struct if tzp is non null, from release/2.31/master

/* Get the current time of day, putting it into *TV.
   If *TZ is not NULL, clear it.
   Returns 0 on success, -1 on errors.  */
int
___gettimeofday (struct timeval *restrict tv, void *restrict tz)
{
  if (__glibc_unlikely (tz != 0))
    memset (tz, 0, sizeof (struct timezone));

  struct timespec ts;
  if (__clock_gettime (CLOCK_REALTIME, &ts))
    return -1;

  TIMESPEC_TO_TIMEVAL (tv, &ts);
  return 0;
}

Should we get preeny to reflect that for newer builds?

acidghost pushed a commit to acidghost/preeny that referenced this issue Jul 14, 2020
acidghost pushed a commit to acidghost/preeny that referenced this issue Jul 14, 2020
acidghost pushed a commit to acidghost/preeny that referenced this issue Jul 14, 2020
acidghost added a commit to acidghost/preeny that referenced this issue Nov 1, 2020
acidghost added a commit to acidghost/preeny that referenced this issue Nov 1, 2020
acidghost added a commit to acidghost/preeny that referenced this issue Dec 3, 2020
@acidghost acidghost mentioned this issue Dec 3, 2020
@zardus zardus closed this as completed in #78 Dec 3, 2020
zardus pushed a commit that referenced this issue Dec 3, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants