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.
Related
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.
I would like to install bazel from source, and use bazel to compile tensorflow on a cluster running redhat 6.7. When I try to install bazel, the glibc version (2.12) is too old. I do not have root access to the cluster. Is it possible to install tensorflow in this case?
My system information:
-bash-4.1$ cat /etc/redhat-release
Red Hat Enterprise Linux Server release 6.7 (Santiago)
-bash-4.1$ which gcc
/usr/bin/gcc
-bash-4.1$ gcc -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.4.7 20120313 (Red Hat 4.4.7-16) (GCC)
-bash-4.1$ ldd --version
ldd (GNU libc) 2.12
The system has newer gcc installed as well. I tried using it, bazel still won't compile.
-bash-4.1$ /usr/local/gcc/4.8.4/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/usr/local/gcc/4.8.4/bin/gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc/4.8.4/libexec/gcc/x86_64-unknown-linux-gnu/4.8.4/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/usr/local/gcc/4.8.4
Thread model: posix
gcc version 4.8.4 (GCC)
When I was compiling bazel, I got the following error:
bazel-0.1.1/_bin/build-runfiles: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.14' not found
Some people also reported this issue:
https://github.com/tensorflow/tensorflow/issues/110
and https://github.com/tensorflow/tensorflow/issues/527
How can I install the missing dependency locally, and have bazel pick up the right library?
You should be able to compile from source with a newer version of Bazel exporting LD_FLAGS, CXX and CC, and tweaking the tools/cpp/CROSSTOOL file of Bazel. Please open a github issue on Bazel (https://github.com/bazelbuild/bazel/issues) if you have further questions.
I am currently working on making all that easier. Sorry for the mess.
In case anyone need to do this manually:
Compile up-to-date glibc, gcc and all their dependencies from source with the option --disable-rpath to avoid glibc path being hard coded to system default. Do NOT add glibc to LD_LIBRARY_PATH directly, or all executables including rm will stop working.
Compile python with your gcc, install pip and the official wheel
./configure --prefix=$PWD/build --enable-unicode=ucs4 --with-cxx-main=g++ && make && make install
Start python with the following command to load the correct glibc, where ${GLIBC_PATH} is your install location to glibc, make an alias
alias tensorflow='${GLIBC_PATH}/lib/ld-2.23.so --library-path ${GLIBC_PATH}/lib:${LD_LIBRARY_PATH}which python'
Import tensorflow to check no error occur
After able to import tensorflow module without any error, you can use any other computer (possibly ubuntu VM on your PC) to compile a custom wheel with machine specific option, and copy that to your cluster following the guide
bazel build -c opt --copt=-mavx --copt=-mavx2 --copt=-mfma --copt=-mfpmath=both --copt=-msse4.2 --copt=-msse4.1 //tensorflow/tools/pip_package:build_pip_package
I have a setup with Windows 7, MSYS2, Mingw-w64-x86_64 gcc toolchain, CMake, and I am trying to build the nanomsg library.
Here is what I obtain :
$ cmake --debug-trycompile
-DCMAKE_TOOLCHAIN_FILE=../toolchain_i686-pc-mingw32.cmake -DCMAKE_INSTALL_PREFIX=/usr/x86_64-w64-mingw32 -G "MinGW Makefiles" ../nanomsg
debug trycompile on
-- The C compiler identification is GNU 4.8.2
-- Check for working C compiler: C:/mingw64/bin/x86_64-w64-mingw32-gcc.exe
-- Check for working C compiler: C:/mingw64/bin/x86_64-w64-mingw32-gcc.exe -- broken CMake Error at
C:/cmake-win32-x86/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake:61
(message): The C compiler
"C:/mingw64/bin/x86_64-w64-mingw32-gcc.exe" is not able to compile a
simple test program.
It fails with the following output:
Change Dir:
C:/msys64/home/Laurent/Dev/nanomsg-build/CMakeFiles/CMakeTmp
Run Build Command:C:/mingw64/bin/mingw32-make.exe
"cmTryCompileExec910276652/fast"
C:/mingw64/bin/mingw32-make.exe -f
CMakeFiles\cmTryCompileExec910276652.dir\build.make
CMakeFiles/cmTryCompileExec910276652.dir/build
mingw32-make.exe1: Entering directory
'C:/msys64/home/Laurent/Dev/nanomsg-build/CMakeFiles/CMakeTmp'
C:\cmake-win32-x86\bin\cmake.exe -E cmake_progress_report
C:\msys64\home\Laurent\Dev\nanomsg-build\CMakeFiles\CMakeTmp\CMakeFiles
1
Building C object
CMakeFiles/cmTryCompileExec910276652.dir/testCCompiler.c.obj
C:\mingw64\bin\x86_64-w64-mingw32-gcc.exe -o
CMakeFiles\cmTryCompileExec910276652.dir\testCCompiler.c.obj -c
C:\msys64\home\Laurent\Dev\nanomsg-build\CMakeFiles\CMakeTmp\testCCompiler.c
Linking C executable cmTryCompileExec910276652.exe
C:\cmake-win32-x86\bin\cmake.exe -E cmake_link_script
CMakeFiles\cmTryCompileExec910276652.dir\link.txt --verbose=1
C:\cmake-win32-x86\bin\cmake.exe -E remove -f
CMakeFiles\cmTryCompileExec910276652.dir/objects.a
x86_64-w64-mingw32-gcc-ar cr
CMakeFiles\cmTryCompileExec910276652.dir/objects.a
#CMakeFiles\cmTryCompileExec910276652.dir\objects1.rsp
sorry - this program has been built without plugin support
CMakeFiles\cmTryCompileExec910276652.dir\build.make:91: recipe for
target 'cmTryCompileExec910276652.exe' failed
mingw32-make.exe1: * [cmTryCompileExec910276652.exe] Error 1
mingw32-make.exe1: Leaving directory
'C:/msys64/home/Laurent/Dev/nanomsg-build/CMakeFiles/CMakeTmp'
Makefile:116: recipe for target 'cmTryCompileExec910276652/fast'
failed
mingw32-make.exe: * [cmTryCompileExec910276652/fast] Error 2
CMake will not be able to correctly generate this project. Call
Stack (most recent call first): CMakeLists.txt:29 (project)
Here is my toolchain file:
$ cat ../toolchain_i686-pc-mingw32.cmake
# http://www.cmake.org/Wiki/CMake_Cross_Compiling#The_toolchain_file
# http://bulletphysics.org/Bullet/phpBB3/viewtopic.php?t=8959
# http://stackoverflow.com/questions/19754316/cross-compiling-opencv-with-mingw-using-cmakein-linux-for-windows
# this one is important
SET(CMAKE_SYSTEM_NAME Windows)
#this one not so much
#SET(CMAKE_SYSTEM_VERSION 1)
# specify the cross compiler
SET(PREFIX x86_64-w64-mingw32)
SET(CMAKE_MAKE_PROGRAM mingw32-make)
SET(CMAKE_C_COMPILER ${PREFIX}-gcc)
SET(CMAKE_CXX_COMPILER ${PREFIX}-g++)
SET(CMAKE_AR ${PREFIX}-gcc-ar)
SET(CMAKE_NM ${PREFIX}-gcc-nm)
SET(CMAKE_RC_COMPILER windres)
# specify the cross linker
SET(CMAKE_RANLIB ${PREFIX}-gcc-ranlib)
# where is the target environment
SET(CMAKE_FIND_ROOT_PATH /opt/mingw64 /usr/${PREFIX})
# search for programs in the build host directories
#SET(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
# for libraries and headers in the target directories
#SET(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
#SET(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
It looks like it fails to build on an auto test because the toolchain misses plugin support.
Here is my gcc version and options:
$ /opt/mingw64/bin/x86_64-w64-mingw32-gcc.exe -v
Using built-in specs.
COLLECT_GCC=C:\mingw64\bin\x86_64-w64-mingw32-gcc.exe
COLLECT_LTO_WRAPPER=C:/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/4.8.2/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../../../src/gcc-4.8.2/configure --host=x86_64-w64-mingw32 --build=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --prefix=/mingw64 --with-sysroot=/c/mingw482/x86_64-482-posix-seh-rt_v3-rev3/mingw64 --with-gxx-include-dir=/mingw64/x86_64-w64-mingw32/include/c++ --enable-shared --enable-static --disable-multilib --enable-languages=ada,c,c++,fortran,objc,obj-c++,lto --enable-libstdcxx-time=yes --enable-threads=posix --enable-libgomp --enable-libatomic --enable-lto --enable-graphite --enable-checking=release --enable-fully-dynamic-string --enable-version-specific-runtime-libs --disable-isl-version-check --disable-cloog-version-check --disable-libstdcxx-pch --disable-libstdcxx-debug --enable-bootstrap --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-gnu-as --with-gnu-ld --with-arch=nocona --with-tune=core2 --with-libiconv --with-system-zlib --with-gmp=/c/mingw482/prerequisites/x86_64-w64-mingw32-static --with-mpfr=/c/mingw482/prerequisites/x86_64-w64-mingw32-static --with-mpc=/c/mingw482/prerequisites/x86_64-w64-mingw32-static --with-isl=/c/mingw482/prerequisites/x86_64-w64-mingw32-static --with-cloog=/c/mingw482/prerequisites/x86_64-w64-mingw32-static --enable-cloog-backend=isl --with-pkgversion='x86_64-posix-seh-rev3, Built by MinGW-W64 project' --with-bugurl=http://sourceforge.net/projects/mingw-w64 CFLAGS='-O2 -pipe -I/c/mingw482/x86_64-482-posix-seh-rt_v3-rev3/mingw64/opt/include -I/c/mingw482/prerequisites/x86_64-zlib-static/include -I/c/mingw482/prerequisites/x86_64-w64-mingw32-static/include' CXXFLAGS='-O2 -pipe -I/c/mingw482/x86_64-482-posix-seh-rt_v3-rev3/mingw64/opt/include -I/c/mingw482/prerequisites/x86_64-zlib-static/include -I/c/mingw482/prerequisites/x86_64-w64-mingw32-static/include' CPPFLAGS= LDFLAGS='-pipe -L/c/mingw482/x86_64-482-posix-seh-rt_v3-rev3/mingw64/opt/lib -L/c/mingw482/prerequisites/x86_64-zlib-static/lib -L/c/mingw482/prerequisites/x86_64-w64-mingw32-static/lib '
Thread model: posix
gcc version 4.8.2 (x86_64-posix-seh-rev3, Built by MinGW-W64 project)
Is it related to the "--enable-plugin" option (missing in my gcc) ?
Is there somewhere a toolchain build available with this option set ? I looked for it in MSYS2, Mingw-w64, rubenvb repositories, but it is not there. Or shall I build it myself ?
Possibly nanomsg does not need it ? Does the autotest requires it because nanomsg needs it ? Or can I prevent this autotest from being run ? Or can I set something to avoid the need of the "--enable-plugins" option ?
I think you are using the MSYS2 shell here, and not MSYS2 itself. If you were using an up to date MSYS2 then you'd be using the following mingw-w64 x86_64 GCC:
$ pacman -Ss mingw-w64-x86_64-gcc
mingw64/mingw-w64-x86_64-gcc 4.9.1-6
$ PATH=/mingw64/bin:$PATH gcc -v
Configured with: ... --enable-lto ...
--enable-lto implies --enable-plugins which is the default now and so doesn't appear in the list.
To build nanomsg with MSYS2, install https://master-dl.sourceforge.net/project/msys2/Base/x86_64/msys2-x86_64-20141003.exe, untick "Run MSYS2 shell now" (you want a mingw-w64 shell instead). Run the mingw-w64 shell (Start->MSYS2 64Bit->MinGW-w64 Win64 Shell). From within that shell:
$ pacman -S git make mingw-w64-x86_64-cmake mingw-w64-x86_64-gcc
$ git clone https://github.com/nanomsg/nanomsg.git
$ mkdir nanomsg-build
$ cd nanomsg-build
$ cmake --debug-trycompile -DCMAKE_INSTALL_PREFIX=/usr/x86_64-w64-mingw32 -G "MSYS Makefiles" ../nanomsg
$ make install
But if you are a developer, we'd appreciate the contribution of a PKGBUILD for nanomsg
I have a gcc compiler v 4.2.2 with next build options :
$ /opt/eldk-4.2/usr/bin/ppc_6xx-gcc -v
Reading specs from /home/dejovivl/workspace/eldk-4.2/usr/bin/../lib/gcc/powerpc-linux/4.2.2/specs
Target: powerpc-linux
Configured with: /opt/eldk/build/ppc-2008-04-01/work/usr/src/denx/BUILD/crosstool-0.43/build/gcc-4.2.2-glibc-20070515T2025-eldk/powerpc-linux/gcc-4.2.2/configure --target=powerpc-linux --host=i686-host_pc-linux-gnu --prefix=/var/tmp/eldk.UZpAG7/usr/crosstool/gcc-4.2.2-glibc-20070515T2025-eldk/powerpc-linux --disable-hosted-libstdcxx --with-headers=/var/tmp/eldk.UZpAG7/usr/crosstool/gcc-4.2.2-glibc-20070515T2025-eldk/powerpc-linux/powerpc-linux/include --with-local-prefix=/var/tmp/eldk.UZpAG7/usr/crosstool/gcc-4.2.2-glibc-20070515T2025-eldk/powerpc-linux/powerpc-linux --disable-nls --enable-threads=posix --enable-symvers=gnu --enable-__cxa_atexit --enable-languages=c,c++,java --enable-shared --enable-c99 --enable-long-long --without-x
Thread model: posix
gcc version 4.2.2
Most options are easy to find, except for --without-x. So, what is this option for?
The summary of gcc options didn't help, since the option is not listed.
Configure options are not options to gcc. They are given when gcc is built to the configure script. To find out what they mean, check the gcc source documentation.
If --with-x is not there, it doesn't have to mean anything, as autoconf-generated configure scripts can ignore flags.
However, it is listed on http://gcc.gnu.org/install/configure.html -
--with-x
Use the X Window System.
I downloaded gcc v4.8 from homebrew so that I could update gcc and g++ to 4.8 instead of using the 4.2.1 supplied from apple.
I installed gcc48 with the following command:
$brew install gcc48 --enable-all-languages
This installed all the required dependancies and when I run,
$gcc-4.8 -v
I get:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc48/4.8.1/gcc/libexec/gcc/x86_64-apple-darwin12.4.0/4.8.1/lto-wrapper
Target: x86_64-apple-darwin12.4.0
Configured with: ../configure --build=x86_64-apple-darwin12.4.0 --prefix=/usr/local/Cellar/gcc48/4.8.1/gcc --datarootdir=/usr/local/Cellar/gcc48/4.8.1/share --bindir=/usr/local/Cellar/gcc48/4.8.1/bin --enable-languages=c,c++,fortran,java,objc,obj-c++ --program-suffix=-4.8 --with-gmp=/usr/local/opt/gmp --with-mpfr=/usr/local/opt/mpfr --with-mpc=/usr/local/opt/libmpc --with-cloog=/usr/local/opt/cloog --with-isl=/usr/local/opt/isl --with-system-zlib --enable-libstdcxx-time=yes --enable-stage1-checking --enable-checking=release --enable-plugin --enable-lto --disable-werror --disable-nls --with-ecj-jar=/usr/local/opt/ecj/share/java/ecj.jar --disable-multilib
Thread model: posix
gcc version 4.8.1 (GCC)
I created the symbolic link using
$ln -s gcc-4.8 gcc
while in the /usr/local/bin folder and it created the symbolic link and
$gcc -v
gives me the same output as:
$gcc-4.8 -v
I tried doing the same thing with g++-4.8 and created a symbolic link using,
$ln -s g++-4.8 g++
and got no errors. But now, when I do
$g++ -v
I get:
g++-4.8: error trying to exec '/usr/local/bin/../Cellar/gcc48/4.8.1/bin/i686-apple-darwin11-llvm-g++-4.2': execvp: No such file or directory
Here's my $PATH:/usr/local/bin:/Library/Frameworks/Python.framework/Versions/3.3/bin:/Developer/Intel/ispc-v1.3.0-osx:/Developer/NVIDIA/CUDA-5.0/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/opt/X11/bin:/usr/texbin
It seems to be looking for 4.2 for some reason and I have no idea why! It worked perfectly fine for gcc and am just not sure what is the problem with g++?
which g++
returns
/usr/local/bin/g++
Try running:
$ hash
And check if gcc is in the list. If it is you may need to run:
$ hash -r
If you use bash or:
$ rehash
For zsh. This refreshes the hash, which provides a way for the shell to find the command without rechecking the entire path each time.
Looks to me that your g++ symbolic link points to the wrong thing.
Try:
ls -l `which g++`
And if that looks OK, see if the target is not a symbolic link too, etc..
Be mindful that symbol links use relative paths. If you move a symbolic link around, it doesn't point to the same location anymore.
Hope that helps.