directory name must immediately follow -I compile error

Hello,

I am trying to compile some code under opensuse 12.2. The code compiles fine under cygwin and CentOS. Under suse, I get the error "directory name must immediately follow -I"

This is the place in make where the error happens.

Code:

---

g77-3.3 -I ./src/src_common_depend/ -O2 -DVERNUM=6 -c -o bld_dir/FortranA.o src/src_client_main/FortranA.FOR
f771: error: directory name must immediately follow -I

---

The includes are specified in the make file with,
SOURCELOC = ./src
INCLUDES = -I ${SOURCELOC}/src_common_depend/

These are common includes that are used by more than one applications and so are stored in a common location.

I have tried leaving off the ./ and the trailing /

SOURCELOC = src
INCLUDES = -I ${SOURCELOC}/src_common_depend

And various similar combinations, including parenthesis instead of the curly braces.

I'm not sure why gcc under suse would be particular about this syntax when gcc under other distros seem to think it's fine. I really have no idea what to try next, so any suggestions would be a bit help. I can post the rest of the makefile if that would be useful.

This is the compile rule that g77 is implementing where the error occurs,
# compile src fortran objects with fortran preprocessor
$(BDIR)/%.o: $(SOURCELOC)/src_client_main/%.FOR
$(FCOMP) $(FCFLAGS) $(VFLAGS) -c -o $@ $<


LMHmedchem

Quote:

---

Originally Posted by LMHmedchem

I'm not sure why gcc under suse would be particular about this syntax when gcc under other distros seem to think it's fine.

---

It's not the OS that is important, it is the version of gcc.

