I had a working set up consisting of a main program (F77) that calls a bunch of subroutines in a library. Suddenly, it appears that the library is not rebuilding - changes to the main program are implemented but those to a subroutine,“reader” in folder “util”, do not. The library builds without any errors and a new library archive is created via the following makefile (rewritten for easier reading):
FOR=ifort -c -O3
(ditto many other subroutines)
rm -f *.o *~ core
(ditto manyother subroutines)
ar -rv $(MY_DIR)/libmy.a *.o
Then the main program (and others) are compiled with another makefile. Again, there are no errors and a new executable is created.
FOR=ifort -c -O3
$(FOR) $(OPT) $<
$(CC) $(OPT) $<
$(LINK) -o my_main my_main.o $(LIBMY)
(ditto many other subroutines)
These makefiles used to work and have never changed, the only thing that has changed is the subroutine “reader”.
How can this be fixed?
What happened depends on the commands that you used to rebuild the library and the executable. Do you really need to use makefiles for a project with a few source files?
The default target in the first makefile is "clean", so just typing "make" will not rebuild the library. Similarly, in the second makefile the target my_main is not listed as being dependent on the library libmy.a
1. Not a few source files, over 200 of them.
2. I type "make mylib", which builds it.
3. $(LINK) -o my_main my_main.o $(LIBMY) shows it being dependent on the library libmy.a. Is there another way to do this?
To simplify the question hugely, why does
ifort -c -O3 ~/mydir/reader.f
ar -rv ~/mydir/libmy.a reader.o
not add "reader" to the library, when it added all the other subroutines in the library?
franco@franco-VirtualBox:~/swifthjs$ make libswift
cp libswift.a libswift.a~
ifort -c -O3 /home/franco/swifthjs/anal/*.f
ifort -c -O3 /home/franco/swifthjs/bs/*.f
ifort -c -O3 /home/franco/swifthjs/coord/*.f
ifort -c -O3 /home/franco/swifthjs/discard/*.f
ifort -c -O3 /home/franco/swifthjs/hjs/*.f
ifort -c -O3 /home/franco/swifthjs/io/*.f
ifort -c -O3 /home/franco/swifthjs/lyap/*.f
ifort -c -O3 /home/franco/swifthjs/lyap2/*.f
ifort -c -O3 /home/franco/swifthjs/mvs/drift/*.f
ifort -c -O3 /home/franco/swifthjs/mvs/getacch/*.f
ifort -c -O3 /home/franco/swifthjs/mvs/kickvh/*.f
ifort -c -O3 /home/franco/swifthjs/mvs/step/*.f
ifort -c -O3 /home/franco/swifthjs/orbel/*.f
ifort -c -O3 /home/franco/swifthjs/rmvs/*.f
ifort -c -O3 /home/franco/swifthjs/rmvs2/*.f
ifort -c -O3 /home/franco/swifthjs/rmvs3/*.f
ifort -c -O3 /home/franco/swifthjs/tu4/*.f
ifort -c -O3 /home/franco/swifthjs/obl/*.f
ifort -c -O3 /home/franco/swifthjs/util/*.f
ifort -c -O3 /home/franco/swifthjs/symba5/*.f
ifort -c -O3 /home/franco/swifthjs/helio/*.f
ar -rv /home/franco/swifthjs/libswift.a *.o
ar: creating /home/franco/swifthjs/libswift.a
a - anal_energy.o
a - anal_energy_discard5.o
a - anal_energy_hjs.o
a - anal_energy_mtiny.o
a - anal_energy_write.o
a - anal_energy_write_hjs.o
a - anal_jacobi.o
a - anal_jacobi_write.o
a - bs_der.o
[another 200 subroutines]
a - reader.o
Well, that's not the command you showed originally. And I see reader.o in the output from ar. So what makes you think it isn't working?
I changed the names in the original to make them more self-explanatory, but they are identical.
ar -rv $(MY_DIR)/libmy.a *.o = ar -rv /home/franco/swifthjs/libswift.a *.o
The command executes OK and the library appears to be built, in that its attributes change. However, its size does not, so it seems as if "reader" is not being incorporated. Running the main program produces results that do not reflect changes made in "reader". (Another oddity is that sometimes the main program does not compile, producing an error message "undefined reference to `reader_'".)
What puzzles me is that all the other subroutines shown above have no problem. What is it about "reader" that makes it different?
In the original you explicitly named reader.o, but what you're really doing is wildcarding the object files.
If the library already contained reader then the use of -r would replace it. You can use the nm command to see what symbols are in the library.
Your mention that "sometimes" the program does not link (not "compile") suggests something else is going on - either it would always work or never work.
It reads to me as if there's an issue with your build environment, not the compiler. You should examine more closely what gets compiled, where the objects go, etc. Maybe ld has some way of showing where various symbols were resolved. Is there perhaps another object containing reader_?
There was a previous version of "reader.f", saved under the completely different name "a.f", in the same directory as "reader.f". Deleting this file leads to the "undefined reference to `reader_'" error. Renaming it to anything not ending in .f leads to this error as well.
I simply copied the contents of "reader.f" into "a.f", deleted the original "reader.f" and renamed "a.f" to "reader.f", after which everything worked.
So I found the solution, although I still do not know what the problem is! How the file "a.f" could have any influence when it is not referred to anywhere, remains a puzzle.