Compiler warnings since upgrade

Discussion on computers, ROMS installation and compiling

Moderators: arango, robertson

Post Reply
Message
Author
julian.kuhlmann
Posts: 24
Joined: Wed Sep 07, 2011 4:13 pm
Location: GFZ Potsdam

Compiler warnings since upgrade

#1 Unread post by julian.kuhlmann »

Hi,

since the last update (announced here), I receive a bunch of warnings at the beginning of compilation:

Code: Select all

ROMS/Nonlinear/Module.mk:13: warning: overriding commands for target `/.../Build/libNLM.a'
ROMS/Nonlinear/Module.mk:13: warning: ignoring old commands for target `/.../Build/libNLM.a'
ROMS/Nonlinear/Module.mk:15: warning: overriding commands for target `/.../Build/bbl.o'
ROMS/Nonlinear/Module.mk:15: warning: ignoring old commands for target `/.../Build/bbl.o'
ROMS/Nonlinear/Module.mk:15: warning: overriding commands for target `/.../Build/bbl.f90'
ROMS/Nonlinear/Module.mk:15: warning: ignoring old commands for target `/.../Build/bbl.f90'
...
...
...
As I understand the messages, there are some rules for the "make" command set twice, but I am unable to find out where exactly. Am I the only one with this problem? Does anybody have an idea of how to solve it?

Cheers,
Julian

User avatar
arango
Site Admin
Posts: 1347
Joined: Wed Feb 26, 2003 4:41 pm
Location: DMCS, Rutgers University
Contact:

Re: Compiler warnings since upgrade

#2 Unread post by arango »

Yes, this is due to the cyclic dependency in the modules target in the makefile. We have to include ROMS/Nonlinear twice recently.

I guess that we cannot satisfy everybody... We have an user :arrow: reporting that he was unable to compile and none of us where able to reproduce his problem. I was suggested that included the dependency twice for ROMS/Nonlinear in the modules will solve his problem. Perhaps, we need to look for an alternative. Otherwise, we are going to all you panicking about this compilation inconsequential warning message.

Maybe we should remove that cyclic dependency since it is affecting everybody and force the other user to investigate more why he is having dependency problems that others don't have.

User avatar
kate
Posts: 4088
Joined: Wed Jul 02, 2003 5:29 pm
Location: CFOS/UAF, USA

Re: Compiler warnings since upgrade

#3 Unread post by kate »

Was there a reason the uv_rotate.F file was placed in Nonlinear and not Utility? Moving it to Utility would remove that cycle.

User avatar
arango
Site Admin
Posts: 1347
Joined: Wed Feb 26, 2003 4:41 pm
Location: DMCS, Rutgers University
Contact:

Re: Compiler warnings since upgrade

#4 Unread post by arango »

Yes. It can be adjointed. But we have several modules in ROMS/Nonlinear that are used in the ROMS/Utility directory. This includes the bc2d.F, bc3d.F, exchange_2d.F, exchage_3d.F, scale_omega, and so on. I don't understand why uv_rotate.F has to be different. This cross-directory references are used extensively in 4D-Var and we never heard about dependency problems with these algorithms.

Recall that the cycling problem with uv_rotate is happening to a single user, as far as we know. I have not been able to reproduce his problem in several computers and compilers. Do you think that he maybe having problems with sfmakedepend in his computer?

I may be forced to remove that cyclic dependency from the makefile. I have received five private e-mails about this in the last three days... It is better to have a single user with that problem that everybody complaining and panicking about these warnings...

User avatar
arango
Site Admin
Posts: 1347
Joined: Wed Feb 26, 2003 4:41 pm
Location: DMCS, Rutgers University
Contact:

Re: Compiler warnings since upgrade

#5 Unread post by arango »

I reverted the recent change to the makefile. Please check the following repository :arrow: ticket.

julian.kuhlmann
Posts: 24
Joined: Wed Sep 07, 2011 4:13 pm
Location: GFZ Potsdam

Re: Compiler warnings since upgrade

#6 Unread post by julian.kuhlmann »

Thanks, Hernan! This did the trick for me, I can now again compile without errors or warnings.

User avatar
m.hadfield
Posts: 521
Joined: Tue Jul 01, 2003 4:12 am
Location: NIWA

Re: Compiler warnings since upgrade

#7 Unread post by m.hadfield »

arango wrote:Yes. It can be adjointed. But we have several modules in ROMS/Nonlinear that are used in the ROMS/Utility directory. This includes the bc2d.F, bc3d.F, exchange_2d.F, exchage_3d.F, scale_omega, and so on. I don't understand why uv_rotate.F has to be different. This cross-directory references are used extensively in 4D-Var and we never heard about dependency problems with these algorithms.
Perhaps the difference is that these other modules are referenced by code in Nonlinear as well as by code in Utility.

As I understand it, the way most (many?) Unix linkers work when given a list of libraries to process is to take out of each library only the symbols that are known to be needed at the time that library is processed. So if the linker command is (in cut down form)

Code: Select all

/usr/bin/gfortran -o oceanS ocean_control.o  libNLM.a libUTIL.a libMODS.a -lnetcdf
then the linker will pull out a given symbol from libNLM.a only if that is referenced by ocean_control.o or libNLM.a. If the first time it comes across a reference to that symbol is in libUTIL.a then the linker won't know to go back and look for it in libNLM.a, therefore linking fails.

Why hasn't this been a problem before? Possibly because the modules that Hernan lists are referred to by code in the Nonlinear subdirectory, as well as code in the Utility subdirectory. (In the case of scale_omega, the only place this particular subroutine is called is in Utility/wrt_his.F, but the Fortran module that contains it, namely omega_mod, is used by Nonlinear/initial.F and Nonlinear/main3d.F. The fact that the current problem is not encountered for scale_omega suggests that Fortran linkers import all the public symbols from a given Fortran module when that module is used.)

In the case of uv_rotate (or, to be more exact, module uv_rotate_mod which has public subroutines uv_rotate2d and uv_rotate3d) this is used by Nonlinear/set_avg.F as well as Utility/wrt_his.F. But the former only gets past the preprocessor when AVERAGES is defined. So I expect that the uv_rotate problem will only crop up when AVERAGES is not defined. This is consistent with my own experience, though I haven't yet checked it out systematically.

User avatar
arango
Site Admin
Posts: 1347
Joined: Wed Feb 26, 2003 4:41 pm
Location: DMCS, Rutgers University
Contact:

Re: Compiler warnings since upgrade

#8 Unread post by arango »

Interesting... Your explanation makes sense to me. The only hole in this story is why I cannot reproduce this problem in my LINUX and DARWIN computers with the ifort, pgi, and gfortran compilers versions that I have. What it is so special about all my computers?

The reason why uv_rotate.F is now in ROMS/Nonlinear is because it is possible to be adjoint it in the future. Anyway, I already have several routines in ROMS/Utility with the adjoint and tangent linear versions in them. Nowadays, I prefer to have mostly all the ROMS routines inside modules so the checking of arguments is strict. I guess that the only alternative that I have is to move uv_rotate.F to ROMS/Utility. This was my intention at the beginning and was also suggested by you and Kate.

Post Reply