[SOLVED] Fortran Compiler Issue

[SanguinePenguin]

I wrote a fortran77 program to run on a computing network, but it isn't compiling there. I have successfully compiled and run it on a different machine. I got similar errors to these when I tried to run it on it on the other machine using just gfortran (instead of g77). I've been trying to troubleshoot this with no luck. I tried using other other compiler versions (g77, f95, gfortran, gfortran -std=legacy, gcc34, gcc, gcc44) with no luck (in fact the others would spew out even more errors).

Also, it would be difficult to rebuild the compiler as I don't have root user access.

Any help would be greatly appreciated.

Also, I know I shouldn't write in fortran, but the program requires legacy code.

Thanks!

g77 HEPMC2STDHEP.f -o HEPMC2STDHEP -O2 -LMG_ME_V4.4.32/pythia-pgs/libraries/PGS4/lib -lFmcfio -lstdhep -lexthep

The Error:

MG_ME_V4.4.32/pythia-pgs/libraries/PGS4/lib/libstdhep.a(stdxend.o): In function `stdxend_':
ccLn4gW6.f:(.text+0x1f): undefined reference to `mcfio_infostreamint_'
ccLn4gW6.f:(.text+0x36): undefined reference to `mcfio_infostreamint_'
ccLn4gW6.f:(.text+0x44): undefined reference to `mcfio_close_'
MG_ME_V4.4.32/pythia-pgs/libraries/PGS4/lib/libstdhep.a(stdxwinit.o): In function `stdxwinit_':
ccwl8fRD.f:(.text+0x43): undefined reference to `mcfio_init_'
MG_ME_V4.4.32/pythia-pgs/libraries/PGS4/lib/libstdhep.a(stdxwopen.o): In function `stdxwopen_':
ccq6AQdF.f:(.text+0xc9): undefined reference to `mcfio_openwritedirect_'
MG_ME_V4.4.32/pythia-pgs/libraries/PGS4/lib/libstdhep.a(stdxwcm1.o): In function `stdxwcm1_':
ccuGtfTj.f:(.text+0x50): undefined reference to `mcfio_block_'
ccuGtfTj.f:(.text+0x68): undefined reference to `mcfio_nextevent_'
ccuGtfTj.f:(.text+0x9a): undefined reference to `mcfio_block_'
ccuGtfTj.f:(.text+0xaf): undefined reference to `mcfio_nextevent_'
MG_ME_V4.4.32/pythia-pgs/libraries/PGS4/lib/libstdhep.a(stdxwevt.o): In function `stdxwevt_':
ccS6Pppo.f:(.text+0xb0): undefined reference to `mcfio_block_'
ccS6Pppo.f:(.text+0xd2): undefined reference to `mcfio_seteventinfo_'
ccS6Pppo.f:(.text+0xe0): undefined reference to `mcfio_nextevent_'
ccS6Pppo.f:(.text+0x11a): undefined reference to `mcfio_block_'
ccS6Pppo.f:(.text+0x13c): undefined reference to `mcfio_seteventinfo_'
ccS6Pppo.f:(.text+0x14a): undefined reference to `mcfio_nextevent_'
MG_ME_V4.4.32/pythia-pgs/libraries/PGS4/lib/libstdhep.a(stdxwevtlh.o): In function `stdxwevtlh_':
ccy0mybv.f:(.text+0xb0): undefined reference to `mcfio_block_'
ccy0mybv.f:(.text+0xd2): undefined reference to `mcfio_seteventinfo_'
ccy0mybv.f:(.text+0xe0): undefined reference to `mcfio_nextevent_'
ccy0mybv.f:(.text+0x11a): undefined reference to `mcfio_block_'
ccy0mybv.f:(.text+0x13c): undefined reference to `mcfio_seteventinfo_'
ccy0mybv.f:(.text+0x14a): undefined reference to `mcfio_nextevent_'
MG_ME_V4.4.32/pythia-pgs/libraries/PGS4/lib/libstdhep.a(stdxwevtup.o): In function `stdxwevtup_':
cciS59rz.f:(.text+0x8b): undefined reference to `mcfio_block_'
cciS59rz.f:(.text+0xa0): undefined reference to `mcfio_nextevent_'
cciS59rz.f:(.text+0xda): undefined reference to `mcfio_block_'
cciS59rz.f:(.text+0xef): undefined reference to `mcfio_nextevent_'
collect2: ld returned 1 exit status

VERSION ON SERVER:

$ g77 -v
Reading specs from /usr/lib/gcc/x86_64-redhat-linux/3.4.6/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-languages=c,c++,f77
--disable-libgcj --host=x86_64-redhat-linux
Thread model: posix
gcc version 3.4.6 20060404 (Red Hat 3.4.6-4)

