I am trying to install a program and when I run make or make -f Makefile (following the installation instructions) I get the following output:
g77 -O5 -Wall -c prep_output.f -o prep_output.o
dyld: Symbol not found: ___keymgr_global
Referenced from: /usr/local/bin/g77
Expected in: /usr/lib/libSystem.B.dylib
make: *** [prep_output.o] Abort trap: 6
I am working on a macOS Mojave 10.14.6. Following some other proposed solutions in similar problems, I've already installed Command line tools in my Xcode but that didn't do the trick. Any suggestions please??
Thanks in advance
EDIT:
I got rid of g77 and installed a compatible version of gcc (gcc8) through MacPorts. After running the make command I get the following:
g77 -O5 -Wall -c prep_output.f -o prep_output.o
make: g77: No such file or directory
make: *** [prep_output.o] Error 1
So I guess the program still needs the g77 setup? This is the program btw ([http://www.cfht.hawaii.edu/~arnouts/LEPHARE/install.html]). Is there a way to rely to the gfortran compiler for building the program?
Thanks in advance
P.S. I noticed that when I install g77 I get the following error:
x usr/local/: Can't set user=0/group=0 for usr/local`
`tar: Error exit delayed from previous errors.
However it still installs g77..
The error message indicates that your installation of g77 is broken. This has nothing to do with make or the particular project you're trying to build, except inasmuch as the project is trying to use g77 in the first place. That is a bit surprising, actually, since g77 has been obsolete for years (gfortran is the current GNU Fortran compiler), but I'm uncertain what exactly to expect from XCode in this area.
On the other hand, since the full path to the binary is /usr/local/bin/g77, I'm further inclined to think that you're not using XCode for this at all. Possibly you've dumped a g77 built on some other system into your /usr/local/bin, and it's not compatible with your Mojave system.
Your best bet is probably to
Get rid of your broken g77 installation.
Install Fink or MacPorts, or a similar project.
Install the Fink / MacPorts / whatever package for gfortran (maybe gcc-gfortran or similar in some of those) to get a working Fortran compiler.
Rely on that compiler to build your project.
I eventually want to use valgrind to find what is causing the occasional bizarre output in a C program which refines a model against experimental data using OpenMP parallel programming.
To avoid the use of the nominal gcc (ie clang) compiler, I used brew to install gcc-4.9 on my MacPro running Yosemite (OS x 10.10.5). However, when trying to compile my program with gcc-4.9, with or without -fopenmp, I get numerous error messages of the type:
/var/folders/qc/1j0gr_l48xnfd9001s6tt6f80000gn/T//ccRxnrnU.s:30597:suffix
or operands invalid for `movq'
I have no idea what the problem triggering these error messages is. Can anyone help?
The following summarises what was worked out in the comments section and did lead to the issue being resolved. Not all steps may be necessary, but most are probably good practice.
Step 1 - Clean up
If you have been trying lots of different, potentially incompatible, methods to get OpenMP set up, it is probably a good idea to clean them up first. So, something like:
brew rm --force gcc # or maybe gcc#4.9
Step 2 - Update Xcode and Command Line Tools
If you have upgraded macOS since installing Xcode, it is probably advisable to update Xcode and its "Command Line Tools"
Consider uninstalling and re-installing Xcode - it is available for free from the App Store.
Update/install the "Command Line Tools" after installing/updating with:
xcode-select --install
Step 3 - Install gcc
Now, try installing gcc afresh, ensuring that you use the --without-multilib option:
brew install gcc#4.9 --without-multilib
Hopefully you can now compile OpenMP code with:
/usr/local/bin/gcc -fopenmp program.c -o program
I am unsure exactly why the --without-multilib option is needed and prefer to quote #hristo-iliev:
Multilib usually refers to the coexistence of both 64-bit and 32-bit
versions of each library so that 32-bit software could be run on
64-bit OS. In the GCC case that probably refers to having all GCC
runtime libraries in "fat" Mach-O format, i.e. versions for both i386
and x86_64 in the same shared library file. It could be that libgomp
(the GNU OpenMP runtime library) cannot be built in such a way.
See this question.
Keywords: gcc, g++, GNU Compiler, OpenMP, fopenmp, -fopenmp, Xcode, multilib, Command Line Tools, macOS, OSX, homebrew, brew
I'm starting to learn Haskell and I found out that ghc can compile using LLVM with the -fllvm flag. Whenever I use the flag, I get the error message:
<no location info>: error:
Warning: Couldn't figure out LLVM version!
Make sure you have installed LLVM 3.7
ghc: could not execute: opt
However, I have opt in my /usr/local/Cellar/llvm/3.9.0/ folder. I'm on a Mac OS X and I've installed the full LLVM with brew install llvm but error persists. Is this a genuine version problem where I have to unistall LLVM and reinstall its 3.7 version? Or is ghc having trouble finding opt and there is some kind of search path I can modify to fix the problem? Thanks for the help and have a great day.
The GHC documentation says that it's compatible with llvm-2.8+, but as you've discovered, it actually requires llvm-3.7.
The simplest way to get it is:
brew install llvm#3.7
This installs llvm binaries in your path with a -3.7 suffix, like clang-3.7. GHC will need the unadorned names, which are in a subdirectory:
export PATH=/usr/local/opt/llvm#3.7/lib/llvm-3.7/bin:$PATH
I try to compile Octave 3.8.2 on CentOS 6.4 （serve）, but there's an error:
A BLAS library was detected but found incompatible with your Fortran 77 compiler settings.
I'm so confused. I compiled a BLAS and a LAPACK myself, and I added their path to bashrc. But this error appeared again. I try to change fflags to ff2c as other resources suggested, but this error also occurred.
I found the following guide and discussion of my error.
I am going through this, and I had the same issues that you are mentioning. I solved it by using the auto config options to point it to the correct library, e.g.
./configure --with-lapack=/path/to/liblapack.so.3 --with-blas=/path/to/libf77blas.so.3
It compiles and produces an executable.
I would suggest using OpenBLAS instead of the common BLAS and LAPACK packages. It is written in the Octave documentation:
"Accelerated BLAS libraries such as OpenBLAS (https://www.openblas.net/) or ATLAS (http://math-atlas.sourceforge.net) are recommended for best performance. The reference implementation (http://www.netlib.org/blas) is slow, unmaintained, and suffers from certain bugs in corner case inputs."
You can download it from https://www.openblas.net/ and install it with the classical ./configure && make %% sudo make install. After this move the libraries generated by OpenBLAS to /usr/lib64 and run:
./configure -with-blas="-lopenblas"
Add other flags and arguments to configure if needed.
I'm having trouble building the hmatrix library on OS X Lion. Looking at the .cabal file, it requires the gsl library, so I installed it with macports. The .a files are in /opt/local/lib and the .h files are in /opt/local/include/gsl
As suggested here I changed the built-type from Custom to Simple. (without that change I get a similar error).
When I use cabal configure I get the following output:
* Missing C library: gsl
This problem can usually be solved by installing the system package that
provides this library (you may need the "-dev" version). If the library is
already installed but in a non-standard location then you can use the flags
--extra-include-dirs= and --extra-lib-dirs= to specify where it is.
So I tried cabal --extra-include-dirs=/opt/local/include --extra-lib-dirs=/opt/local/lib configure, but I still get the same error. I can compile and link a c program that includes gsl. What files is cabal looking for? If I have the right files, how do I tell it how to find them?
libgsl.a is a universal binary:
$ file /opt/local/lib/libgsl.a
/opt/local/lib/libgsl.a: Mach-O universal binary with 2 architectures
/opt/local/lib/libgsl.a (for architecture x86_64): current ar archive random library
/opt/local/lib/libgsl.a (for architecture i386): current ar archive random library
ghc looks like it's 64-bit:
$ ghc --info
[("Project name","The Glorious Glasgow Haskell Compilation System")
,("GCC extra via C opts"," -fwrapv")
,("C compiler command","/usr/bin/llvm-gcc")
,("C compiler flags"," -m64 -fno-stack-protector -m64")
,("ar command","/usr/bin/ar")
,("ar flags","clqs")
,("ar supports at file","NO")
,("touch command","touch")
,("dllwrap command","/bin/false")
,("windres command","/bin/false")
,("perl command","/usr/bin/perl")
,("target os","OSDarwin")
,("target arch","ArchX86_64")
,("target word size","8")
,("target has GNU nonexec stack","False")
,("target has subsections via symbols","True")
,("Project version","7.4.2")
,("Booter version","7.4.2")
,("Stage","2")
,("Build platform","x86_64-apple-darwin")
,("Host platform","x86_64-apple-darwin")
,("Target platform","x86_64-apple-darwin")
,("Have interpreter","YES")
,("Object splitting supported","NO")
,("Have native code generator","YES")
,("Support SMP","YES")
,("Unregisterised","NO")
,("Tables next to code","YES")
,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn")
,("Leading underscore","YES")
,("Debug on","False")
,("LibDir","/usr/local/Cellar/ghc/7.4.2/lib/ghc-7.4.2")
,("Global Package DB","/usr/local/Cellar/ghc/7.4.2/lib/ghc-7.4.2/package.conf.d")
,("Gcc Linker flags","[\"-m64\"]")
,("Ld Linker flags","[\"-arch\",\"x86_64\"]")
]
As an alternative to mac-ports you can use the nix package manager for mac. It does a pretty good job of taking care of the c dependancies for for the libraries available through it. In general I have been more happy with it then any other package manager on mac.
Unfortunately mac(darwin) unlike for linux does not have as many binaries available through nix so installing ghc often means waiting for it to compile.
The commands to install ghc and hmatrix after installation of nix are:
nix-env -iA nixpkgs-unstable.haskellPackages.ghc
nix-env -iA nixpkgs-unstable.haskellPackages.hmatrix
All of the needed dependencies will be taken care of for you.
I just tried it on my macbook pro and hmatrix seems to be working correctly in ghci after trying commands from the first few pages of the tutorial.
I'm not a mac person, but it really sounds like you haven't installed the "-dev" version. For a mac, I suspect you need to install gsl-devel in addition to gsl. If the problem persists, verify that you have libgsl0-dev on your library path.