R and M1 install issues

Installation Issues
1

Hi experts

I'm working with a collaborator who needs to run 3dLME(r) on their M1 laptop and is having R issues. This issue seems similar to this recent thread but I didn't want to hijack someone else's conversation.

when my collaborator runs rPkgsInstall -pkgs ALL -check they get:

updating R_LD_LIBRARY_PATH ...

oo Warning:
Failed to load R_io.so with this error message:

Error in dyn.load(ll) :
unable to load shared object '/Users/irinastrigo/abin/R_io.so':
dlopen(/Users/irinastrigo/abin/R_io.so, 0x0006): tried: '/Users/irinastrigo/abin/R_io.so' (mach-o file, but is an incompatible architecture (have 'x86_64', need 'arm64')), '/System/Volumes/Preboot/Cryptexes/OS/Users/irinastrigo/abin/R_io.so' (no such file), '/Users/irinastrigo/abin/R_io.so' (mach-o file, but is an incompatible architecture (have 'x86_64', need 'arm64'))
Calls: source ... withVisible -> eval -> eval -> set_R_io -> dyn.load
Execution halted

And when they run afni_system_check.py -check_all they get:
-------------------------------- general ---------------------------------
architecture: 64bit
cpu type: arm
system: Darwin
release: 22.5.0
version: Darwin Kernel Version 22.5.0: Thu Jun 8 22:22:20 PDT 2023; root:xnu-8796.121.3~7/RELEASE_ARM64_T6000
distribution: 13.4.1
number of CPUs: 10
apparent login shell: zsh
shell RC file: .zshrc (exists)

--------------------- AFNI and related program tests ---------------------
which afni : /Users/irinastrigo/abin/afni
afni version : Precompiled binary macos_10.12_local: Feb 13 2023
: AFNI_23.0.04 'Commodus'
AFNI_version.txt : AFNI_23.0.04, macos_10.12_local, Feb 13 2023
which python : /opt/homebrew/opt/python/libexec/bin/python
python version : 3.11.4
which R : /usr/local/bin/R
R version : R version 4.2.2 (2022-10-31) -- "Innocent and Trusting"
which tcsh : /bin/tcsh

instances of various programs found in PATH:
afni : 1 (/Users/irinastrigo/abin/afni)
R : 1 (/Library/Frameworks/R.framework/Versions/4.2-arm64/Resources/bin/R)
python : 1 (/opt/homebrew/Cellar/python@3.11/3.11.4_1/Frameworks/Python.framework/Versions/3.11/bin/python3.11)
python2 : 0
python3 : 2
/opt/homebrew/Cellar/python@3.11/3.11.4_1/Frameworks/Python.framework/Versions/3.11/bin/python3.11
/usr/bin/python3

** have python3 but not python2

testing ability to start various programs...
afni : success
suma : success
3dSkullStrip : success
uber_subject.py : success
3dAllineate : success
3dRSFC : success
SurfMesh : success
3dClustSim : success
3dMVM : FAILURE
Error in dyn.load(ll) :
unable to load shared object '/Users/irinastrigo/abin/R_io.so':
dlopen(/Users/irinastrigo/abin/R_io.so, 0x0006): tried: '/Users/irinastrigo/abin/R_io.so' (mach-o file, but is an incompatible architecture (have 'x86_64', need 'arm64')), '/System/Volumes/Preboot/Cryptexes/OS/Users/irinastrigo/abin/R_io.so' (no such file), '/Users/irinastrigo/abin/R_io.so' (mach-o file, but is an incompatible architecture (have 'x86_64', need 'arm64'))
Calls: source ... withVisible -> eval -> eval -> set_R_io -> dyn.load
Execution halted

checking for R packages...
rPkgsInstall -pkgs ALL -check : success

R RHOME : /Library/Frameworks/R.framework/Resources

checking for $HOME files...
.afnirc : found
.sumarc : found
.afni/help/all_progs.COMP : found

------------------------------ python libs -------------------------------
** failed to load module PyQt4
-- PyQt4 is no longer needed for an AFNI bootcamp

** failed to load module matplotlib.pyplot
-- matplotlib.pyplot is required

