Bugzilla – Bug 127745
g77 (fortran) compile problem, missing cc1
Last modified: 2007-07-24 07:29:05 UTC
Hello, I'd like to compile a fortran program (77). I have the compat g77 rpm installed, and all gcc stuff also. When I try to compile this file I got an error: "g77: installation problem, cannot exec `cc1': No such file or directory" Ok, so I softlinked the cc1 from gcc-4.02. Unfortunatelly in this case I'd got the "cc1: error: too many filenames given. Type cc1 --help for usage" error. What is not suprising me since they are (the g77 and cc1) from different gcc. So maybe you should put some more stuff in compat-g77 rpm... (and unfortunatelly the fortran code is not g95 compatible) (I've "almost" checked everything to my needs in b4 and Rc1 release but this one somehow didn't pup up) Thanks, Tamas
I've checked Fedora(sorry :) ), they put full gcc stuff in the compat rpms (gcc,libs,g77 etc) so maybe this would be needed here. (since some prg is not gcc-4.0 compatible neither, we need old gcc-3x as well. Tamas
I was on vacation. This error message should only happen when you include C files in the call to the g77 compiler. Please post the full commands which lead to the failure.
Well, g77 -o low lowtran7.1.F and I will attach this fortran source also. However I solved my problem to install the full gcc 3.4.4 to /usr/local. After doing it, I had a problem with lyx and octave and with libgcc_s.so.1. So I changed the name of this lib in /usr/local to libgcc_s.so.1.gcc344. ( this solution not clever I know, but for me is sort enough)
Created attachment 55728 [details] fortran source file (big one)
The reason is the extension .F (big F), which makes g77 invoke the C preprocessor (which then fails). Renaming the file to lowtran7.1.f should work around this problem. Hmm. I could perhaps include the 3.3 cc1 in the compat-g77 package, but I don't know if we will release YOU updates for this type of error. Btw, out of interest: does your program not build with gfortran (gcc-fortran package)? If it does you wouldn't need the compat-g77 package. It _does_ compile f77, but might indeed have some bugs.
Whoa, I've never thought the big F means anything at all. Thanks. Unfortunatelly this code is good with g77 only. I've tried the others but no success. ( I'm not fortran programmer, and this code is very old and to big for me.)I guess we will drop out this code anyway. Thanks again, Tamas
FIXED
This bug is _not_ fixed, it is still present in 10.0, 10.1 and 10.2-factory. Renaming sources from *.F to *.f is not a fix because the capital F _does_ have a special meaning. Not being able to compile *.F is a bug in the compiler package itself and not in the sources.
What meaning does the capital F have? (Besides from invoking the C preprocessor)
Why "besides"? The capital F is equivalent to invoking g77 as "g77 -x f77-cpp-input source.f", which is necessary to compile existing code that uses #include and #define directives. It's a different language option. Since the whole point why there is a compat-g77 package at all is being able to compile existing code, I consider it a real problem - the "-x f77-cpp-input" option is explicitly mentioned in the g77 man page and does not work currently. A fix for factory (10.2) would be fine for me if the issue does not look severe enough for a YOU.
*** Bug 192186 has been marked as a duplicate of this bug. ***
Hello, Just want to let everybody know, that we have exactly the same problem with another (old) Fortran program: The code is definitely not compiling with the new gfortran, cannot be updated easily (~100.000 lines of code), and requires to call the C preprocessor due to #include and #define directives. Any chance to make a working compat-g77 package? That on Readhat is working... Thanks, Andreas
Hi, I can only support the above requests to fix this issue. We need C preprocessor options in our Fortran sources and can only compile with g77. We run SUSE LINUX 10.0. Please get this to work. Thanks. Thomas
Hi all, I'm currently trying to port a large package of important astronomical data analysis software to 10.1 for my astrophysicist users and this bug is stopping me, so I'd like to add my voice to those requesting an update soon with the preprocessor restored. Regards, Laurence.
(moving product to openSUSE 10.2 because an update for earlier released distributions seems unlikely)
Hi, we also would love to see this issue resolved! Is someone working on a fix? Thanks, Richard
g77 is now available via the gcc33 packages from the http://software.opensuse.org/download/home:/rguenther/* repositories (i386 and x86_64 only).
(In reply to comment #17) I have also run into this bug occassionally in 10.1 (and 10.0?). I usually got around it somehow -- at least once copying a previous cc1 file into some directory where it was needed. I'm just starting with 10.2, and don't have this specific experience yet. (But see bug 235256.) A large fraction of the scientific community (at least) is still bound to g77. Our university HPC uses g77 and, because it seemingly works well, I don't expect to see gfortran for some time yet. Converting from g77 to gfortran is much worse than from gcc 2.95 to 3.0+. Compile flags must sometimes be changed, along with some code. It took me weeks to convert a major, complex package (from CERN) to gfortran, while keeping g77 in the scripts for installations that needed it. I also have an application (CERN related) that comes as an object library generated with g77 and a carefully designed script for linking it (and user routines) on the host machine. I am just expressing a strong voice that g77 be kept as part of openSuSE, and easily useable, for a few more releases.
Fixing together with #218406.
released
Dears, I'm New on SuSE and I having problem to compile a program that requires g77 compiler. I read this bug and the comments, and saw that was released a fix for this bug, but I could not find where to download. Can somebody teach me how do I find it to download? I use SuSE Enterprise 10.2 Thanks. Sorry for my inexperience. D. A.
It is available as 'compat-g77' package on the 10.2 DVD.