-
Notifications
You must be signed in to change notification settings - Fork 5
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
Datafile.hh: " error: cannot convert 'long int*' to 'time_t*' " #14
Comments
I'm sorry, but I don't know anything about Windows anymore. I had a machine with that OS for a year or two, back in the 1990s, I think. If gri builds on such machines, it's because of careful coding to the standards of the time, more than testing with an everyday-use machine. If you state the filename and line number, I can likely make some guesses as to the fix. This looks like it might have been a remnant, because I thought I was using It's possible someone on this thread uses windows. I lack access to such machines. I am on macos now, and don't even have a real gcc, since that uses llvm (10.0.0). |
Dan, I'm as well getting back to Windows and just struck that the last gri binary for this platform is 14 years old port available at GNUwin32 utils. . . Although until last bit has been unbent and last byte polished no final word can be said on the exact reason for the problem, I surmise is not platform dependent but an issue related to the augmented strictness of the compilers we're are developing with. Historically is was supposed the programmer (at least in C prog lang) knew was doing and the matters related to loosing precision due casting were at most "code smells" or "advanced warnings". Nowadays, all compiler writers want to protect us from liberties and more than once I've stumbled with old code that recompiled seems to have fired the NYC Fire Departmente during the Orson Wells radio broadcast...! So, IMNHO before worrying too mucha about Windows, I would get my attention to the current version of gcc (GNU Compiler Collection, as Gri uses C++ as well). These are the first lines of config.log:
------------------------------------------------------------------------------------------>8--------------------
If we run
OTOH I know that I don't mind into delving in the issue but would like not to expend time in redundant way if other developers already found this and most importantly the solution to the problem. Best Regards,Cesar Rabak |
Using gcc (Rev1, Built by MSYS2 project) 8.2.1 20181207 in a MSYS2 environment I get an error which I could circumvent using an '-fpermissive' compile flag for C++, but this one g++ claims is an error.
What was the latest gcc which gri 2.12.23 built sucessfully in a Windows platform?
The text was updated successfully, but these errors were encountered: