Install fails on MacOS X, linker error: Symbol not found: __gfortran_pow_r8_i4

13 posts / 0 new
Offline
Joined: 03/10/2013 - 07:38
Install fails on MacOS X, linker error: Symbol not found: __gfortran_pow_r8_i4

I'm on a Mid-2009 MacBook Pro, Latest Mountain Lion, MacPorts GNU compilers and R 2.15.3.

These are the last relevant error message lines:

Error in dyn.load(file, DLLpath = DLLpath, ...) :
unable to load shared object '/opt/local/Library/Frameworks/R.framework/Versions/2.15/Resources/library/OpenMx/libs/x86_64/OpenMx.so':
Referenced from: /opt/local/Library/Frameworks/R.framework/Versions/2.15/Resources/library/OpenMx/libs/x86_64/OpenMx.so
Expected in: dynamic lookup

Execution halted
* removing ‘/opt/local/Library/Frameworks/R.framework/Versions/2.15/Resources/library/OpenMx’

According to a Google search, this error message is a) rare and b) is caused by __gfortran_pow_r8_i4 having been removed from recent versions of gfortran.

Any and all pointers to solutions appreciated. Thank you.

Offline
Joined: 05/24/2012 - 00:35
__gfortran_pow_r8_i4

Yeah, this is a known problem. If you can try recompiling with libnpsol.a from SVN 177, I bet that will work.

http://people.virginia.edu/~jnp3bc/libnpsol-svn177.a

Offline
Joined: 03/10/2013 - 07:38
Seems we're not on quite the same architecture:

Seems we're not on quite the same architecture:

sudo R CMD INSTALL -i ~/OpenMx
...

ld: warning: ignoring file ../inst/npsol/osx/libnpsol.a, file was built for archive which is not the architecture being linked (x86_64): ../inst/npsol/osx/libnpsol.a

I'm on a 64-bit Mac, don't know if that is significant. I'm also not overly confident that I'm doing this right.

Offline
Joined: 05/24/2012 - 00:35
npsol

We have a developer working on replacing npsol with an open source optimizer. Long-term, that will be the best solution.

If you are willing to recompile npsol for your architecture, please join https://lists.virginia.edu/sympa/info/openmx-developers

Sorry I don't have better news.

Offline
Joined: 04/16/2013 - 14:03
I just replied above in this

I just replied above in this thread, but I wanted to attach here too. Can the person doing this refactor handle the following challenge:

• roll back npsol and F77 to a version that will compile OpenMX on a 64-bit mac
• tweak the makefile to build a statically linked binary
• package that up for redistribution on the website
• or, even better, adapt the installation process to pull the static binary if it is installing on OS X

I cannot do this right now. However, whoever is refactoring npsol probably has the knowledge to perform this task.

Thanks,
Ian

Offline
Joined: 07/31/2009 - 15:14
No problems with 64bit mac

Hi

I resolved the earlier compilation problems with R2.15. Essentially I was having trouble with too many gcc's installed. Cleaning them all out and using fresh xcode install solved the issue. Gfortran works fine. One trick I found was that R on the command line should point to R64, per the end bit of the wiki for developer.

If you are not a developer, the binary install should work fine for a 64 bit install (parallel or not)
source("http://openmx.psyc.virginia.edu/getOpenMx.R")

And... replacement for npsol is on its way!

Offline
Joined: 04/16/2013 - 14:03
no dice with gcc 4.7

Hi Neale,

Thanks for checking into this. I've tried the developer instructions, including the patched npsol from subversion. The core issue is with gfortran; my version is too new:

gfortran --version
GNU Fortran (GCC) 4.7.2
Copyright (C) 2012 Free Software Foundation, Inc.

Please see the following; npsol has probably been broken in some way since gcc 4.3 (i.e. gfortran 4.2 may be the last version that worked):

http://gcc.gnu.org/ml/fortran/2009-05/msg00404.html

I was at the APS conference over the weekend and I spoke with several members of the OpenMX team. I am trying to build OpenMx using an older version of fortran. So far, so good, but I do not have a full version building yet. You can track my progress here:

https://github.com/iandennismiller/openmx-osx

Also, I am a little confused here... It really looks like there is a pre-compiled binary distro already available:

http://openmx.psyc.virginia.edu/packages/bin/macosx/universal/contrib/2.15/

However, that appears to be broken too. First off, it does not install using the following process because the suffix is .tgz instead of .tar.gz:

install.packages(pkgs=c('OpenMx'), contriburl='http://openmx.psyc.virginia.edu/packages/bin/macosx/universal/contrib/2.15')

Then, using my own mirror (with a correctly named tarball) to install it like so:

install.packages(pkgs=c('OpenMx'), contriburl='http://imiller.utsc.utoronto.ca/p/OpenMx')

I receive the following error:

Error: package ‘OpenMx’ was built for universal-apple-darwin9.8.0

...so I still believe that if somebody (maybe you) can just build and statically link the thing on a modern OS X system, then make the correctly named tarball (.tar.gz, apparently) available via http://openmx.psyc.virginia.edu/packages/bin/macosx/universal/contrib/2.15, I could possibly install OpenMx without having to build an old version of gcc in order to compile it.

Offline
Joined: 07/31/2009 - 15:14
Works for me on 4.8.1

I have:

new-host% gfortran --version
GNU Fortran (GCC) 4.8.1 20130404 (prerelease)
Copyright (C) 2013 Free Software Foundation, Inc.

Which version of R are you using? What does
which R return, and what does that point to? I had to go through a few steps to see where it was eventually headed, for which purpose I used a few doses of awk (seems clumsy but piping things into ls doesn't work)

 which R | awk '{print "ls -lF",$0}' | csh | awk '{print "ls -lF",$NF}' | csh

on my system I got
new-host% which R | awk '{print "ls -lF",$0}' | csh | awk '{print "ls -lF",$NF}' | csh
lrwxr-xr-x 1 root admin 3 May 27 08:22 /Library/Frameworks/R.framework/Resources/bin/R@ -> R64

and it works fine.

I don't think that static linking is an option - and I don't think it's needed.

Offline
Joined: 07/31/2009 - 14:25

Fresh OS X 10.10.1 install on a mid-2014 Macbook pro, with R 3.1.2 Pumpkin Helmet (Mavericks) installed plus the Simon Urbanek gfortran 4.8.2 used to compile R for Mavericks, I can compile OpenMx 2 but installing it fails

** testing if installed package can be loaded
Error in dyn.load(file, DLLpath = DLLpath, ...) :
unable to load shared object '/Library/Frameworks/R.framework/Versions/3.1/Resources/library/OpenMx/libs/OpenMx.so':
Referenced from: /Library/Frameworks/R.framework/Versions/3.1/Resources/library/OpenMx/libs/OpenMx.so
Expected in: dynamic lookup

Error: loading failed

Qeb search suggests that the culprit symbol embedded in NPSOL may reflect compilation using Fortran 4.4 or older and no longer supported? e.g.

http://marc.info/?l=gcc-fortran&m=136205999713783

Offline
Joined: 04/16/2013 - 14:03
results of compilation

I tried compiling openmx using the npsol library you provided, but I have run into a separate (but probably related) linker problem:

** testing if installed package can be loaded
Error in dyn.load(file, DLLpath = DLLpath, ...) :
unable to load shared object '/Users/idm/Library/R/Versions/2.15/OpenMx/libs/OpenMx.so':
Referenced from: /Users/idm/Library/R/Versions/2.15/OpenMx/libs/OpenMx.so
Expected in: dynamic lookup

It appears npoptn might be something else related to F77 and npsol?

At any rate, it sounds like OpenMX is broken on OS X. Is there any possible workaround, like a statically linked version or an older version, or maybe instructions for using a suitable fortran compiler? Any help would be appreciated.

In the meanwhile, Linux is still working, so I'm still going to get all my work done on time. However, I'm eager to know if I can do this on OS X.

Thanks!

Offline
Joined: 07/31/2009 - 15:14
Is this R 2.15 problem
1. I don't have any problem compiling OpenMx on my macbook pro early 2011, under Mountain Lion and R 2.14.2

2. It is the case that npoptn is part of npsol.

3. You can of course run OpenMx on OSX simply by downloading and installing the binary. It seems that it is only compiling that seems to be broken, and perhaps only on R 2.15, and even then maybe it is something to do with the compiler version.

Offline
Joined: 07/31/2009 - 15:14
R 2.15 problem with make install

Building OpenMx from source did break when I upgraded to R 2.15. It seems that gcc 4.6.3 doesn't like -arch arguments any more, but I don't know how to get rid of them. Any ideas?

new-host-4% sudo make install
rm -rf build/*
mkdir -p build
cp DESCRIPTION DESCRIPTION.bak
sed '/Version:/d' DESCRIPTION.bak > DESCRIPTION
echo "Version: "999.0.0"-"2465 >> DESCRIPTION
cd build; R CMD build ..

Welcome to R on Mike Neale's Macbook!

• checking for file ‘../DESCRIPTION’ ... OK
• preparing ‘OpenMx’:
• checking DESCRIPTION meta-information ... OK
• cleaning src
• checking for LF line-endings in source and make files
• checking for empty or unneeded directories
Removed empty directory ‘OpenMx/docs/source/static/Rdoc’
Removed empty directory ‘OpenMx/docs/source/static/demo’
Removed empty directory ‘OpenMx/docs/source/static’
Removed empty directory ‘OpenMx/docs/source/templates’
Removed empty directory ‘OpenMx/inst/unit-tests’
Removed empty directory ‘OpenMx/models/failing/temp-files’
Removed empty directory ‘OpenMx/testsuite’
• looking to see if a ‘data/datalist’ file should be added
• re-saving tabular files
• building ‘OpenMx_999.0.0-2465.tar.gz’

mv DESCRIPTION.bak DESCRIPTION
rm -f man/genericFitDependencies.Rd man/imxAddDependency.Rd man/MxAlgebraFunction.Rd \
man/omxCheckCloseEnough.Rd
cd build; R CMD INSTALL "--configure-args=--enable-openmp" OpenMx_999.0.0-2465.tar.gz

Welcome to R on Mike Neale's Macbook!

• installing to library ‘/Library/Frameworks/R.framework/Versions/2.15/Resources/library’
• installing source package ‘OpenMx’ ...
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for gcc option to support OpenMP... -fopenmp
checking whether gcc is installed... yes
checking build system type... i386-apple-darwin12.3.0
checking host system type... i386-apple-darwin12.3.0
checking for inst/npsol/osx/libnpsol.a... yes
configure: creating ./config.status
config.status: creating src/Makevars
config.status: executing src/omxSymbolTable.h commands
config.status: executing src/omxSymbolTable.c commands
** libs
*** arch - x86_64
gcc -arch x86_64 -std=gnu99 -I/Library/Frameworks/R.framework/Resources/include -I/Library/Frameworks/R.framework/Resources/include/x86_64 -DNDEBUG -I/usr/local/include -Wall -fopenmp -mmacosx-version-min=10.4 -fPIC -g -O2 -c merge.c -o merge.o
gcc: error: x86_64: No such file or directory
gcc: error: unrecognized option '-arch'
make[1]: *** [merge.o] Error 1
ERROR: compilation failed for package ‘OpenMx’
• removing ‘/Library/Frameworks/R.framework/Versions/2.15/Resources/library/OpenMx’
make: *** [install] Error 1
Offline
Joined: 04/16/2013 - 14:03
Well, one suggestion is to

Well, one suggestion is to move to a binary distribution for the time-being. If somebody with good knowledge of the F77 internals (i.e. not me) can roll back the correct libraries, then build a statically linked distribution of openmx, and finally splice this in to the installation process... would that work?

I've concluded (perhaps incorrectly) that there is no way to compile this with a contemporary distribution of F77, so unless npsol is majorly refactored out, this isn't going to lead anywhere. I think the best bet is to try to compile against an older version, then statically link against the older F77 and npsol so as to distribute a fully working, fully self-contained package.

For the sake of novice users, it would be great to adapt this to the current install process. However, I'd be personally happy to install it manually.

Ian