-------------------------------- env vars --------------------------------
PATH = /opt/homebrew/bin:/opt/homebrew/sbin:/usr/local/bin:/System/Cryptexes/App/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin:/opt/homebrew/opt/python/libexec/bin:/Library/Frameworks/R.framework/Resources:/usr/local/gfortran/bin:/Users/irinastrigo/abin

PYTHONPATH =
R_LIBS =
LD_LIBRARY_PATH =
DYLD_LIBRARY_PATH =
DYLD_FALLBACK_LIBRARY_PATH =

----------------------------- eval dot files -----------------------------

-- good: .tcshrc seems to contain 'source .cshrc'
-- considered opertaions: path, flatdir, apsearch

-- note: followers should not need edits, so edit flags should be 0
(have 1 follower(s), which can be ignored)

dot file test : want 1 modifications across 3 files:

  file             path  flatdir  apsearch        follower
  ---------------  ----  -------  --------        --------
  .cshrc           0     0        1               0     
  .tcshrc          0     0        0               1     
  .zshrc           0     0        0               0

------------------------------ data checks -------------------------------
data dir : missing AFNI_data6
data dir : missing AFNI_demos
data dir : missing suma_demo
data dir : missing afni_handouts
atlas : found TT_N27+tlrc under /Users/irinastrigo/abin

------------------------------ OS specific -------------------------------
XQuartz version : 2.8.5

which brew : /opt/homebrew/bin/brew
brew version : Homebrew 4.0.28

-- for PyQt4 under brew, consider running:
brew install cartr/qt4/pyqt
++ found 1 dylib files under '/opt/X11/lib/flat_namespace'
-- found 'libXt' dylib files:
/opt/X11/lib/flat_namespace/libXt.6.dylib
** env var DYLD_LIBRARY_PATH is not set to contain /opt/X11/lib/flat_namespace
(so afni and suma may fail)

========================= summary, please fix: =========================

  • just be aware: login shell 'zsh', but our code examples use 'tcsh'
  • AFNI programs show FAILURE
  • python library matplotlib is required
    (see AFNI install docs for details)
  • dot file test : want 1 modifications across 3 files:
  • insufficient data for AFNI bootcamp
    (see "Prepare for Bootcamp" on install pages)
  • OS X version might be old
  • consider setting DYLD_LIBRARY_PATH to /opt/X11/lib/flat_namespace

Are their only options to build AFNI for their M1s or to downgrade R to an earlier version?
The former could be too involved and the latter worries them that other things will break.
Thoughts? thank you so much!

-Sam

2

Hi Sam-

I would recommend installing the newest R and then building from source.

git clone https://github.com/afni/afni.git

You can follow some of the instructions in the macOS 13 Makefile: https://github.com/afni/afni/blob/master/src/other_builds/Makefile.macos_13_ARM_clang

You might need to change one line in the linking to match the version of netpbm that gets installed (i.e. replace the 10.86.33 with whatever version it installs for you):

sudo ln -s /opt/homebrew/Cellar/netpbm/10.86.33/include/netpbm/pgm.h \
 /opt/homebrew/include/pgm.h

After the home-brew installation finishes:

cd afni/src
cp other_builds/Makefile.macos_13_ARM_clang ./Makefile
make vastness
3

thanks Peter! and you'd recommend this approach over using build_afni.py ?

4

build_afni.py wasn't cooperating on my M1 earlier which could be due to a variety of internet issues. But I did just test build on the current macOS_13 makefile and it ran well and built against the newest version of R.

1 Like
5

The newest versions of R (4.2.3 and 4.3.1) are both having problems (some R programs work, some do not). This seems to be something that might need to be resolved by the R community, it is early to be sure. But problems with our R programs should be reported.

The setup and compile steps that work well are shown in:

afni crash after building binaries - #4 by rickr]

I am not aware of any issues with build_afni.py. One can specify that alternate makefile as an option if desired. But that would presumably correspond to different setup instructions. I suggest starting with what we have posted.

  • rick
1 Like
6

@rickr can you let us know which R programs? I noticed some hiccups with 3dLME on biowulf but can run them locally just fine.

7

Sorry @pmolfese, but I am out of town and will not have access to that system for a while. It looked like different issues for 4.3.1 vs 4.2.3, but it is possible that they actually affected the same stats programs, with errors just being reported differently. Maybe @Gang knows the state of things.

  • rick
8

