Program will not recognize that I have changed a file

[Wes Johnson]

I've encountered a problem where I am changing a particular c source
document and then running the associated make command in the console.
If I then run that program, it is as though the update has been
ignored.
In actuality this change I am making is for the file tcpdump.c for the
program tcpdump.
I am changing a simple print statement that I am sure will be
executed:

Something like
fprintf(stderr, "%d packets received by
filter\n",stat.ps_recv);

** is changed to **

fprintf(stderr, "%d packets received by filter BLAH \n",
stat.ps_recv);

I don't feel that the particular program is the source of my problem.
I have done the basic commands to set it up (./configure, make, make
install) and it is running fine. Concerning my update, I am sure that
tcpdump.c is actually being changed and the giving the make command
again acts as though it recognizes a change of a file, and running
make once again will reply that all the created .o files are up to
date. Does anybody know of what could be keeping my addition of "BLAH"
from being printed? I am not very experienced with c so I figure I
must be overlooking something involving compilation.
.. I am using SuSE linux and the makefile calls the gcc compiler.

 

[Alan Balmer]

I've encountered a problem where I am changing a particular c source
document and then running the associated make command in the console.

This is off topic here, where we discuss the C language. You seem to
have a problem with your makefile. Ask in comp.unix.programmer or in
one of the Linux groups, maybe alt.linux.suse.

 

[jacob navia]

Hi Wes

What is the time of your computer?

If the time is wrong, makefiles will not work.

I had that problem once. Can't tell you if it is the problem
in your case but it is worth checking...

Check the name of the file you are saving also.
Maybe you are saving a different copy than the
copy that the makefile is expecting, in another
directory maybe?

Open a command shell and type make with
a special option to make "make" tell you what is doing.

In the docs of your "make" you will find that kind of
stuff.

Happy debugging

Jacob

 

[Keith Thompson]

Hi Wes

What is the time of your computer?

If the time is wrong, makefiles will not work.

[...]

It's not that simple. Certainly having your system clock set
correctly is a good idea, but an incorrect clock on a standalone
system won't break Makefiles. The reasons are best discussed in a
more relevant newsgroup probably comp.unix.programmer, where they can
tell you about the issues of clock synchronization between NFS clients
and servers, if that happens to be relevant to your problem.

 

[jacob navia]

Hi Wes

What is the time of your computer?

If the time is wrong, makefiles will not work.

[...]

It's not that simple. Certainly having your system clock set
correctly is a good idea, but an incorrect clock on a standalone
system won't break Makefiles.

Try this Keith:
1) Recompile some package. All objects will have date of 2 July.
2) Set the date to July 1st
3) Go to the same package and modify a file.

The file will never be recompiled since its object file
will have 2 July as date, and the source 1 July.

Some good make utilities warn about "The date
of xxx is in the future".

 

[Mark McIntyre]

Try this Keith:
1) Recompile some package. All objects will have date of 2 July.
2) Set the date to July 1st
3) Go to the same package and modify a file.

Jacob, thats different to what you said. It may be what you meant but its
not what you said.

You said "if the time is wrong, makefiles will not work". This is different
to "if the time changes to be in the past, makefiles will not work".

Keith is correct. On a standalone system the timestamp is largely
irrelevant unless you have a badly broken system clock. OTOH if the source
is stored server-side then clock discrepancies between the server and local
machine can definitely cause the effect you're discussing.

 

[jacob navia]

Keith is correct. On a standalone system the timestamp is largely

irrelevant unless you have a badly broken system clock. OTOH if the source
is stored server-side then clock discrepancies between the server and local
machine can definitely cause the effect you're discussing.

Or, your motherboard crashed. That happened to me last week (my
amd64 MSI K8T crashed, and I had to buy a new motherboard). When
I installed it, started to work again and my makefiles would not work.

It was a while till I got to the clock. Maybe because it was fresh
in my mind, I started with that possibility.

True, if the clock goes up regularly this will not happen. But it
*may* happen, and is an easy verification to do in all systems.

When debugging, an easy verification can save a lot of time if
positive, and doesn't cost a lot when negative.

 

[Keith Thompson]

Hi Wes

What is the time of your computer?

If the time is wrong, makefiles will not work.

[...]

It's not that simple. Certainly having your system clock set
correctly is a good idea, but an incorrect clock on a standalone
system won't break Makefiles.

Try this Keith:

[snip]

I stand by my previous statement.

But the real point, which you snipped, is that this discussion is
off-topic. It's not about C, it's about "make". I'll be happy to
discuss the interaction between "make" and the system clock in an
appropriate newsgroup, but not here in comp.lang.c.

 

[Eric]

I've encountered a problem where I am changing a particular c source
document and then running the associated make command in the console.
If I then run that program, it is as though the update has been
ignored.
In actuality this change I am making is for the file tcpdump.c for the
program tcpdump.
I am changing a simple print statement that I am sure will be
executed:

Something like
fprintf(stderr, "%d packets received by
filter\n",stat.ps_recv);

** is changed to **

fprintf(stderr, "%d packets received by filter BLAH \n",
stat.ps_recv);

I don't feel that the particular program is the source of my problem.
I have done the basic commands to set it up (./configure, make, make
install) and it is running fine. Concerning my update, I am sure that
tcpdump.c is actually being changed and the giving the make command
again acts as though it recognizes a change of a file, and running
make once again will reply that all the created .o files are up to
date. Does anybody know of what could be keeping my addition of "BLAH"
from being printed? I am not very experienced with c so I figure I
must be overlooking something involving compilation.
. I am using SuSE linux and the makefile calls the gcc compiler.

Are you sure you are executing the changed file? ie: ./mynewfile
Under Linux the path is searched before the current dir is so if
mynewfile is also in /usr/local/bin (which is usually on your path)
and you compile a new version of mynewfile in /home/yourName/Code
and then whilst sitting in /home/yourName/Code you type: mynewfile
the one in /usr/local/bin will execute instead of the one your staring
at. Of course I am assuming you havnt modified the default path to
something like PATH=.:$PATH, and I also am assuming you are running
Linux, I could be totaly wrong on both assumptions.
Eric

 

[Dan Pop]

Hi Wes

What is the time of your computer?

If the time is wrong, makefiles will not work.

[...]

It's not that simple. Certainly having your system clock set
correctly is a good idea, but an incorrect clock on a standalone
system won't break Makefiles.

It *may*, when importing a set of sources from another system, if the
original timestamps are preserved.

Dan

 

[Gordon Burditt]

It's not that simple. Certainly having your system clock set

correctly is a good idea, but an incorrect clock on a standalone
system won't break Makefiles.

A clock on a standalone system that goes backwards (say, during a
reboot or being manually set) CAN break Makefiles. I've had it
happen. This was an old system with no network or shared filesystems
whatever, and none of the relevant files were imported on floppies.

Gordon L. Burditt