I mostly work on linux and have no problems but want to occasionally use a Mac for work. Somehow gfortran does not work there, though. I installed it as instructed but when I try to compile something, this happens:
gfortran -o m_g_matrix2.x m_g_matrix.f90
ld: entry point (start) undefined. Usually in crt1.o for architecture x86_64
collect2: error: ld returned 1 exit status
I have no idea what this means and google search did not help. Did someone manage to get gfortran to work on Mac?
Thanks for the help!
I installed gcc binaries for yosemite from http://hpc.sourceforge.net
and also installed Xcode command-line tools as directed there.
gcc contains the gfortran compiler.
Seems to work well on macbook air with Yosemite.
JTN
Related
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'm trying to compile WxWidgets 3.0.2 on my mac OSX 10.10
and I get the following message:
Blockquote
...
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [/Users/.../wxWidgets-3.0.2/build_rel/lib/libwx_osx_cocoau-3.0.0.2.0.dylib] Error 1
I'm compiling using these flags
../configure --with-osx_cocoa --with-macosx-version-min=10.7 --with-macosx-sdk=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk --prefix="$(pwd)" --with-opengl CC=clang CXX=clang++ CXXFLAGS="-stdlib=libc++ -std=c++11" OBJCXXFLAGS="-stdlib=libc++ -std=c++11" LDFLAGS=-stdlib=libc++ --enable-universal-binary=x86_64 --enable-monolithic --enable-unicode --with-expat=builtin --with-zlib=builtin --with-libtiff=builtin --with-regex=builtin --with-libpng=builtin --with-libjpeg=builtin
As you can see I added the enable-universal-binary=x86_64 as suggested in other topics.
If you can suggest other flags that I might have not added or I should remove
that would be great..
Thanks
The other way:
brew install wxwidgets
you will get compiled wxWidgets in /usr/local/Cellar.
In principle, this should work, but what is the point of using --enable-universal-binary=x86_64? It's not universal if there is only a single architecture... You probably wanted to use --enable-macosx_arch=x86_64 instead.
BTW, I think the various stdlib-related options are unnecessary as well, clang is the default compiler under 10.10. And --enable-unicode is definitely superfluous.
If you need wx3.0.0 osx 10.7+ monolitic, shared library can get it from here wxphp stub bundle
Library is included in app/contents/resources , use it if you want. but you need headers c++, get it from wx side.
As posted here, you can use --with-macosx-sdk=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/ as a workaround. There is an fixed issue about it and will probably be released on 3.0.3.
I updated my Mac to OS X 10.9 GM, then I found that gfortran does not work.
When building any program, it shows:
ld: library not found for -lcrt1.10.5.o
collect2: ld return 1
Does anyone know how I might solve this?
This problem is because OS X 10.9 has removed the /Developer directory completely where the library crt1.10.5.o used to locate. The libraries have been moved to the new Xcode directory (make sure that Xcode is also updated to the latest version 5.0.1+). I found that crt1.10.5.o is actually hidden deep in here /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib. I believe there should be a way to redirect ld automatically, but I do not know how. So for now I am using the -L flag to compile.
gfortran ... -L /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib/
This works for me as a temperary solution. I am also waiting for better solutions to come up.
Gfortran has already been compiled for Mac OS X Mavericks 10.9 by http://hpc.sourceforge.net/
First, cd to the root of your Mavericks installation so the files extract recursively into the proper folders
cd /
sudo wget http://prdownloads.sourceforge.net/hpc/gcc-4.9-bin.tar.gz
tar -xvf gcc-4.9-bin.tar.gz
gfortran --help
I had similar problems (ld: library not found for -lcrt0.o) but I discovered that they went away when I stopped using the -static flag with the gfortran command. The -static-libgcc flag seems to be OK.
I'm using InstallJammer to build cross-platform installers for my application (Windows, Linux & Mac). However, InstallJammer development has been discontinued and the official forum is now closed.
I need to build the installkit for Windows, because I'll have to make some changes to the Windows install manifest, in order to add Windows 7 support (otherwise the installer displays the message "This program might not have installed correctly").
I grabbed the latest installkit sources from here: http://sourceforge.net/projects/installjammer/files/installkit/1.2.15/installkit-1.2.15.tar.gz/download
I found this topic http://www.installjammer.com/forums/viewtopic.php?f=3&p=9258 which helped me get started.
I grabbed latest version of MinGW and typed ./configure && make. It started the build process, but there was this error while trying to compile TCL:
c:/installkit-1.2.15/src/tcl/win/tclWinReg.c:750:29: error: lvalue required as increment operand
Since these sources are kind of old, I figured I should try with an older GCC version (I was using 4.7.2). So I downgraded MinGW's GCC to version 3.4.5 and tried again.
This time, TCL built fine. Everything was going well, until it failed to build something called 'miniarc' (I don't know what it is), with the following error message:
miniarc.o:miniarc.c:(.text+0x370c): undefined reference to `_imp__strtoull'
miniarc.o:miniarc.c:(.text+0x37c9): undefined reference to `_imp__strtoull'
miniarc.o:miniarc.c:(.text+0x3cb6): undefined reference to `_imp__strtoull'
miniarc.o:miniarc.c:(.text+0x3e78): undefined reference to `_imp__strtoull'
miniarc.o:miniarc.c:(.text+0x3e9f): undefined reference to `_imp__strtoull'
miniarc.o:miniarc.c:(.text+0x3ff5): more undefined references to `_imp__strtoull' follow
collect2: ld returned 1 exit status
Strange thing is that there's no reference to imp_strtoull inside miniarc.c.
Moving on, I tried to build it in Ubuntu, since I didn't know what else to do, and it worked! GCC version was 4.4.3. So I went and searched for GCC 4.4.3 for MinGW, but the closest version was 4.4.0. I grabbed these and tried again. Same tcl build error (regarding tclWinReg.c).
Then I went back to GCC 4.7.2 and replaced TCL & TK sources (8.4) with the latest ones (8.5) and tried again.
TCL and TK both built fine, and so did some other libs, but when it came to 'miniarc', it failed again. This time with a different error:
undefined reference to `TclIncrVar2'
Apparently, this function no longer exists in TCL 8.5.
So, I'm out of ideas. I even tried emailing the original (and only) InstallJammer developer, but still got no answer (I don't even know if his email is the same).
Does anyone have any suggestions?
EDIT: I should add that I have very little experience with Makefiles and the last time I coded in C was 8 years ago in college. So, I apologize if there is something obvious about all this that I didn't notice.
I don't like the solution, but here's how I got it working:
Using GCC 3.4.5, I started the make process by typing ./configure && make;
The make process stops with an error (mentioned above) when it reaches 'miniarc';
Then, manually, I built a DLL (strtoull.dll) from file strtoull.o (below is the exact command-line I typed);
gcc -pipe -shared -o strtoull.dll strtoull.o -lz -L/c/installkit-1.2.15/Windows/lib /c/installkit-1.2.15/Windows/lib/libtclstub84s.a"
After that, I copied strtoull.dll to miniarc/build and to windows/system32;
Then I entered folder miniarc/build and typed:
gcc -pipe -shared -o miniarc01.dll miniarc.o sha1.o md5.o -lz -L/c/installkit-1.2.15/Windows/lib "/c/installkit-1.2.15/Windows/lib/libtclstub84s.a" strtoull.dll
Finally, I typed make again so it could continue building the rest of the stuff.
I'm consistently getting errors across the board related to the following problem, on Mac osx 10.7.4 via a 2011 mac book pro.
these errors are mostly from mathematical related dev libs that compile and run example code without error on various linux machines, while using similar make files
the error i get is usually something on the lines of
ld: symbol(s) not found for architecture x86_64
this also occurs with various compilers and no matter how i compile the lib I link, clang, various versions of gcc even haskell's ghc
some libs that give me errors are
PETSC(which i compiled from source and none of the examples compile
with make test)
GSL(from macports) gives same error
FFTW... and the list goes on
I believe the culprit is that some where along the line something (maybe a compiler) was compiled via macports improperly,
for instance gcc -v states it was compiled Target: i686-apple-darwin11
--build=i686-apple-darwin11 --enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2336.11~28/dst-llvmCore/Developer/usr/local --program-prefix=i686-apple-darwin11- --host=x86_64-apple-darwin11 --target=i686-apple-darwin11
while every other compiler, clang , g++-mp-4.7 exc, says Target: x86_64-apple-darwin11
is there any solution to this problem?
is there a way to recompile everything enforcing 64 bit? Would that fix the above problem?
Mac OS X has its own build toolchain, so this probably is a path issue.
Check
which gcc
and compare the path with any library you know comes from mac ports (probably in /opt/bin).
As a solution, putting the /opt/bin path at the beginning of your $PATH should work out.