Ah the issue is the main afni server being out of commission. The build_afni.py script cannot download the atlas package from there. One work around is to use the git repo as a fallback.

9

@pmolfese thanks for the update, this clarifies things. i was just working on my colleagues computer, following the 2 text files that Rick points to in his comment above (in https://github.com/afni/afni/tree/master/src/other_builds) and in the 2nd file " OS_notes.macos_12_x86_64_b_user.txt" kept encountering an error at this line:

username@SFC-RL3731M ~ % tcsh @update.afni.binaries -no_recur -package anyos_text_atlas -bindir $HOME/abin
DOCTYPE: Event not found.

(which is happening because of the main afni server?)

which subsequently also breaks:

build_afni.py -build_root $HOME/afni_build -package macos_13_ARM_clang
** error: option -package follows unknown arg #1 (-build_root)
** error: failed to process options...

so i guess we wait for the server to return? this doesn't have to be solved on their machine immediately

11

Hi, @storrisi -

Can you give it a try now, with standard instructions? I think the subset of files are currently available.

--pt

12

@storrisi, note that your build_afni.py -build_root command is indeed likely failing because of the failed @update.afni.binaries, because you do not have the current build_afni.py program.

And this command still fails with a Forbidden error:

@update.afni.binaries -no_recur -package anyos_text_atlas -bindir $HOME/abin.atlas

However, it should be possible to omit the test of pub/dist/bin and go straight to tgz using:

curl -O https://afni.nimh.nih.gov/pub/dist/tgz/anyos_text_atlas.tgz
@update.afni.binaries -no_recur -local_package anyos_text_atlas.tgz -bindir ~/abin

But they should be able to fix the Forbidden problem on the pub/dist/bin directory, so you could wait for that.
Either way, at that point you should be able to continue with init_user_dotfiles.py and build_afni.py.

  • rick
13

thanks so much everyone. i was able to zoom again with the collaborator but am sorry to report i can't get past @update.afni.binaries

if i type:
tcsh @update.afni.binaries -no_recur -package anyos_text_atlas -bindir $HOME/abin
i get:
DOCTYPE: Event not found.

everything i'm finding online about the "DOCTYPE..." error points to shells and syntax, but i've tried executing in all 3 shells and other related tricks. could someone explain that error in this context?

i also tried the curl command Rick provided and successfully downloaded anyos_text_atlas.tgz, but after changing the option to "-local_package" it still breaks

note that there's already a @update.afni.binaries script in the home directory with yesterday's date so must be something i downloaded during yesterday's set of commands. if i try to read it in 'vi' it begins with html-type syntax so i'm confused about that. but if i modify the above @update.afni..... to point to the normal @update.afni.binaries script already in ~/abin then it appears to start to run but errors out with:

"set: Variable name must begin with a letter"

any ideas? i'm mostly in zsh because of the instructions at the top of scriptA on github, but like i said i've tried other shells too. once again i apologize for all this

14

Hi, Sam-

Don't apologize! But I'm a bit puzzled.

Firstly, I would get rid of the "html-type syntax" @update.afni.binaries file in your home dir---that must be a bad download.

I wonder if there is a partial/broken download somewhere. I would probably remove the "old" abin from yesterday, and even the current @update.afni.binaries.

Your current shell shouldn't really matter to the script execution, unless some weird alias/path thing is happening (but I doubt that is the case here).

-pt

15

Alright, the solution to this has been determined:

  • to the first part, wtih the DOCTYPE and html-like contents of the text file: this was caused by the fact that when @update.afni.binaries was downloaded, the server was actually down, and (confusingly) the file still gets curled and created on the computer, but its contents are just the "Forbidden ..." error message that would appear in the browser when trying to access and unaccessible file.

    • so, we purged that bad file, and re-downloaded a good one.

  • For the "seg: Variable name ..." issue: there was a pre-existing AFNI installation on the computer, and an alias for 'afni' had been created as part of that earlier setup; this created a hiccup when the @update.afni.binaries script tried to use the results of `which afni` to find the path to the afni program---in tcsh, it gave a space separated output about the alias existing.

    • so, we found all instances of aliasing 'afni', and opened a new terminal, and then we could run the normal tcsh @update.afni.binaries ... command as expected.

Rockin'.

--pt

1 Like
16

thanks again a trillion billion, Paul