Jim Henderson wrote:
> That's not what I read in your post.  I duplicated with the code staying 
> the same, but not with it changing.

I take advantage of X windows, ya see. :-)

I find it really hard to believe GCC will compile a program, then read the 
output file to see if the result is the same, and if not, only then will 
unlink the old code and write the new code.

I'll give it a try next time I'm in Linux, tho.  I suspect it's more some 
options on the compiler or file system we have set differently or something.

-- 
   Darren New, San Diego CA, USA (PST)
   The NFL should go international. I'd pay to
   see the Detroit Lions vs the Roman Catholics.

Post a reply to this message

Darren New wrote:
> 
> I find it really hard to believe GCC will compile a program, then read
> the output file to see if the result is the same, and if not, only then
> will unlink the old code and write the new code.
> 

OTOH it could check mtime of the source and the binary and choose the
way to work. But somehow I even that hard to believe.

-Aero

Post a reply to this message

Eero Ahonen wrote:
> OTOH it could check mtime of the source and the binary and choose the
> way to work. But somehow I even that hard to believe.

Except it would have to pretty much compile everything anyway, since 
environment variables, command line options, and include files can all 
affect the results too. And anyway, I changed the file between runs.

-- 
   Darren New, San Diego CA, USA (PST)
   The NFL should go international. I'd pay to
   see the Detroit Lions vs the Roman Catholics.

Post a reply to this message

On Mon, 01 Dec 2008 10:55:03 -0800, Darren New wrote:

> Jim Henderson wrote:
>> That's not what I read in your post.  I duplicated with the code
>> staying the same, but not with it changing.
> 
> I take advantage of X windows, ya see. :-)
> 
> I find it really hard to believe GCC will compile a program, then read
> the output file to see if the result is the same, and if not, only then
> will unlink the old code and write the new code.

It probably looks to see if the source file changed since the last 
compilation (not sure how it tracks that).  All I know is that when I 
didn't change the code, the inode stayed the same, and when I did, it 
didn't.

> I'll give it a try next time I'm in Linux, tho.  I suspect it's more
> some options on the compiler or file system we have set differently or
> something.

Could be.

Jim

Post a reply to this message

Jim Henderson wrote:
> It probably looks to see if the source file changed since the last 
> compilation (not sure how it tracks that).

I find it hard to believe that GCC would be that broken.

-- 
   Darren New, San Diego CA, USA (PST)
   The NFL should go international. I'd pay to
   see the Detroit Lions vs the Roman Catholics.

Post a reply to this message

On Mon, 01 Dec 2008 18:57:12 -0800, Darren New wrote:

> Jim Henderson wrote:
>> It probably looks to see if the source file changed since the last
>> compilation (not sure how it tracks that).
> 
> I find it hard to believe that GCC would be that broken.

<shrug>  I'm just goin' by my observation.....if you've got a better 
explanation, I'm all ears.

Or maybe that's "eyes". ;-)

Jim

Post a reply to this message

Jim Henderson wrote:
> <shrug>  I'm just goin' by my observation.....if you've got a better 
> explanation, I'm all ears.

Dunno. Like I said, it may be the compiler version or something. Now, if 
you're talking Java, I could understand this, because the Java equivalent of 
#include looks at .class files to see if something needs to be recompiled. 
I.e., "make" is sort of built in to Java compilers.

darren@dog:~/test> gcc -v
Using built-in specs.
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --with-local-prefix=/usr/local 
--infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 
--libexecdir=/usr/lib64 
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada 
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.3 
--enable-ssp --disable-libssp --with-bugurl=http://bugs.opensuse.org/ 
--with-pkgversion='SUSE Linux' --disable-libgcj --with-slibdir=/lib64 
--with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new 
--disable-libstdcxx-pch --program-suffix=-4.3 
--enable-version-specific-runtime-libs --enable-linux-futex 
--without-system-libunwind --with-cpu=generic --build=x86_64-suse-linux
Thread model: posix
gcc version 4.3.1 20080507 (prerelease) [gcc-4_3-branch revision 135036] 
(SUSE Linux)
darren@dog:~/test> ls -l
total 28
-rw-r--r-- 1 darren users 67 2008-12-02 10:25 a.c
-rw-r--r-- 1 darren users 67 2008-12-02 10:26 b.c
-rw-r--r-- 1 darren users 22 2008-12-02 11:07 c.c
-rw-r--r-- 1 darren users 22 2008-12-02 10:25 d.c
darren@dog:~/test> cat a.c
#include "c.c"
int main() { write(1, "Hello " XYZ, 12); return 0;}
darren@dog:~/test> cat b.c
#include "c.c"
int main() { write(1, "Zing! " XYZ, 12); return 0;}
darren@dog:~/test> cat c.c
#define XYZ "World\n"
darren@dog:~/test> cat d.c
#define XYZ "xyzzy\n"
darren@dog:~/test> gcc a.c ; ls -li a.out ; ./a.out
1818787 -rwxr-xr-x 1 darren users 11120 2008-12-02 11:07 a.out
Hello World
darren@dog:~/test> gcc b.c ; ls -li a.out ; ./a.out
1818787 -rwxr-xr-x 1 darren users 11120 2008-12-02 11:07 a.out
Zing! World
darren@dog:~/test> cat d.c >c.c
darren@dog:~/test> gcc a.c ; ls -li a.out ; ./a.out
1818787 -rwxr-xr-x 1 darren users 11120 2008-12-02 11:08 a.out
Hello xyzzy
darren@dog:~/test> gcc b.c ; ls -li a.out ; ./a.out
1818787 -rwxr-xr-x 1 darren users 11120 2008-12-02 11:08 a.out
Zing! xyzzy
darren@dog:~/test> cat a.c >b.c
darren@dog:~/test> gcc b.c ; ls -li a.out ; ./a.out
1818787 -rwxr-xr-x 1 darren users 11120 2008-12-02 11:08 a.out
Hello xyzzy
darren@dog:~/test>

Nothing I did changed the inode number of a.out, in spite of getting 
different output every time I ran it.

-- 
   Darren New, San Diego CA, USA (PST)
   The NFL should go international. I'd pay to
   see the Detroit Lions vs the Roman Catholics.

Post a reply to this message

On Tue, 02 Dec 2008 11:30:48 -0800, Darren New wrote:

> Jim Henderson wrote:
>> <shrug>  I'm just goin' by my observation.....if you've got a better
>> explanation, I'm all ears.
> 
> Dunno. Like I said, it may be the compiler version or something. Now, if
> you're talking Java, I could understand this, because the Java
> equivalent of #include looks at .class files to see if something needs
> to be recompiled. I.e., "make" is sort of built in to Java compilers.

Might be.  What filesystem are you using?  Maybe it's a question of the 
inode allocation system, number of free inodes and the like?

Jim

Post a reply to this message

Jim Henderson wrote:
> Might be.  What filesystem are you using?  Maybe it's a question of the 
> inode allocation system, number of free inodes and the like?

ext3. I don't think that's it. If I delete the a.out and run gcc again, I 
get a different inode number.

-- 
   Darren New, San Diego CA, USA (PST)
   The NFL should go international. I'd pay to
   see the Detroit Lions vs the Roman Catholics.

Post a reply to this message

On Tue, 02 Dec 2008 12:17:52 -0800, Darren New wrote:

> Jim Henderson wrote:
>> Might be.  What filesystem are you using?  Maybe it's a question of the
>> inode allocation system, number of free inodes and the like?
> 
> ext3. I don't think that's it. If I delete the a.out and run gcc again,
> I get a different inode number.

Interesting; I also am running ext3 here....

Jim

Post a reply to this message