Can you compile and run code with your compiler 'gfortran'?ĭo you have any knowledge of the use of and how I might be able to overcome this linking issue? I'm wondering if there is another flag that can be included in the configure/make step (probably needed for the PETSc build itself) that can specify what/where refers to? My suspicion/fear is that this all needs to happen during the build of gfortran though □.Īpologies if this all appears way out-to-lunch - I'm definitely out of my depth here and have just been sleuthing the internet for potential clues.īoth of the gfortran versions work out of the box. Otherwise there is problem with the compilers. configure with the additional option -with-batch. To submit jobs you will need to configure using. When trying to re-install PETSc using this brute-forced change, PETSc fails with the following error:Ĭannot run executables created with FC. While this worked to return absolute paths when running otool -L libgfortran.dylib, it broke the gfortran build (probably not unsurprisingly!). I tried using the install_name_tool to force the to be an absolute path. usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1311.0.0) Running otool -L libgfortran.dylib on the updated gfortran version (where make is unsuccessful) (compatibility version 6.0.0, current version (compatibility version 1.0.0, current version (compatibility version 1.0.0, current version 1.1.0) usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.60.1) usr/local/gfortran/lib/libgcc_s.2.dylib (compatibility version 2.0.0, current version 2.0.0) usr/local/gfortran/lib/libgfortran.5.dylib (compatibility version 6.0.0, current version 6.0.0) For example, running otool -L libgfortran.dylib on the original gfortran version returns: In the original gfortran version (where make is successful), the linked libraries appear to use absolute paths, and not the call. I think it's the use of here that's the issue. I chased down that the libgfortran.dylib is linked to the libgcc_s.1.1.dylib, so I suspect this is where the issue arises. Using this gfortran version, all external packages install successfully, but when running make, I get the pesky ld: file not found: for architecture arm64 error. The inversion issue remained.įollowing this, I grabbed the different experimental gfortran version ( here) built intentionally for Monterey on ARM machines. I updated the package versions called in the ISSM external package installation scripts, and was able to return another successful build using this same gfortan version. To try and rectify this, I have been attempting a new build with updates to everything. This issue looks to stem from the PETSc install. Using the ISSM external package install scripts, I've been able to successfully build and run ISSM using the gfortran version here (based on initial recommendation from However, this build is where I ran into issue with the inversion. Apologies for the longwinded post, but I wanted to document this progress. Hi keep tinkering with this in the hope that it will be useful to me, or someone else! I think I've narrowed down the issue (at least a little).
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |