compile, but does not build

[ybilodid]

Hi!

I'm trying to use FoBiS on a very cumbersome project. FoBiS does a great job - goes through all nested folders, compiles each and every subroutine and module and puts all object files into build/obj/ But the error occurs on the linking step – huge amount of errors like that one:

build/obj/subroutine1.o: In function ` subroutine1_':
subroutine1.f:(.text+0x393): undefined reference to `__module1_MOD_var1'

listing probably each variable in each USE statement.

The most confusing thing is that simple running in the /build$ gfortran -o target ./obj/*.o works perfectly. So why It does not work with FoBiS?

I am using gfortran 6.3.0 on ubuntu 14.04. Examples from FoBiS distribution are running well. The fobos file I'm using:

[default]
compiler=Gnu
mpi=False
cflags=-c -cpp
mod_dir=./mod/
obj_dir=./obj/
build_dir=./build/
src=./src/
colors=True
quiet=False
jobs=1
output=target
log=True

[szaghi]

Wow, dear @ybilodid

this sounds very "cumbersome" :smile:

At a first sight I am really confused about what is going wrong, surely there should be a bug in FoBiS linking command, but I cannot figure out what...

Can you provide me a minimal example reproducing the bug? Is your sources public?

I am very busy in this period, thus I am not able to re-create the test alone on the basis of your description, I am sorry.

Thank you very much for reporting the bug!

[ybilodid]

Thanks a lot for a response!

The source is unfortunately not public - it's a legacy code for reactor simulation. Hundreds of routines and modules. I'll try to produce some example which reproduces the problem. In between I also tried to compile the code using FoBiS on virtual machine with Ubuntu 17 and gfortran 7 - with the same result.

Yuri

On 11 Dec 2017 3:40 p.m., "Stefano Zaghi" notifications@github.com wrote:

Wow, dear @ybilodid https://github.com/ybilodid

this sounds very "cumbersome" 😄

At a first sight I am really confused about what is going wrong, surely there should be a bug in FoBiS linking command, but I cannot figure out what...

Can you provide me a minimal example reproducing the bug? Is your sources public?

I am very busy in this period, thus I am not able to re-create the test alone on the basis of your description, I am sorry.

Thank you very much for reporting the bug!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/szaghi/FoBiS/issues/100#issuecomment-350742977, or mute the thread https://github.com/notifications/unsubscribe-auth/Agyog9aiCm04YaT76TL97OAdbej-ghYBks5s_T7ogaJpZM4Q70Dh .

[szaghi]

In between I also tried to compile the code using FoBiS on virtual machine with Ubuntu 17 and gfortran 7 - with the same result.

Yes, the problem is luckily into FoBiS rather than in gfortran. I think that something odd happens in the linking command that FoBiS generate, but it is really difficult to investigate without a working example.

One thing you could check is: are there more than one program into the sources you are building? if yes, it could be a hint for me.

Cheers.

[ybilodid]

there is only one Programm definition in sources. But I think I got a trace: in verbose mode fobis prints the linking command, which list explicitly each .o file which should be included: gfortran -J build/mod build/obj/ndslay.o build/obj/nd_mhex2.o ..... -o build/target.exe the problem is - there are 416 .o files in a linking list, but /obj/ contains 528 files. so, the linking command missed some files (which were compiled). this is why `gfortran -J build/mod build/obj/.o ..... -o build/target.exe` works.

[szaghi]

the problem is - there are 416 *.o files in a linking list, but /obj/ contains 528 files.

This was the kind of issue I was thinking to: the linking command is missing something; this happened in the past when the building concerns multiple programs...

Another question: what kind of sources are your compiling? All modules, or also old-fashioned sources with a "collection of fortran units" not enclosed into a module? Are there files containing multiple modules or a mixture of modules and non-module units? There should be some "corner-cases" that I have not considered...

Can you compare the list of compiled objects (.o) with fortran sources?

I am sorry to bother you, but without having the bug-reproducer in my hands I have to go by blind-guesses.

Cheers.

[ybilodid]

the source is old-style, the most is fixed format 77-style. most files are subroutines, not enclosed to modules. these subroutines use modules which mainly contain only global variables. I have compared lists of objects: seems like modules are compiled, their .o put in /obj and .mod in /mod - but they are missing in a linking command I'm trying to reproduce the problem on an smaller example, but did not succeed so far

[szaghi]

seems like modules are compiled, their .o put in /obj and .mod in /mod - but they are missing in a linking command

Ok, it is now more clear... something into the hierarchy of the dependencies are going to be lost...

I'll try to dig it deeper soon.

Thanks.

P.S. this is a corner case for me, because I do not use old fashioned projects.

[szaghi]

Dear @ybilodid

Thank you for the example you provided: I found the bug, but it is not very simple to solve. Essentially the reason is: the module that is not a direct dependency of the program is difficult to be tracked. In your example, there are 2 modules that are necessary, but that are not a direct dependency of the target: the target (your main program) needs that modules by means of some units (subroutine) contained into an old fashioned sources, outside a module scope... I have to find a simple way to deal with this scenario. I need more time, sorry.

Cheers.

P.S. basing on your example I have now a very simple test of 3 sources raising the bug, thank you very much.

[szaghi]

Dear @ybilodid

I have just uploaded a new version with the hope to have solved the bug. Please, can you check the new version (2.2.8) with your real program?

Thanks a lot.

[ybilodid]

Yes, it works! Thanks a lot!

[szaghi]

Thanks a lot!

You are welcome!

Thank you too for pointing out this subtle bug!