justinquinn
Hi Justin:

The Forum doesn't appear to let me upload a *.log or a *.txt file - is there perhaps an email I can send the configure.log to you at?

As for using Python, I am okay with that for now - hopefully an update to MATLAB is released in the not too distant future.

@mathieumorlighem - thanks for the note on gfortran. I'll see if Justin spots anything obvious in the configure.log, otherwise I'll definitely try a different gfortran version.

Thank you both for your help - I appreciate it!

Lawrence

      lawrence-bird

      That is odd indeed. I'll have to look further into this restriction.

      That said, I suspect Mathieu is correct: it is likely due to having a copy of gfortran that is not designed to compile for the M1 target.

          @justinquinn @mathieumorlighem

          Hi Justin/Mathieu:

          Updating gfortran to an experimental ARM version for MacOS Monterey (gfortran 12-experimental for ARM, macOS 12 (Monterey)) did indeed allow me to successfully install PETSc. That said, I was able to install all external packages.

          Moving on to the next step, ISSM appears to configure successfully, but is failing during make. I am receiving the following error:

          ld: file not found: @rpath/libgcc_s.1.1.dylib for architecture arm64
          clang: error: linker command failed with exit code 1 (use -v to see invocation)

          It seems to be something to do with gcc; however, when I interrogate the gcc version on my system (below), it looks like there is a gcc version suitable for arm64:

          $ which gcc
          /usr/bin/gcc

          $ file /usr/bin/gcc
          /usr/bin/gcc: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64e:Mach-O 64-bit executable arm64e]
          /usr/bin/gcc (for architecture x86_64): Mach-O 64-bit executable x86_64
          /usr/bin/gcc (for architecture arm64e): Mach-O 64-bit executable arm64e

          $ gcc --version
          Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
          Apple clang version 13.0.0 (clang-1300.0.29.30)
          Target: arm64-apple-darwin21.2.0
          Thread model: posix
          InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

          If you have any ideas on this, I'm all ears!

          Thanks.

          Lawrence

            lawrence-bird Okay, you may have to,

            export LD_LIBRARY_PATH=/usr/local/gfortran/lib:${LD_LIBRARY_PATH}
