/crtbegin.o error ?

Hi:

We recently got a Em64T system and installed PG 5.2-4 on it, when I try to compile a fortran90 code i get the error

“/usr/bin/ld: /crtbegin.o: No such file: No such file or directory”

I copied the crtbegin.o file from the /usr/lib//gcc/x86_64-redhat-linux/3.4.2/32/crtbegin.o to the “/” dir and then I can compile sucessfully, but why is there this problem ? I installed 5.2-4 using the install program accompanying the compiler.

please advise
thanks
-Jay

Hi Jay,

The compiler gets the path to the crtbegin.o file from configuration information found in the “localrc” file. The localrc file can be found in the “bin” directory of your PGI install path. However, given the GCC version you list below, I’m assuming your on a Fedora Core 3 system. Since FC3 came out after 5.2 was released, it is not offically supported by 5.2. You will need to download a patch to get things working correctly. The patch can be found in the “Known Problems” section at the bottom of the 5.2 release information page (http://www.pgroup.com/support/new_rel_52.htm) Download the patch, un-tar it in your PGI directory, and then re-install the compilers.

Hope this helps,
Mat

Mat:

Thanks for your help, I was able to compile without any problems. Are you with Portland Group ? Would you know why isn’t there a direct link to the support page you mention in your answer anywhere on the support site. Also are there any such links for version 6.0-2?

We are having some MPICH/CMAQ4.4 related problems (which we feel is related to 6.0-2) since it works with 5.2-4 without any issues. We will wait for a 6.0-2 update (hopefully there will be one soon :) )

thank you
-Jay

Hi Jay,

I’m with PGI’s application’s group and am one of the biggest users of PGI compilers and tools. I enjoy answering other user’s questions and like to know what issues people are having. While I hope other users will be more active, until then, I’m more than happy to offer any insight I can (hopefully even useful!)

The link to this page can be found through the FAQ page under the “Installation” section’s “What Releases of PGI Compilers work with Each Linux Release” link. Also, information about supported operating systems is included in the compiler’s release notes. The 6.0-2 information can be found in the same location as 5.2-4 as well as under the FAQ’s Installation section’s “What Should I Know About the Latest Release” link.

What problems are you having CMAQ?

Thanks,
Mat

Mat,

Thanks for offer to help.

We are having a problem with MM5 (correction not CMAQ) and MPICH, the cause of the problem seems to be very difficult to figure out.

We were able to compile MM5 on an EM64T cluster but when we try to run it through mpirun, we get a SIGSEGV error in the rs.out files, all it says is that there is a p4_error and that the cause of the error is SIGSEGV, we looked through the pgroup MM5 “tips and techniques” and the recommendation is to use -Mswapbyteio and another flag for SGI systems, also there is a mention of SIGSEGV if the stack size is too low , but the user has resources set to unlimitied.

Additionally we looked through the source code to see if we can figure out the point of error and the error seems to be right after mm5.mpp reads in the input and prints out the sort of input (indicated by the first line in the rs.out file as “*************** ONE DOMAIN ONLY!!! ***************” and the second line is a p4_error: interrupt SIGSEGV: 11)

thanks for any advice you can offer
-Jay

Hi Jay,

We have two reports with a similar issue using a mutli-nested domains, but have not yet been able recreate the problem here. Could you send a report to trs@pgroup.com? I’d like to get a copy of your data, configure.user, mm5.deck and mmlif files. Let Dave know I requested these files and he’ll give you instructions on how to ftp them to us.

Also, could you try a few things? Remove the optimization flags but not the configuration flags (ie remove -fastsse but not -byteswapio), add “-O0”, recompile and re-run. If it succeeds, then we’ve most likely have a compiler bug. If it still seg faults, then it’s most likely a problem with MPICH or MM5.

Either way, I’d still like to try an recreate the issue here. If its a compielr bug, then we need to get it fixed. If it’s something else, then I’d like to find a work around and post the info.

Thanks,
Mat

Hi Mat,

Sorry for delaying the response, but we downgraded the cluster to a 32 bit OS (the system is still Em64t, 64 bit proc) FEDORA Core 2 with all recent updates installed. I tried compiling now with version 5.2 CDK, version 6 and workstation version 5.1.6 (yes we have licenses for all three :) ) but all three result with the message in the rs1.out.0000 file as

*** LOWER BDY CONDITIONS VALID BETWEEN 2005-05-13_00:00 - 2005-05-13_03:00 ARE
READ IN AT TIME = 0.00 MINUTES FOR DOMAIN 1
UPDATING SST FOR DOMAIN 1

and nothing more in the error or output files, I am a systems person and need to talk with some of the reserach folks to understand the message but would you able to provide any clue ? At least the p4_error and SIGSEGV errors have gone.

I have tried your suggestions (removing -fastsse and adding -O0) , we did not have -fastsse but i did add -O0 and tried without any change and hence the reason to downgrade to a 32 bit OS since it is critical to get MM5 running.

Would you still want me to send the the files you request, please let me know.

thanks
-Jay

Hi Jay,

If it can wait till Monday, I’m more than happy to take a look. Since it still exhibits the same behavior at “-O0” and with other versions of the compiler, it’s most likely not a problem with the compiler itself. My suspicion is with MPICH since the p4 error usually occurs because the data transport gets some unexpected data (i.e. 64-bit when it’s expecting 32-bit values). I don’t believe that the fortran interface to MPICH is 64-bit clean and this might be causing your 64-bit problem.

I’d try two things:

  1. Take MPICH out of the equation, build the OpenMP or even serial version of MM5, and try running again. We have a guide to building the OpenMP version of MM5 here if needed.

  2. Compile MM5 and MPICH with “-g” and use pgdbg (the PGI debugger) to determine where and why the program seg faults in 64-bits and halts in 32-bits. They are most likely related. If you don’t have our CDK, I can post the “-dbg” MPICH script needed to lauch pgdbg.

Good Luck!
Mat