VERSION ON OTHER COMPUTER:

$ g77 -v
Reading specs from /usr/local/lib/gcc/i686-apple-darwin8.11.1/3.4.0/specs
Configured with: ../gcc-3.4.0/configure --enable-altivec
--enable-languages=c,f77
Thread model: posix
gcc version 3.4.0 (grh-5)

[Rubberman]

It looks like you are missing some libraries, hence the "undefined reference" errors you are getting. Your code, or some code yours uses, calls functions that are not available. You need to determine what libraries contain these symbols and link them as well. It may be that they need to be installed on the problem machines.

[ramin.honary]

I second Rubberman's response.

It could also be that the libraries you want are already installed on the remote machine, but not in the place the compiler expects them to be. You may need to set an environment variable like

export LD_LIBRARY_PATH="/lib/path/on/remote/node"
# (I don't know if gfortran or g77 uses that environment variable or not, though.)

You could also solve the issue by specifying these library paths on the command line. But you will need to read the "g77" manual to learn which command line switches can be used to point the compiler to the correct library paths.

[SanguinePenguin]

Rubberman & ramin.honary: Thank you both for your responses. Unfortunately, I am almost certain that I am correctly linking the programs. I know this because on the other system I am finding them in the exact same basic package which is fully installed on both machines. All of them are in the shared libraries.
libFmcfio.a
libstdhep.a
libexthep.a
Which are all in the folder "MG_ME_V4.4.32/pythia-pgs/libraries/PGS4/lib"

The exact same library links on the other machine work correctly (with the corresponding address modified - but I know this is correct on this machine because the errors are all arising in subsets of the -lstdhep). I checked carefully and all three libraries are located in the same directory.

I am certain this is a compiler error, because when I use a different compiler on the other machine (which is truthfully linked to the relevant libraries in the same way), it gives me nearly the same errors. It is only when I choose g77 on that machine that it will work. I know fortran has some major issues from release to release, so I feel like there is some flag that needs to be activated (like "-ffixed-length" or something) in order for it to compile, but I don't know which ones it would be.

Unless I am confused, the command line switches to point g77 to the right place are:
-LMG_ME_V4.4.32/pythia-pgs/libraries/PGS4/lib -lFmcfio -lstdhep -lexthep

Again, thank you for your responses. Any further help is appreciated.

[ramin.honary]

It is impossible for "g77" to link to a binary library compiled with "gfortran". Do you know what version of the libraries are installed on all the machines? Are they all identical, is the only difference the versions of the compiler?

Is it possible you have mixed libraries produced from both G77 and GFortran and you are trying to use them together? Is the "stdhep" and "exthep" compiled with the same version as the MG_ME_V4.4.32 libraries?

Try compiling with the "gfortran -ff2c" flag. The "-ff2c" switch will cause "gfortran" to generate object code compatible with libraries that have been compiled with "g77". You could try, but I don't know if this will also let it use libraries compiled with "g77" together with libraries compiled with "gfortran", I have never done anything like this before.

Or maybe I misunderstood your problem completely? You have three computers on which you try to compile, right?

• X86 RedHat Server (target?): g77 v3.4.6 compile fails with the errors above
• X86 Apple Darwin (local host, the one you use?): g77 v3.4.0 compile also fails with the same errors?

Both of these machines has the MG_ME_V4.4.32 library installed in the path "/usr/local/lib/MG_ME_V4.4.32/pythia-pgs/libraries/PGS4/lib" on both machines?

• "Different" computer: X86? Compiles successfully?

What is the platform, the version of g77, and compile flags you are using on this successful machine? Where is the library installed on this machine?

[drl]

Hi.

Comments and observations:

I wrote a fortran77 program to run on a computing network, but it isn't compiling there.

Are you saying that you intend to run parts of the code on different computers in the network?

I agree with ramin.honary about the compatibility of libraries and applications. You can test this for yourself, and create a basic confidence suite, Acceptance testing - Wikipedia, the free encyclopedia for yourself. I use one of those whenever I update compilers and libraries, or equivalently, when I move to a new platform.

You might also ask the people who did the library installs how they did it, and look at a copy of their test results.

I am certain this is a compiler error, because ...

I'm not an expert, but I have been in the game long enough to know that this is rarely true, and so I usually move along silently without responding to argue the point.

Best wishes ... cheers, drl

[SanguinePenguin]

Thank you again for the replies.

Sorry if I was unclear before. There are only two machines considered. There is no third computer.

• X86 RedHat Server (target): g77 v3.4.6 compile fails with the errors above
• X86 Apple Darwin (local host, the one I usually use): g77 v3.4.0 compiles successfully

