g++ build on SUSE 12.1, cannot open included file

Linux and Unix-Like SuSE
1

Hello,

I have a project that I have compiled on a number of linux systems including CentOS, Ubuntu, and Windows Cygwin. I am trying to build the project under SUSE 12.1. The make file runs allot of the way through, but then throws an error that an included file can't be opened.

This is the include statement (in fortran),

C  Error codes that may be encountered when processing inputs.
       INCLUDE 'MOLERRORS.DAT'

The file exists and is in the same directory. It does not appear to be a permissions issues because the entire directory is set to 777. This exact code base compiles on a number of other linux platform through a multi boot setup, so I can't understand why there is an issue with this.

This is the compile line from the make,

# compile src gfortran objects with fortran preprocessor
$(BDIR)/%.o: $(SOURCELOC)/src_client_main/%.FOR
	$(FCOMP) $(FCFLAGS) $(VFLAGS) -c -o $@ $<

Before I got the error, allot of objects that complied successfully even though they had the same include, so I am more than a bit baffled. I'm not even sure where to start looking.

Any suggestions?

LMHmedchem

2

It is probably a compiler issue. But I do not know either. strace can be used for this kind of thing. Sometimes.

This will produce a list of all syscalls involving file I/O. And their return codes, look for -1 return codes and the name of the error like ENOENT EPERM.

strace -e trace file -f -ff -o outputfilefromtrace  make -f mymakefile.mk

For a large build this may not be feasible, but it appears you are just building one tool set.
The -ff option creates separate files for each child process, you can then grep for -1

The candidate syscall most likely to fail is stat - stat is used to traverse PATH variables or -I dirname kinds of compiler directives.
In your case the last file in

 ls -lstr outputfilefromtrace*

contains the culprit's fingerprints.

3

This is an include inside of another included file, so I don't know if that is the problem, but I don't see how it could work some times and not others. I will look at the trace. I will also just manually add the included file, since the data is always there. I don't remember why this was a separate file in the first place.

LMHmedchem

4

There were limits to the number of "sub" includes - used to be 12 for the c++ standard.
If I remember correctly. And I do recall that this limit is perpetuated thru the gcc family.
Whatever it is today...

1 Like
5

Well I got it hacked, more or less. The problem was the the first include statement was in a file in a different sub directory than the included file. The included was done as,

      INCLUDE '../src_client_main/PARAM.DAT'

Within the included PARAM.DAT file, there was the regular include I listed above. I guess it looks like,

./src_models/MODELS.FOR (INCLUDE '../src_client_main/PARAM.DAT')
./src_client_main/PARAM.DAT, MOLERRORS.DAT

PARAM.DAT has the INCLUDE 'MOLERRORS.DAT' in it. When the pre-processer was working on MODELS.FOR, it was able to find PARAM.DAT when referenced with that kind of path, but it didn't look for MOLERRORS.DAT with the ../src_client_main/ path. I guess it just looked for ./MOLERRORS.DAT and didn't find it. This setup works under cygwin, ubuntu, and cent, so I am surprised there is a difference with suse. I think it's all the same gcc stuff, but I guess I should look into it. It runs quite a bit slower under suse, so maybe not.

I guess I need to investigate a better way to set up my src structure. I have files in a few different sub folders, but there are some dependencies that need to be included from several places. I'm not sure how to address that without doing something lame like having several copies of the included files. It seems like there was a way to list the dependencies in the make file and include them on the compile line instead of explicitly in the src file, but I'm not sure about that.

LMHmedchem