C/C++: compilation question

[IHateMyJob2004]

I was shocked recently. This is really dailywtf.com type stuff. But before I assume my disillusions are correct I will ask.

Let's say that you were using a gnu compiler to compile some code. You code compiles and links but the executable (actually a .out file for the vxWorks OS) that was created many years ago differs from the executable that is now being created. It has a different filesize (and checksum). Someone at another company that wrote this code is arguing that it could be something as simple as a file (assuming he meant source file) being in a different directory. My head imploded.

So, I have to ask, is it actually possible that a different file size and checksum could result from a different directory structure?

I guess I will have to look for debug flags. The kicker however is that to our knowledge the directory structure is identical from the C drive up. The files were not haphazardly located on the C drive without reason. We are using the supplied build procedure.

 

[Cogman]

Is it the same gcc version? If so, then that will most likely be the reason for different file sizes.

You could get a different checksum if somehow the file names change, so for example, a.cpp and b.cpp swap names. The order will change causing some checksum differences.

Other differences could enter when new libraries are introduced ect (A static library update will change a lot of things)

A directory change could change things, however, I wouldn't think that it would change file sizes.

 

[Nothinman]

I'm not expert but I wouldn't think that it would unless the filenames were included in the debugging information. Assuming everything else (i.e. compiler and linker flags, gcc version, etc) is exactly the same.

 

[Cogman]

Originally posted by: Nothinman
I'm not expert but I wouldn't think that it would unless the filenames were included in the debugging information. Assuming everything else (i.e. compiler and linker flags, gcc version, etc) is exactly the same.

Well, it can be in different orders. For example, if someFunc(blah) was declared in a.cpp and someOtherFunc(blah) was declared in b.cpp, but those two functions are only used in c.cpp, then the order that someFunc and someOtherFunc are defined will be the order that the files are compiled and linked together. Functions aren't placed in the compiled file in alphabetical order.

 

[Markbnj]

I would be hugely surprised if the file location affected its size or checksum at all. I would not be at all surprised that compiling the same code under different versions of a compiler does change both the size and checksum. Rather, I'd be surprised if it didn't.

 

[IHateMyJob2004]

Ahhh, some things I should add.

We have an exact duplicate of the original developers COMPILER/LINKER. same exact version. It is literally a copy of what they had.

The source code is also in the exact same story. It is a copy of their working folders.

What happened is that they delivered an executable (.out file) that is currently in use with the target hardware. This is the same executable that came with the source code. The executable checksums match. We are certain that the executable in use is the exact same thing as the executable that came with the source code.

Now, when we take the source and build the executable, we get a different executable than what is in use. If we do this same thing with an older version of the source code and corresponding older executable we get matching executable checksums.

To us, it is obvious. The source code that is available does not correlate to the latest executable used in the real world for the past 2 years which is rock solid. We need to update the source code with additional functionality but we don't have the latest source code. BIG PROBLEM if we can not replicate. And this is when the other companies lead developer says that it could just be a directory that is messed up I cringe and think to myself "You have got to be $#$W%ing kidding me".

Anyways, I do agree that debug info could be different if a directory changed. I appreciate the comments and will be going over them again.

Some things:
1) It can't be linking order since the file sizes differ.
2) Debug info may have changed if directory structure is different

Today I tinkered with optimization levels. no luck but figured it was worth the 30 minute exercise.

 

[hans007]

well the simplest explanation is someone copied the wrong version of the source code as the binary they shipped.

i've worked at places where people "forgot" to check into source control the binary that is in production. hell i worked at a place where some production daemon was running on a computer at a guys desk and when he quit all hell broke loose.

 

[DaveSimmons]

Any external libraries not included in the source code snapshot or the compiler snapshot, like a graphics or OS library?

Are you sure you're using the exact same makefile with the same flags?

A debug build would include file names for trace and error statements but I'd -guess- not folders. But you might try making the folder paths match his if that's possible.

 

[IHateMyJob2004]

Originally posted by: DaveSimmons
Any external libraries not included in the source code snapshot or the compiler snapshot, like a graphics or OS library?

We have a duplicate of the original developers environment. They actually provided this once we got all the legal issues resolved. Sadly, I think they mucked up their installation of the IDE (Tornado in this case) so the only fix was to get a copy of what they have.

Are you sure you're using the exact same makefile with the same flags?

According to them, yes. I agree. The company that originally developed it said they couldn't replicate on their end either. I hope I mentioned that. When I say original developers, I mean original developers at another company.

A debug build would include file names for trace and error statements but I'd -guess- not folders. But you might try making the folder paths match his if that's possible.

There are 4 makefiles total. Once of them has a debug compiler option. I tried removing it and it did nothing other than make the file bigger. I tried using all the compiler optimization levels to no avail.

Also, what we compile is slightly larger than the executable that was provided. I found no compile flags that made what we are building smaller.

 

[degibson]

Take the two binaries and run them both through nm. Apply sed's, sort's, and diff's as necessary to see if there are any ABI or static placement differences.