export DYLD_LIBRARY_PATH=/usr/local/gfortran/lib:${DYLD_LIBRARY_PATH}

            in your shell profile (the above assumes bash). You may be able to test this ahead of time by exporting (or otherwise setting these environment variables) directly in the terminal instance and recompiling.

                justinquinn

                Hi Justin - I implemented this, but the same error persists, unfortunately. I assume this would not affect the external package installations and I don't need to recompile those?

                    justinquinn

                    I am not sure if it's relevant where this error is occurring during the make process, but this is the full error:

                    ld: file not found: @rpath/libgcc_s.1.1.dylib for architecture arm64
                    clang: error: linker command failed with exit code 1 (use -v to see invocation)
                    make[3]: *** [libISSMCore.la] Error 1
                    make[2]: *** [all-recursive] Error 1
                    make[1]: *** [all-recursive] Error 1
                    make: *** [all] Error 2

                    This is preceded by a number of warnings similar to this:

                    *** Warning: Linking the shared library libISSMCore.la against the
                    *** static library /Users/lbir0005/ISSM/trunk/externalpackages/m1qn3/install/libddot.a is not portable!
                    ld: warning: object file (./modules/FourierLoveCorex/.libs/lnb_param.o) was built for newer macOS version (12.1) than being linked (12.0)

                        justinquinn

                        Here's the full output once things start going awry:

                        *** Warning: Linking the shared library libISSMCore.la against the
                        *** static library /Users/lbir0005/ISSM/trunk/externalpackages/m1qn3/install/libm1qn3.a is not portable!
                        *** Warning: Linking the shared library libISSMCore.la against the
                        *** static library /Users/lbir0005/ISSM/trunk/externalpackages/m1qn3/install/libddot.a is not portable!
                        ld: warning: object file (./modules/FourierLoveCorex/.libs/lnb_param.o) was built for newer macOS version (12.1) than being linked (12.0)
                        ld: warning: object file (./modules/FourierLoveCorex/.libs/model.o) was built for newer macOS version (12.1) than being linked (12.0)
                        ld: warning: object file (./modules/FourierLoveCorex/.libs/util.o) was built for newer macOS version (12.1) than being linked (12.0)
                        ld: warning: could not create compact unwind for ___model_MOD_earth_nlayers: register 28 saved somewhere other than in frame
                        ld: warning: could not create compact unwind for ___model_MOD_earth_nlayers_viscoelas: register 75 saved somewhere other than in frame
                        ld: warning: could not create compact unwind for ___model_MOD_model_init2: register 73 saved somewhere other than in frame
                        ld: warning: object file (./modules/FourierLoveCorex/.libs/lovenb_sub.o) was built for newer macOS version (12.1) than being linked (12.0)
                        ld: warning: could not create compact unwind for ___lovenb_sub_MOD_solution_nbloutput: registers 78 and 79 not saved contiguously in frame
                        ld: warning: could not create compact unwind for ___util_MOD_ludcmp: register 24 saved somewhere other than in frame
                        ld: warning: ld: warning: could not create compact unwind for ___util_MOD_derivs: registers 78 and 79 not saved contiguously in frameld: warning: could not create compact unwind for ___lovenb_sub_MOD_solution: registers 78 and 79 not saved contiguously in frameld: warning: object file (./modules/GiaDeflectionCorex/.libs/libISSMCore_la-ojrule.o) was built for newer macOS version (12.1) than being linked (12.0)ld: warning:
                        object file (./modules/GiaDeflectionCorex/.libs/libISSMCore_la-freed.o) was built for newer macOS version (12.1) than being linked (12.0)
                        ld: warning: ld: warning: object file (./modules/GiaDeflectionCorex/.libs/libISSMCore_la-distme.o) was built for newer macOS version (12.1) than being linked (12.0)
                        object file (./modules/FourierLoveCorex/.libs/love_numbers.o) was built for newer macOS version (12.1) than being linked (12.0)
                        ld: warning: object file (./modules/GiaDeflectionCorex/.libs/libISSMCore_la-pwise.o) was built for newer macOS version (12.1) than being linked (12.0)
                        object file (./modules/GiaDeflectionCorex/.libs/libISSMCore_la-qwise.o) was built for newer macOS version (12.1) than being linked (12.0)ld: warning:
                        ld: warning: object file (./modules/GiaDeflectionCorex/.libs/libISSMCore_la-what0.o) was built for newer macOS version (12.1) than being linked (12.0)
                        ld: warning: could not create compact unwind for _what0_: registers 78 and 79 not saved contiguously in frame
                        ld: warning: could not create compact unwind for ___lovenb_sub_MOD_boundary_conditions_matrix: register 77 saved somewhere other than in frame
                        ld: warning: object file (./modules/GiaDeflectionCorex/.libs/libISSMCore_la-stot.o) was built for newer macOS version (12.1) than being linked (12.0)
                        ld: warning: could not create compact unwind for _stot_: registers 72 and 73 not saved contiguously in frame
                        could not create compact unwind for _love_numbers_: registers 27 and 28 not saved contiguously in frame
                        ld: warning: could not create compact unwind for _lnb_setup_: registers 27 and 28 not saved contiguously in frame
                        ld: warning: could not create compact unwind for _distme_: register 75 saved somewhere other than in frame
                        ld: warning: dylib (/Users/lbir0005/ISSM/trunk/externalpackages/petsc/install/lib/libmpifort.dylib) was built for newer macOS version (12.1) than being linked (12.0)
                        ld: warning: dylib (/usr/local/gfortran/lib/gcc/aarch64-apple-darwin21/12.0.0/../../..//libgfortran.5.dylib) was built for newer macOS version (12.1) than being linked (12.0)
                        ld: warning: dylib (/usr/local/gfortran/lib/gcc/aarch64-apple-darwin21/12.0.0/../../..//libquadmath.0.dylib) was built for newer macOS version (12.1) than being linked (12.0)
                        ld: file not found: @rpath/libgcc_s.1.1.dylib for architecture arm64
                        clang: error: linker command failed with exit code 1 (use -v to see invocation)
                        make[3]: *** [libISSMCore.la] Error 1
                        make[2]: *** [all-recursive] Error 1
                        make[1]: *** [all-recursive] Error 1
                        make: *** [all] Error 2

                            lawrence-bird
                            Hi Lawrence,
                            The warnings may look alarming but do not indicate an actual failure. I think what might be going on is that the binaries of the this copy of gfortran are functional but the /usr/local/gfortran/lib/libgcc_s.1.1.dylib may not be compiled with ARM as the target. To be perfectly honest, I don't know what is trying to linke against libgcc_s. What do you get from ldd /usr/local/bin/gfortran? Also, what does your configuration look like?

                                justinquinn

                                Hi Justin:

                                ldd doesn't appear to work (I'm not sure if it's all Mac's or just these new systems), but apparently otool -L is the equivalent. Output from this:

                                $ otool -L /usr/local/bin/gfortran
                                /usr/local/bin/gfortran:
                                /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
                                /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1311.0.0)

                                Perhaps I will try rolling back my gfortran version to the one listed by Mathieu and see if that works on Monterey (as well as it's intended MacOS 11).

                                    lawrence-bird
                                    Right, ldd aliases to otool-classic in my case.

                                    Okay, the output looks the same as mine. You might try running down the dependency trail by running otool -L on each of the libraries that are listed to see if they, in turn, load libgcc_s.1.1.dylib. That said, I suspect it is something else that is linking to this library. It may, after all, be one of the external package libraries, so you may have to check those too with otool.

                                    Try rolling back your gfortran version though first and let's see if that resolves it.

                                        justinquinn

                                        Hi Justin:

                                        Rolling back the gfortran version didn't resolve the issue. I've also dug around the external packages using otool -L and can't find any of those that link to libgcc_s.1.1.dylib.

                                        The only thing that I notice in the config.log file is a "fatal error" that occurs a few times, although it dosesn't result in the configure process failing:

                                        configure:3883: checking how to run the C preprocessor
                                        configure:3914: gcc -E conftest.c
                                        configure:3914: $? = 0
                                        configure:3928: gcc -E conftest.c
                                        conftest.c:9:10: fatal error: 'ac_nonexistent.h' file not found
                                        #include <ac_nonexistent.h>
                                        ^~~~~~~~~~~~~~~~~~
                                        1 error generated.
                                        configure:3928: $? = 1
                                        configure: failed program was:
                                        | /* confdefs.h */
                                        | #define PACKAGE_NAME "Ice Sheet System Model (ISSM)"
                                        | #define PACKAGE_TARNAME "issm"
                                        | #define PACKAGE_VERSION "4.19"
                                        | #define PACKAGE_STRING "Ice Sheet System Model (ISSM) 4.19"
                                        | #define PACKAGE_BUGREPORT "issm@jpl.nasa.gov"
                                        | #define PACKAGE_URL "http://issm.jpl.nasa.gov"
                                        | /* end confdefs.h. */
                                        | #include <ac_nonexistent.h>

                                        I don't think this is related, but thought I would share it in case it sheds any light on anything.

                                        Thanks.

                                        Lawrence

                                            lawrence-bird
                                            Hi Lawrence,
                                            I'm sorry, I'm running out of ideas on what might be the issue here. It's really hard for me to test on my end without access to an M1 machine. Are you getting the same error as before with the rolled back copy of gfortran?

                                            I can confirm that the fatal errors in the config.log are not an issue:

                                            $ grep "fatal error" config.log 
config.log:155:conftest.c:9:10: fatal error: 'ac_nonexistent.h' file not found
config.log:174:conftest.c:9:10: fatal error: 'ac_nonexistent.h' file not found
config.log:256:gfortran: fatal error: no input files
config.log:261:gfortran: fatal error: no input files
config.log:297:gfortran: fatal error: no input files
config.log:302:gfortran: fatal error: no input files
config.log:545:conftest.cpp:23:10: fatal error: 'ac_nonexistent.h' file not found
config.log:578:conftest.cpp:23:10: fatal error: 'ac_nonexistent.h' file not found

                                            That's from a successful config and compilation.

                                                justinquinn
                                                Hi Justin:

                                                No worries - this is a strange one.

                                                I m happy to report that I was able to get ISSM to compile! But I've now got a new issue. On the compilation front, this was my process:

                                                • Grabbed a clean version from the trunk
                                                • Downloaded the gfortran 11-experimental-2 for ARM Big Sur (macOS 11) version Mathieu noted above
                                                • Installed all external packages (noting the updated to LIBTOOL_VER=2.46 for autotools
                                                • Ran autoreconf -ivf at $ISSM_DIR
                                                • Installed numpy / scipy using homebrew
                                                • Installed pyenv using homebrew (to allow me to get a dev copy of Python)
                                                • Installed python 3.9-dev using pyenv
                                                • Specified the --with-fortran-lib in the configure script to point to the location of gfortran that I'd downloaded. This step was important as another gcc version is installed using homebrew as a dependancy for numpy. Without specifying the fortran location, it would try and use the gcc location in homebrew (based, I presume, on it's location in the $PATH), and it would fail. Interestingly, the gcc version downloaded as a dependancy for numpy is that same version I was originally trying (for Monterey).
                                                • Specified the python directory (in pyenv) and the python version (3.9) in the configure script.
                                                • ./configure
                                                • make
                                                • make install

                                                This appears to result in a successful compilation!

                                                However, when I try and run the model via Python, I am returned a Segmentation fault: 11. After launching Python, I am entering the following (before be returned the seg fault):

                                                import sys
                                                sys.path.append('/Users/lbir0005/ISSM/trunk/bin/')
                                                sys.path.append('/Users/lbir0005/ISSM/trunk/lib/')
                                                from issmversion import issmversion

                                                I was able to successfully build ISSM with Matlab on a different machine that I am waiting to get remote access right for.

                                                At this point, I am just being stubborn about trying to get it working on my laptop with Python.

                                                Cheers,

                                                Lawrence