What is the version of gcc? There is a command-line option that outputs the version (don't remember what it is). If the versions are different, then that could be one reason why others work while one doesn't.

Regards,

Paul McKenzie

The opensuse version of g77 is 3.3.3-hammer. Under cygwin, the version is 3.4.4. I would have to open the cent VM to check, but I think that is 3.4 as well. I have compiled this src under cygwin and cent going back several years, so I'm sure that I used 3.3 there with no problems as well. This same makefile seems to work on opensuse with gcc 4.7, so I'm not sure what the issue is. It doesn't seem as if I can upgrade gcc3 to 3.4 in suse yast.

LMHmedchem

Well, it tells you what's wrong:
"error: directory name must immediately follow -I"
This means that in your line
g77-3.3 -I ./src/src_common_depend/
there is one blank too much: between the I and .

HTH
Richard

Quote:

---

Originally Posted by Richard.J

Well, it tells you what's wrong:
"error: directory name must immediately follow -I"
This means that in your line
g77-3.3 -I ./src/src_common_depend/
there is one blank too much: between the I and .

HTH
Richard

---

Well that would be annoyingly simple. I need to go back a bit and test that. Why would all the other versions of gcc that this compiles under not care about the extra space?

LMHmedchem

Well removing the space does get it to compile, except there are some errors. Oddly, these compiler errors do not show up under gcc3.4 cygwin, only under gcc3.3 opensuse. That is another issue I guess.

I am getting the error,
error: call of overloaded `sqrt(int&)' is ambiguous

The code is,
X0 = X0 + 1/sqrt(molAtoms[currentAtom].simpleDelta);

molAtoms[currentAtom].simpleDelta is an int and XO is a double, so I guess I need to specifically cast this. Again, I'm not sure why it works in other versions. Do I need to convert molAtoms[currentAtom].simpleDelta to a float as well?

LMHmedchem

Quote:

---

Originally Posted by LMHmedchem

Well removing the space does get it to compile, except there are some errors. Oddly, these compiler errors do not show up under gcc3.4 cygwin, only under gcc3.3 opensuse. That is another issue I guess.

I am getting the error,
error: call of overloaded `sqrt(int&)' is ambiguous

The code is,
X0 = X0 + 1/sqrt(molAtoms[currentAtom].simpleDelta);

molAtoms[currentAtom].simpleDelta is an int and XO is a double, so I guess I need to specifically cast this. Again, I'm not sure why it works in other versions.

---

You have to understand that C++ has a language standard, and many (practically all) compilers have to fix their compilers to adhere to the ANSI standard.

So the reason why it "works" on one compiler and not another is that either a good user informed the gcc team that their compiler was non-comliant, or the gcc team discovered this on their own. So to fix that, they make the compiler more ANSI compliant in the next version.

So it was your code all along that was incorrect, and that the new compiler no longer accepted it. If you stick to reading ANSI standard documentation on the sqrt() function and coded to the standard, a change in the gcc compiler will not affect you.

The sqrt() function has various overloads. From this link, sqrt() for C++ 98 has three overloads:

http://www.cplusplus.com/reference/cmath/sqrt/

The call is ambiguous since due to the conversion rules of C++ from int to a bigger type. So stick to with double, float, and long double, or cast to one of these types.

Regards,

Paul McKenzie

Since X0 and XV0 are doubles, I changed to,

// simple X0, sum reciprocal square root of simple delta
X0 = X0 + 1/sqrt( (double)molAtoms[currentAtom].simpleDelta );

The compiler didn't complain about this second instance where molAtoms[currentAtom].valenceDelta is a float and XV0 is a double.
XV0 = XV0 + 1/sqrt(fabs(molAtoms[currentAtom].valenceDelta));

Even thought the compiler doesn't complain about this, is it better practice to cast the float anyway?
XV0 = XV0 + 1/sqrt(fabs( (double)molAtoms[currentAtom].valenceDelta ));

LMHmedchem

Quote:

---

Originally Posted by LMHmedchem

Since X0 and XV0 are doubles, I changed to,

// simple X0, sum reciprocal square root of simple delta
X0 = X0 + 1/sqrt( (double)molAtoms[currentAtom].simpleDelta );

The compiler didn't complain about this second instance where molAtoms[currentAtom].valenceDelta is a float and XV0 is a double.
XV0 = XV0 + 1/sqrt(fabs(molAtoms[currentAtom].valenceDelta));

Even thought the compiler doesn't complain about this, is it better practice to cast the float anyway?
XV0 = XV0 + 1/sqrt(fabs( (double)molAtoms[currentAtom].valenceDelta ));

LMHmedchem

---

I guess in this case, since it is an int, it doesn't make a real difference if you casted to float or double.

Hopefully, you're testing for divide by 0. In the code you posted, you don't seem to be doing that.

Regards,

Paul McKenzie

Quote:

---

Originally Posted by Paul McKenzie

I guess in this case, since it is an int, it doesn't make a real difference if you casted to float or double.

Hopefully, you're testing for divide by 0. In the code you posted, you don't seem to be doing that.

Regards,

Paul McKenzie

---

For the second case,
XV0 = XV0 + 1/sqrt(fabs( (double)molAtoms[currentAtom].valenceDelta ));

The class member molAtoms[currentAtom].valenceDelta is a float, but XVO is a double. I am running fabs() on molAtoms[currentAtom].valenceDelta because it can be negative and I want the abs. The compiler doesn't seem to care about the type differences in this case, but it seems like it makes sense to cast molAtoms[currentAtom].valenceDelta as a double to keep it consistent with the result variable XV0.

Vriables like molAtoms[currentAtom].simpleDelta are checked in a number of places before this part of the code. This is the number of neighbors for a graph vertex and if that value were 0, there would be all kind of frags from things like the distance matrix. I don't usually check variables like that after the initial read in.

LMHmedchem

Quote:

---

Originally Posted by LMHmedchem

Vriables like molAtoms[currentAtom].simpleDelta are checked in a number of places before this part of the code. This is the number of neighbors for a graph vertex and if that value were 0, there would be all kind of frags from things like the distance matrix. I don't usually check variables like that after the initial read in.

---

It still is dangerous to assume that the data is good, or that your code always takes the path that you expect it to take.

At the very least, an assert() should be placed before those calculations, so that any division by 0 can be detected.

Regards,

Paul McKenzie

I guess I need to add some additional error checking like that. These global variables, like the number of graph neighbors, are used for thousands of calculations and it would be a bore to check everything before each one. I probably need to go through and find key places to check values, like at the beginning of a function, or check to insure that the function call actually produced a value to return. Most of the checking I do is to the output. I run through thousands of molecules and check to make sure that the output is what it should be.

Thanks again, Paul and to Richard.J as well.

LMHmedchem