WIndows Project Moved to Linux = Errors

[arew264]

Okay, so I'm working on a project that's eventually gonna be run on linux, but I started it out on windows and compiled with Cygwin.
Then when I got sick of debugging with cygwin (debugging with cygwin is basically recompiling your code with diagnostic messages), and set up a SVN repo, stored all my code (the whole project folder, etc), fired up codeblocks on linux, checked out the repo, and opened the project file.
It opens all my files just fine, and I can edit them, etc, but after I changed the compiler from cygwin to GCC, I told it to rebuild and got this as a log:

Code Select Expand

-------------- Build: Debug in NewMud ---------------
WARNING: Can't read file's timestamp: /home/arew264/Desktop/newmud/admin.cpp
WARNING: Can't read file's timestamp: /home/arew264/Desktop/newmud/area.cpp
WARNING: Can't read file's timestamp: /home/arew264/Desktop/newmud/build.cpp
WARNING: Can't read file's timestamp: /home/arew264/Desktop/newmud/commands.cpp
WARNING: Can't read file's timestamp: /home/arew264/Desktop/newmud/commandutils.cpp
WARNING: Can't read file's timestamp: /home/arew264/Desktop/newmud/comms.cpp
WARNING: Can't read file's timestamp: /home/arew264/Desktop/newmud/editor.cpp
WARNING: Can't read file's timestamp: /home/arew264/Desktop/newmud/fight.cpp
WARNING: Can't read file's timestamp: /home/arew264/Desktop/newmud/globals.cpp
WARNING: Can't read file's timestamp: /home/arew264/Desktop/newmud/handlers.cpp
WARNING: Can't read file's timestamp: /home/arew264/Desktop/newmud/load.cpp
WARNING: Can't read file's timestamp: /home/arew264/Desktop/newmud/mob.cpp
WARNING: Can't read file's timestamp: /home/arew264/Desktop/newmud/objects.cpp
WARNING: Can't read file's timestamp: /home/arew264/Desktop/newmud/player.cpp
WARNING: Can't read file's timestamp: /home/arew264/Desktop/newmud/room.cpp
WARNING: Can't read file's timestamp: /home/arew264/Desktop/newmud/states.cpp
WARNING: Can't read file's timestamp: /home/arew264/Desktop/newmud/strings.cpp
WARNING: Can't read file's timestamp: /home/arew264/Desktop/newmud/timer.cpp
WARNING: Can't read file's timestamp: /home/arew264/Desktop/newmud/tinymudserver.cpp
Linking console executable: bin/Debug/NewMud
g++: obj/Debug/admin.o: No such file or directory
g++: obj/Debug/area.o: No such file or directory
g++: obj/Debug/build.o: No such file or directory
g++: obj/Debug/commands.o: No such file or directory
g++: obj/Debug/commandutils.o: No such file or directory
g++: obj/Debug/comms.o: No such file or directory
g++: obj/Debug/editor.o: No such file or directory
g++: obj/Debug/fight.o: No such file or directory
g++: obj/Debug/globals.o: No such file or directory
g++: obj/Debug/handlers.o: No such file or directory
g++: obj/Debug/load.o: No such file or directory
g++: obj/Debug/mob.o: No such file or directory
g++: obj/Debug/objects.o: No such file or directory
g++: obj/Debug/player.o: No such file or directory
g++: obj/Debug/room.o: No such file or directory
g++: obj/Debug/states.o: No such file or directory
g++: obj/Debug/strings.o: No such file or directory
g++: obj/Debug/timer.o: No such file or directory
g++: obj/Debug/tinymudserver.o: No such file or directory
g++: no input files
Process terminated with status 1 (0 minutes, 0 seconds)
0 errors, 0 warnings

Do I need to write my own makefile for linux, or should it all work like it did on Windows? Did I miss something?

[TDragon]

I'd bet that you've just encountered the nasty GCC bug I've spent the past couple of weeks hunting. See if both of the following are true:
- You're using GCC 4.2 or later
- At least a portion of C::B (the Compiler depslib) is compiled with "-O2" (or a particular optimization that -O2 enables)

