I am trying to run fortran code on an Apple Macbook pro M1 chip machine running Big Sur v11.4. When testing my code I get the error
"f951: Error: unrecognized command-line option ‘-auxbase’".
I've written a test script test.f containing the following
program test
print *, "Hello World"
end program test
The output of gcc -v:
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 12.0.5 (clang-1205.0.22.11)
Target: arm64-apple-darwin20.5.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
The output of gfortran -v:
Using built-in specs.
COLLECT_GCC=gfortran
Target: x86_64-apple-darwin13.4.0
Configured with: ../configure --prefix=/Users/pfesi/opt/anaconda3/envs/fermi --build=x86_64-apple-darwin13.4.0 --host=x86_64-apple-darwin13.4.0 --target=x86_64-apple-darwin13.4.0 --with-libiconv-prefix=/Users/pfesi/opt/anaconda3/envs/fermi --enable-languages=fortran --disable-multilib --enable-checking=release --disable-bootstrap --disable-libssp --with-gmp=/Users/pfesi/opt/anaconda3/envs/fermi --with-mpfr=/Users/pfesi/opt/anaconda3/envs/fermi --with-mpc=/Users/pfesi/opt/anaconda3/envs/fermi --with-isl=/Users/pfesi/opt/anaconda3/envs/fermi --with-native-system-header-dir=/Applications/Xcode_12.4.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include
Thread model: posix
gcc version 7.5.0 (GCC)
The output of which gcc:
/usr/bin/gcc
The output of which gfortran:
/Users/pfesi/opt/anaconda3/envs/fermi/bin/gfortran
I'm not an expert on gfortran and any help will be highly appreciated.
Related
I have installed clang on my Windows 10 machine.
$ clang --version
clang version 6.0.1 (tags/RELEASE_601/final)
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: C:\Program Files\LLVM\bin
With it, I can compile C and C++ sources and generate object files, and use lib.exe to create libraries of them.
When it's time to link it into a binary, to my surprise, clang is creating a lib/exp output, not an executable?
Why does clang think it should be creating a library, not an executable?
clang++ -oarmor XWin/main.o -lSDL2main -lpi -ldblunt -lsino -lbase -L. -L ../../src/sino -L MSWin/libs/SDL/lib ../../src/Chipmunk2D/build.release/x64/Release/chipmunk.lib MSWin/libs/OpenAL/lib/OpenAL32.lib -lSDL2 -lOpenGL32
Creating library armor.lib and object armor.exp
LINK : fatal error LNK1561: entry point must be defined
clang++.exe: error: linker command failed with exit code 1561 (use -v to see invocation)
In UNIX, clang will by default create binaries, not libraries?
Check this link -
https://metricpanda.com/rival-fortress-update-27-compiling-with-clang-on-windows
There are currently two flavors of Clang that work on Windows: vanilla LLVM Clang and Clang/C2 with Microsoft Codegen.
I have a nearly fresh mac High Sierra installation. I installed gcc 4.9 with homebrew, and now I want to make sure that's the default gcc (not clang). So I typed the following commands and got the following outputs. And they make no sense to me. Shouldn't gcc -v and gcc-4.9 -v have the same outputs? Why are they different? It seems to me that I don't understand how which works or how symlinks work, which is a surprise because I thought I did.
$ which gcc
/usr/local/bin/gcc
$ ls -l $(which gcc)
lrwxr-xr-x 1 username admin 22 Mar 1 09:50 /usr/local/bin/gcc -> /usr/local/bin/gcc-4.9
$ which gcc-4.9
/usr/local/bin/gcc-4.9
$ gcc-4.9 -v
Using built-in specs.
COLLECT_GCC=gcc-4.9
COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc#4.9/4.9.4_1/libexec/gcc/x86_64-apple-darwin17.3.0/4.9.4/lto-wrapper
Target: x86_64-apple-darwin17.3.0
Configured with: ../configure --build=x86_64-apple-darwin17.3.0 --prefix=/usr/local/Cellar/gcc#4.9/4.9.4_1 --libdir=/usr/local/Cellar/gcc#4.9/4.9.4_1/lib/gcc/4.9 --enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-4.9 --with-system-zlib --enable-libstdcxx-time=yes --enable-stage1-checking --enable-checking=release --enable-lto --enable-plugin --with-build-config=bootstrap-debug --disable-werror --with-pkgversion='Homebrew GCC 4.9.4_1' --with-bugurl=https://github.com/Homebrew/homebrew-core/issues MAKEINFO=missing --disable-nls --enable-multilib
Thread model: posix
gcc version 4.9.4 (Homebrew GCC 4.9.4_1)
$ gcc -v
Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 9.0.0 (clang-900.0.39.2)
Target: x86_64-apple-darwin17.4.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
For context, I'm loosely following these instructions https://github.com/discourse/discourse/blob/master/docs/DEVELOPMENT-OSX-NATIVE.md#os-x-development-tools . I don't think it really matters, but I'm including it for context's sake.
The shell environment was remembering the previous locations of the commands. Using hash -r makes the shell forget them, so now everything behaves as expected.
Thanks to Mark Setchell in the comments above.
My mac version is Sierra. Xcode 8.0
gcc info
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 8.0.0 (clang-800.0.42.1)
Target: x86_64-apple-darwin16.4.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
I think gcc is not problem. My project build option is -print-multi-os-directory. but my gcc unsupported... what's the problem???
thanks
on mac your GCC is Clang as you may see in output
in clang option -print-multi-os-directory is unsupported
On current trunk (line 2079)
Was marked as unsupported here
You may try to install pure gcc via brew install gcc command
Also why do you need this option? Do you have any special checks in you project ?(this option just print path )
Since you are trying to build binutils:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=bfd/configure;h=97693870c462d5e5231bd2b512a76b7c271b9133;hb=7fa393306ed8b93019d225548474c0540b8928f7#l10348
Try to figure out why you get in condition when multi-os option is used.
This happened because your compiler passed test:
I just installed Rust on my Mac and rustc --version --verbose displays
rustc 1.0.0-nightly (91bdf23f5 2015-03-09) (built 2015-03-08)
binary: rustc
commit-hash: 91bdf23f504f79ed59617cde3dfebd3d5e39a476
commit-date: 2015-03-09
build-date: 2015-03-08
host: x86_64-apple-darwin
release: 1.0.0-nightly
I cloned a couple of repositories (postgres-extension and erlang-rust-nif) and ran cargo build upon both of them. Both reported the error
error: could not exec the linker `cc`: No such file or directory (os error 2)
error: aborting due to previous error
Additionally, I wasn't able to compile a simple Rust file printing "hello world" using rustc. I was only able to compile them by passing the flags rustc -C linker=gcc hello_world.rs.
clang --version displays
clang version 3.4.2 (http://llvm.org/git/llvm.git 5c6aa738fb3325ae499454877f1e2926d2368135)
Target: x86_64-apple-darwin12.2.1
Thread model: posix
gcc --version displays
gcc (Homebrew gcc49 4.9.2_1) 4.9.2
It looks like you have installed GCC and LLVM/clang via Homebrew. Checking out the shared macOS configurations, the linker defaults to cc. I have installed the macOS developer tools:
$ clang --version
Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin13.4.0
Thread model: posix
$ gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin13.4.0
Thread model: posix
$ cc --version
Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin13.4.0
Thread model: posix
This is potentially something that Rust itself could fix, but you'd have to file a bug report / enhancement request. It's possible that you might be able to work around this by symlinking clang as cc, instead of just aliasing it, as aliases probably don't exist in the environment that Rust is calling out from.
I am running Yosemite and get xcode 6.1 installed on it. I also installed manually gcc with brew install gcc command.
However when i run port select --list gcc command, it returns the following message
Available versions for gcc:
none (active)
the gcc version shows clang with LLVM.
gcc --version
Configured with: --prefix=/Volumes/DEV/Applications/Xcode.app/Contents/Developer/usr -- with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 6.0 (clang-600.0.54) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin14.0.0
Thread model: posix