Thank you pointing out that the libraries may have been compiled differently, that hadn't occurred to me. Unfortunately, they were all compiled with g77, the only difference is the version of the compilers. I was the one to compile them, simply by running their makefile, which was all part of a pre-existing "accepted" package (of the scientific community). I tried adding all of the additional options (like -fno-second-underscore) that were used in the compilation of the object files, but this didn't change the errors.

In both cases (the successful and flawed compilation), the path (from location of the *.f file) is MG_ME_V4.4.32/pythia-pgs/libraries/PGS4/lib. I didn't put them into the /usr/local/lib/ directory, but I'm almost certain they are correctly linked (otherwise it couldn't have located them at all for this sort of error:

MG_ME_V4.4.32/pythia-pgs/libraries/PGS4/lib/libstdhep.a(stdxwcm1.o): In function `stdxwcm1_':

). I don't think this would cause a problem, but I could be mistaken (I am certainly no expert). It works fine on my machine without them located there. Still, if this was a problem, I don't think I could put them there since I lack root user access.

I don't need to run the code in parallel. The code itself it's terribly computationally intensive, it just needs to be done on extremely large files before piping them into a more computationally intensive process. Due to the size of the files, transferring them to my computer, running the program and transferring the new file back, simply isn't feasible, even if I can't solve this problem.

I am going to look into acceptance testing. This is unfamiliar to me, so it may take some time. As I installed the libraries, I don't believe I recorded any tests. I can always reinstall them, but I need to learn about the testing first.

As always, thank you for your responses. Any further help is appreciated.

[drl]

Hi.

I'm looking at the page http://www.physics.ucdavhttp://www.p...s4-general.htm

Is that where you got the code? ... cheers, drl

[kgore4]

I'd say you're missing the library for
cepa.fnal.gov/psm/simulation/mcfio/

Perhaps there is a problem with the install of MG_ME as it appears to come in that package.
cp3wks05.fynu.ucl.ac.be/cgi-bin/ViewVC/viewvc.cgi/MG_ME/ExRootAnalysis/mcfio/

(I cant post url's so i've stripped the protocol off the front)

edit: a bit more wandering around that cvs repository found
cp3wks05.fynu.ucl.ac.be/cgi-bin/ViewVC/viewvc.cgi/MG_ME/pythia-pgs/libraries/PGS4/src/stdhep-dir/mcfio

which is probably the library its looking for. Is the "F" in "-lFmcfio" supposed to be there?

edit2: after reading the make file, the F is supposed to be there.

Something to try would be see what's in libFmcfio.a with "ar -t"

[ramin.honary]

In both cases (the successful and flawed compilation), the path (from location of the *.f file) is MG_ME_V4.4.32/pythia-pgs/libraries/PGS4/lib. I didn't put them into the /usr/local/lib/ directory, but I'm almost certain they are correctly linked (otherwise it couldn't have located them at all for this sort of error:

MG_ME_V4.4.32/pythia-pgs/libraries/PGS4/lib/libstdhep.a(stdxwcm1.o): In function `stdxwcm1_':

I don't think this would cause a problem, but I could be mistaken (I am certainly no expert). It works fine on my machine without them located there. Still, if this was a problem, I don't think I could put them there since I lack root user access

I see, so when you compile your program on the RedHat server, it gives the errors, even though it is fine compiling on your Mac with an earlier version of g77.

Try using the "-fno-automatic" flag when compiling on the server. You may also need to use this with the "-fno-second-underscore" again, I don't know.

I noticed that you are using statically linked libraries (using ".a" files). It seems the MG_ME_V4.4.32/pythia-pgs/libraries/PGS4/lib is intended to be static linked, not dynamic, but I could be wrong. However, the "g77 -v" command on the server includes "--enable-shared" while your Mac's "g77 -v" does not output this flag. You may need to explicitly specify to the compiler on the server to use static linking, which is what the "-fno-automatic" flag claims to do in the manual. The "g77" installation on the RedHat server is probably using different default compiler flags than your Mac. Even if compiling on your Mac with certain flags is successful, the same flags may cause errors when you compile your program on the server.

I think it is very unlikely to be a compiler fault. This kind of problem is almost always a library compatibility issue. I would also agree with your initial guess about a wrong compiler flag.

Acceptance testing only checks the correctness of the compiler for certain program inputs. I don't think it is likely to help. It can also be very difficult to set the correct compiler flags and environment variables in order to run the tests. Sure, if you could prove to your system administrator with acceptance test results that the RedHat install of g77 were incorrect, you could get them to update the system for you. However, if the tests show no errors with g77 on the server, you have no choice but to continue checking your make flags and environment variables.