If so, you've run afoul of an optimization bug that occurs in the time_enter function in timestamp.c. The fix, for now, is to get that file compiled either without "-O2" or with "-fno-strict-aliasing"; I choose the latter, and for me, since I build C::B with C::B, it's a simple matter of adding "-fno-strict-aliasing" to the Compiler depslib target before building. If you're using the autotools (bootstrap, configure, make) process, I'm not sure how best to get it fixed but you can probably just recompile that single file by hand and then redo the "make" and "make install" steps.

This bug is filed in GCC Bugzilla as Bug #32328, in case you're interested.

Hope that helps,
John E. / TDM

[arew264]

Thanks, there is a good chance this is the case.
I use Arch Linux, a medium sized distro that's major forte is having the latest stable version of ALL major packages. C::B is in the official user repo, and I'll have to check if they used that flag and if to advise them about it.

[Morphius Faydal]

Check in the makefile that comes down with the SVN source of Code::Blocks, and you can edit the target for the compiler.

Also, running touch on all the files should modify the timestamp, so you could, hopefully, work around this GCC bug.

[TDragon]

Also, running touch on all the files should modify the timestamp, so you could, hopefully, work around this GCC bug.

Actually, the bug is in the fact that GCC produces incorrect output when compiling C::B -- the error occurs when C::B itself tries to read a file's timestamp and, because of the incorrect output, fails. Because it can't read the timestamp, it assumes the file doesn't exist and skips compiling it -- then errors out because it can't find the compiled object file.

[Morphius Faydal]

Also, running touch on all the files should modify the timestamp, so you could, hopefully, work around this GCC bug.

Actually, the bug is in the fact that GCC produces incorrect output when compiling C::B -- the error occurs when C::B itself tries to read a file's timestamp and, because of the incorrect output, fails. Because it can't read the timestamp, it assumes the file doesn't exist and skips compiling it -- then errors out because it can't find the compiled object file.

Ah...  I've never encountered said bug, and I guess I didn't read the bug report right.  My apologies.

[arew264]

Okay, that does appear to be the problem, and I am recompiling, which takes somewhere near 15 minutes, even on my awesome 3GHz Pentium 4 with hyperthreading, a gig of ram, and pure awesome (except the ECS mobo - NEVER going to TOUCH one of those again)

[arew264]

Well, I set that -fno-strict-aliasing flag, recompiled, and w00t, my project is running under linux. Thank you!

[TDragon]

You're welcome!

A note to the C::B devs:
The compiler depslib hash table functionality is not a pretty piece of work. I'm not sure how standards-conformant it is to pun a pointer between two types of structs with different members, but my guess is "not very". Even if nothing else, it's breaking strict-aliasing rules, so in my (not so) professional opinion, it should be rewritten or the compiler depslib replaced.

A note to the world in general:
My 500th post, heh.

[Morphius Faydal]

You're welcome!

A note to the C::B devs:
The compiler depslib hash table functionality is not a pretty piece of work. I'm not sure how standards-conformant it is to pun a pointer between two types of structs with different members, but my guess is "not very". Even if nothing else, it's breaking strict-aliasing rules, so in my (not so) professional opinion, it should be rewritten or the compiler depslib replaced.

A note to the world in general:
My 500th post, heh.

How hard would it be to recode the relevant sections to be more standards compliant?

And wow.  You've been around a lot. :-P

[TDragon]

How hard would it be to recode the relevant sections to be more standards compliant?

I'm not sure. It depends on whether the hash table is really only used to store only a single type of data (BINDING*), or is used to store more than one type like it's designed for. If the former, the job would probably be relatively easy; if the latter, it would be more difficult.

[Morphius Faydal]

How would one go about finding out whether it stores only a single data type or multiple?

[TDragon]

How would one go about finding out whether it stores only a single data type or multiple?

One would familiarize oneself with the source... :?