MSVC do not like the gmtime_r

[nickoe]

Build fails on MSVC because of gmtime_r.

error C3861: 'gmtime_r': identifier not found

Maybe https://msdn.microsoft.com/en-us/library/3stkd9be.aspx is relevant to deduce a fix.

[GyrosGeier]

struct tm *gmtime_r(time_t const *timep, struct tm *tmp)
{
    if(gmtime_s(tmp, timep) == 0)
        return tmp;
    return 0;
}

[cbernardo]

Yes, I will push some changes for that:

ifdef _MSC_VER

define gmtime_r( ARG1, ARG2 ) do{ ARG2 = gmtime( ARG1 ); }while(0)

endif

I'm not 100% sure _MSC_VER is always defined though so I'll need to check. I'm having trouble linking to BOOST and I can't understand why; I get a message like "cannot open file libboostXXXX.lib" but all the files referred to are "boostXXXX.lib"; I even had this trouble when I created a project file for libIGES using MSVC itself. I suspect once I learn what I'm doing wrong with BOOST I should be able to build everything via CMake. Well, I also have to sort out problems creating "SISL" as a submodule project; I can build SISL first and that's OK, but I can't get it to build + link if I attempt to build it as a submodule.

[nickoe]

Maybe it is better to #ifdef WIN32. I just tried to cross compile with gcc and I get the same error, and _MSC_VER is not defined here.

For the SISL matter, yes I have had some trouble at times also. But removing the sisl directory and doing the init and update again makes it work again, untill I remove the build dir I was previously working on... or something like that at least.

[nickoe]

By the way, I also get the link error with boost (with MSVC). I think it is a bug somewhere, but I am not really knowledgeable in that field. But I have noticed that for posix systems libraies are usually lib<componentname>.{a,so} and just <componentname>.{lib,dll} on windows.

[nickoe]

This might be helpfull to the boost linking issue, but this is sort of getting off topic of this gmtime_r issue... http://stackoverflow.com/questions/4736877/how-to-link-boost-in-a-dependant-static-library

[nickoe]

It do indeed seem like adding the definition BOOST_ALL_NO_LIB works. I think this is MSVC only, but I am not really sure. I did not need it for cross compiling with gcc to windows, but I think it is fine to add unconditionally in case other compilers that support the lib pragmas now and in the future is present.

[cbernardo]

With boost I gave up and built the entire set with 'b2' and had no problem. Of course I could have passed the wrong

compiler flag initially or used a default instead of passing the correct flag, but the resulting files had exactly the same name and yet I can link to one but not the other.

---

From: nickoe notifications@github.com To: cbernardo/libIGES libIGES@noreply.github.com Cc: cbernardo cirilo_bernardo@yahoo.com Sent: Monday, June 8, 2015 12:15 AM Subject: Re: [libIGES] MSVC do not like the gmtime_r (#10)

By the way, I also get the link error with boost. I think it is a bug somewhere, but I am not really knowledgeable in that field. But I have noticed that for posix systems libraies are usually lib.{a,so} and just .{lib,dll} on windows. — Reply to this email directly or view it on GitHub.

[cbernardo]

Thanks Gyros, I'll use your solution; I just realized my initial proposal could segfault.

[cbernardo]

I may change this back to "#ifdef _MSC_VER"; when using MingW/gcc I get an error saying that gmtime_r is being redefined. I think the "right way" to do this is to do a test compile during configuration time and to decide on the best action then, but if I can get away with using precompiler directives instead I'll do that. Any comments on that?

For the boost build, I can now get the build system to do what I want and I have made notes on how to build it all. I can build with MSVC as well as MinGW/gcc and most things seems to work. I changed the linking to libIGES from dynamic to static and I don't understand yet why the iostream output commands from the DLL don't print (this is the case for both MSVC and gcc).

[nickoe]

Ok, good to know. But I guess we would still like to support cross compilation. Maybe we can make cmake define something if it can detect if cross compiling to windows or using MSVC.

[GyrosGeier]

FWIW, I also built Boost with b2, because that is what I'm supposed to use. Works fine with MSVC.

[GyrosGeier]

Cross-Compiling to Windows is the _WIN32 macro -- this is set on both mingw and MSVC, but not on CygWin. _MSC_VER is MSVC only.

[cbernardo]

I haven't heard more about this problem so I'm assuming the previous fix is OK on all tested platforms and I'm closing this one.