Build issue Win7 (x64) #39

Closed
Jickelsen opened this Issue Dec 14, 2012 · 20 comments

Projects

None yet

5 participants

@Jickelsen

I've run across at least two Windows-specific issues while trying to build.

http://pastebin.com/hE02FWaf

The first one seems to be related to issues with compilers supplied by MinGW. I've tried both the official version and nuwen's distro http://nuwen.net/mingw.html#install. In the end I just commented the line

 snprintf(result, size, "%02hhx:%02hhx:%02hhx:%02hhx:%02hhx:%02hhx",
             addr[5], addr[4], addr[3], addr[2], addr[1], addr[0]);

and it worked.

I don't know about the second issue, other than it might be related to the closed issue #37 . Any help would be greatly appreciated!

@thp
Owner
thp commented Dec 14, 2012

DId you try to build with mingw-w64 also? It works for me (although I'm cross-compiling for Windows on Linux): http://mingw-w64.sourceforge.net/

@Jickelsen

I tried using both the 32- and 64 bit versions of rubenvb's personal builds of mingw-w64 for gcc 4.7 (http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/rubenvb/),

Sadly the first error appears again and I get a variant of the second one.
http://pastebin.com/zFgPeM0j

Edit: Also tried the gcc 4.5 version, same result.

@thp
Owner
thp commented Dec 17, 2012

In that case, maybe you could try commenting out the block in src/psmove.c that defines the clock_gettime function, as well as (maybe) the #define CLOCK_MONOTONIC 0.

@ghost
ghost commented Jan 20, 2013

Has a build solution for this been found yet? Commenting out the parts specified in the error doesn't seem to make things better. I might just boot into linux and cross compile instead of all this hassle.

@thp
Owner
thp commented Jan 20, 2013

If you build it with mingw-w64 instead of mingw32, it should cleanly compile on Windows.

@thp
Owner
thp commented Feb 14, 2013

Did building with mingw-w64 fix this issue?

@Jickelsen

I had a go at it but ran into the same issue. I haven't had time to poke at it more since then, sadly. We're using a different solution right now but in the long run it would be good to get this to work, so I might attempt it again later.

@thp
Owner
thp commented Apr 25, 2013

mfsr, Jickelsen: Any news about this? Have you got it working now? If not, any patch that fixes the problem? A detailed build log using mingw-w64's compiler would be very helpful in tracking down, fixing and finally closing this issue. Thanks :)

@Jickelsen

I'm afraid to say I haven't had time to tackle the problem. The laptop I had set up for building on had a hardware failure and is in for repairs for another week. However once I get it back I can provide a build log.

@Jickelsen

Ok, let's fix this issue. I set up the build system again but I only seem to have mingw32-make in mingw64. At any rate, here is the build log. Tell me if I can provide any more information.

http://pastebin.com/T12Tu5gh

I have no idea why it's referencing my past MinGW64 installation (line 49). I hope this isn't screwing up the build.

@ChairGraveyard

I ran into this issue while trying to build a 64bit windows vers of the API.

Commenting the clock_gettime function didn't work, as the linker ended up failing later (for some reason, despite seeing the declaration in pthread_time.h, it doesn't use it).

So I changed the name of clock_gettime defined in psmove.c to be __clock_gettime (I know, lame right) and switched the call to use that one. It works!

@betonme
betonme commented Jul 9, 2014

Just remove the static declaration and it should link fine.

Tested with Win8.1 x64
mingw32-i686-4.8.3-release-win32-sjlj-rt_v3-rev0
cmake-2.8.12.2-win32-x86

@ChairGraveyard

@betonme, that didn't work for me on Win 7 64bit (mingw-w64). It ends up failing at the linker stage, saying it can't find clock_gettime.

Unless you mean to just change it to not be static in the declaration (not sure based on phrasing)?

@betonme
betonme commented Jul 10, 2014

Yes, just remove the keyword static not the whole function.

@ChairGraveyard

Ah cool, thanks :)

@thp
Owner
thp commented Jul 19, 2014

@ChairGraveyard Do you have a patch that we could apply that would fix this for all users (ifdeffed to WIN32 or something so it only applies to Windows builds)?

@ChairGraveyard

I don't have a patch handy but I could whip one up.

The only difference would be the static declaration for Win, so in psmove.c change the clock_gettime declaration to

#if defined(__APPLE__) 

#define CLOCK_MONOTONIC 0

static int
clock_gettime(int unused, struct timespec *ts)
{
    struct timeval tv;
    gettimeofday(&tv, NULL);

    ts->tv_sec = tv.tv_sec;
    ts->tv_nsec = tv.tv_usec * 1000;

    return 0;
}
#endif /* __APPLE__ */

#ifdef _WIN32

#define CLOCK_MONOTONIC 0

int
clock_gettime(int unused, struct timespec *ts)
{
    struct timeval tv;
    gettimeofday(&tv, NULL);

    ts->tv_sec = tv.tv_sec;
    ts->tv_nsec = tv.tv_usec * 1000;

    return 0;
}

#endif // WIN32

Basically just ifdef-ing out the static part of "static int clock_gettime"

@nitsch
Contributor
nitsch commented Sep 13, 2014

Do we need the Windows branch at all? I set up a 32-bit Windows test machine with mingw-w64 version 4.9.1. The (re-)definition of clock_gettime() is not necessary here since that function is known already.

This means we can simply remove the WIN32 case from

#if defined(__APPLE__) || defined(_WIN32)

Could you guys please verify this on your setups?

@ChairGraveyard

@nitsch - I seem to recall (and may be wrong) that I tried that out too, but it led to errors compiling later on for some reason or other, so I went with the define method.

@nitsch nitsch referenced this issue in betonme/psmoveapi Sep 26, 2014
@betonme betonme Removed static declaration of clock_gettime because of linker error
Tested with Win8.1 x64
mingw32-i686-4.8.3-release-win32-sjlj-rt_v3-rev0
cmake-2.8.12.2-win32-x86
3823590
@thp
Owner
thp commented Mar 24, 2015

Fixed.

@thp thp closed this Mar 24, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment