I have gcc 4.1.2 installed. I installed a new separate gcc (version 4.4.6) too using yum on CentOS. Now my question is, do these two gcc versions use the same glibc version or glibc is different for both of them? How can I find out? Secondly, is it better to have a newer version of glibc in terms of performance?
Both GCC versions will use the glibc version you have installed on your system. GCC packages don't (usually) ship a separate C library.
Write a simple program which makes a call to a glibc function. Then compile it with both versions of gcc and then do ldd a.out on each compilation. You'll get the list of libraries used.
If your source file is test.c then:
$ gcc test.c -o out1 # with gcc 4.1.2
$ gcc test.c -o out2 # with gcc 4.4.6
$ ldd out1
$ ldd out2
This will show the libc versions used by each gcc.
Performance may or may not be better depending on the update done for glibc functions.
Related
My directory structure is:
── bin
│ ├── mylib-osx.so.1.72
│ ├── mylib.so.1.72
├── my.c
I am trying to compile my.c and link mylib-osx.so.1.72 (I'm on a macOS), but to no avail:
ld: library not found for -l:PhotoDNAx64.so.1.72
I tried:
gcc -o my -lmylib-osx my.c
gcc -o my -lmylib-osx.so.1.72 my.c
gcc -o my -lmylib my.c
gcc -o my -L./bin -lmylib-osx my.c
gcc -o my -L./bin -l:"mylib-osx.so.1.72" my.c
What am I doing wrong and why cannot the library be found?
What am I doing wrong and why cannot the library be found?
Read about Invoking GCC. You was wrong in not reading that (or any other documentation of gcc).
Order of program arguments to gcc matters a lot (and in practice several arguments are very useful, e.g. both -Wall and -g at least, and probably -v sometimes). You want something like
gcc -v -Wall -g my.c -lmylib-osx -o my
(also try variants of that), since gcc is running some ld or equivalent linker command, and if you want to pass some -Llib-directory use something like
gcc -v -Wall -g my.c -L./bin -lmylib-osx -o my
and you also need to read the documentation of MacOSX linker (probably named ld). You could also read Levine's Linkers and loaders book.
If you are not happy with gcc (but please use a recent version, so GCC 8 in 2019, not the crappy software sold by Apple named gcc) consider using Clang (a recent version too, e.g. Clang 8 in 2019). It has the same limitation regarding order of program arguments than gcc does (since order of program arguments even mattered for Unix or POSIX cc).
In general, read the documentation of a command before asking questions here about that command. A minima, man gcc on your Apple (or Linux) computer.
PS. The last time I have used some MacOSX was in 2004. My biased recommendation is to install and use Linux (which I use since 1993; I tried MacOSX around 2004 during less than a year, and have been disappointed both by the operating system, including its display server and GUI desktop environment, and by the Apple hardware).
I've used linuxbrew to install gcc 5.3 on a machine on which I don't have sudo access. I now want to link with X11:
> gcc test.c -lX11
ld: cannot find -lX11
I've checked that libX11.so exists in /usr/lib64/ which is on the compiler's LIBRARY_PATH. If I use the system's gcc it works fine, but I need a newer version to compile my actual program.
use -L flag, like this -L/usr/lib64, or you can specify full path to library like this gcc test.c /usr/lib64/libX11.so
According to this comment by a linuxbrew developer,
linuxbrewed gcc removes /usr/lib64 from the library path because mixing system libraries with brewed libraries creates havoc.
The solution is to brew install linuxbrew/xorg/xorg.
I'm new to Homebrew (I usually use Macports, but I'm trying out Homebrew on a 2nd computer), and I wish to install the openmpi (or mpich2) package. Steps are as follows (carried out on Mac OS X Yosemite with Xcode 6 installed):
brew install gcc
brew install openmpi
However, I suspect the linking may have been done incorrectly, due to the following reasons:
The symbolic link for /usr/local/bin/gcc is missing:
$ which gcc
/usr/bin/gcc
$ gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/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
$ which gcc-4.9
/usr/local/bin/gcc-4.9
$ gcc-4.9 --version
gcc-4.9 (Homebrew gcc 4.9.2) 4.9.2
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
mpicc may have been linked to the Apple gcc:
$ which mpicc
/usr/local/bin/mpicc
$ mpicc --version
Apple LLVM version 6.0 (clang-600.0.54) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin14.0.0
Thread model: posix
My questions are as follows:
How do I get the /usr/local/bin/gcc symbolic link? Or is Homebrew deliberately avoiding this for certain reasons? e.g. if Homebrew is compiling all its packages using Apple gcc, which is assumed to be in the path, would changing the path to gcc-4.9 mean that Homebrew now compiles its packages with gcc-4.9 instead?
Is the Homebrew-installed Open MPI linked to the Apple gcc (and not the Homebrew gcc)? If yes, is it possible (or advisable) to change the linking?
Alternatively, how necessary is it to fix the linkages? Could I run into certain problems if I choose not to fix it? For example, I'm considering using ln -s to forcibly create the /usr/local/bin/gcc symbolic link. But is this a good idea (*)?
(*) I understand there are likely to be issues when linking object files created by different compilers. So with (1), (2) and (3), I'm hoping to find a solution that avoids combinations whereby I'm creating object files with different compilers (some with gcc-4.9 and some with the Apple gcc).
You need to do the following:
1) Add environment variables for homebrew (you can also add these lines to your ~\.bashrc):
$ export HOMEBREW_CC=gcc-4.9
$ export HOMEBREW_CXX=g++-4.9
2) Rebuild and reinstall openmpi and its dependencies from source
$ brew reinstall openmpi --build-from-source
3) In the end you will get a message like:
==> Reinstalling open-mpi
==> Using Homebrew-provided fortran compiler.
This may be changed by setting the FC environment variable.
==> Downloading http://www.open-mpi.org/software/ompi/v1.8/downloads/openmpi-1.8.
Already downloaded: /Library/Caches/Homebrew/open-mpi-1.8.4.tar.bz2
==> ./configure --prefix=/usr/local/Cellar/open-mpi/1.8.4 --disable-silent-rules
==> make all
==> make check
==> make install
Warning: open-mpi dependency gcc was built with a different C++ standard
library (libstdc++ from clang). This may cause problems at runtime.
🍺 /usr/local/Cellar/open-mpi/1.8.4: 785 files, 23M, built in 41.2 minutes
$ mpicc --showme
gcc-4.9 -I/usr/local/Cellar/open-mpi/1.8.4/include -L/usr/local/opt/libevent/lib -L/usr/local/Cellar/open-mpi/1.8.4/lib -lmpi
On my MacBook I had some conflicts with XCode 6.2, which were solved following this instructions
If you want to install mpich
$ unlink openmpi
$ brew unlink gcc
$ brew install homebrew/versions/gcc5
$ brew install mpich --build-from-source
$ mpicc -v
mpicc for MPICH version 3.2
Using built-in specs.
COLLECT_GCC=gcc-5
COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc5/5.4.0/libexec/gcc/x86_64-apple-darwin14.5.0/5.4.0/lto-wrapper
Target: x86_64-apple-darwin14.5.0
Configured with: ../configure --build=x86_64-apple-darwin14.5.0 --prefix=/usr/local/Cellar/gcc5/5.4.0 --libdir=/usr/local/Cellar/gcc5/5.4.0/lib/gcc/5 --enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-5 --with-gmp=/usr/local/opt/gmp --with-mpfr=/usr/local/opt/mpfr --with-mpc=/usr/local/opt/libmpc --with-isl=/usr/local/opt/isl014 --with-system-zlib --enable-libstdcxx-time=yes --enable-stage1-checking --enable-checking=release --enable-lto --disable-werror --with-pkgversion='Homebrew gcc5 5.4.0' --with-bugurl=https://github.com/Homebrew/homebrew-versions/issues --enable-plugin --disable-nls --enable-multilib
Thread model: posix
gcc version 5.4.0 (Homebrew gcc5 5.4.0)
It would probably be cleaner if you simply modify the configuration file for the Open MPI compiler wrapper and make it invoke gcc-4.9 instead of simply gcc. As I have no idea where exactly Homebrew puts Open MPI and therefore cannot give you the correct path directly, you should search for it:
$ find /usr/local -name mpicc-wrapper-data.txt
Once you have found mpicc-wrapper-data.txt, find the line that starts with compiler= and modify it to read:
compiler=gcc-4.9
You should also modify all other files that match the shell glob mpi*-wrapper-data.txt and modify the compiler=... line accordingly. Use g++-4.9 in mpic++, mpicxx, and mpiCC. Use gfortran-4.9 (if installed) in mpif77 and mpif90 (for Open MPI versions < 1.8) or for mpifort (for versions >= 1.8).
Mixing object code produced by different compilers on the same platform should be fine as long as all of them adhere to the same ABI, which is more or less the case with Clang and GCC. In the end, all programs are linked against the system libraries that come with OS X and those are compiled with Clang only.
I am using OS 10.9 on mac machine. I want to know the version of gcc I am using. So I tried gcc --version on terminal and it results :
$ gcc --version
Configured with: --prefix=/Applications/Xcode5-DP.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode5-DP.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/c++/4.2.1
Apple LLVM version 5.0 (clang-500.1.58) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin13.0.0
Thread model: posix
Here in output, there is no detail related to gcc but clang is there. I am confused
whether gcc command executes clang or gcc(gnu).
You seem to not actually have gcc on your path. As of recent versions of Xcode, it installs a "gcc" that is instead a link to Clang.
gcc -dumpversion | cut -f1 -d.
-dumpversion Print the compiler version (for example, 3.0) — and don't do anything else.
The same works for following compilers/aliases:
cc -dumpversion
g++ -dumpversion
clang -dumpversion
tcc -dumpversion
Be careful with automate parsing the GCC output:
Output of --version might be localized (e.g. to Russian, Chinese, etc.)
GCC might be built with option --with-gcc-major-version-only. And some distros (e.g. Fedora) are already using that
GCC might be built with option --with-pkgversion. And --version output will contain something like Android (5220042 based on r346389c) clang version 8.0.7 (it's real version string)
The tools supplied by Apple have been switched from GCC to Clang. The gcc command is linked to clang as a convenience. In OS X 10.9, you do not have GCC on your system unless you have installed it independently of Apple packages.
In case you installed gcc via brew install, it might've got installed as gcc-11.
You can run brew info gcc to get path where it is installed and get exact name of the binary by listing the directory.
$ brew info gcc
gcc: stable 11.2.0 (bottled), HEAD
GNU compiler collection
https://gcc.gnu.org/
/usr/local/Cellar/gcc/11.2.0_3 (2,163 files, 459.8MB) *
...
$ ls /usr/local/Cellar/gcc/11.2.0_3/bin
c++-11 gcc-ar-11 gcov-dump-11 gfortran x86_64-apple-darwin21-g++-11 x86_64-apple-darwin21-gcc-ranlib-11
cpp-11 gcc-nm-11 gcov-tool-11 gfortran-11 x86_64-apple-darwin21-gcc-11 x86_64-apple-darwin21-gcc-tmp
g++-11 gcc-ranlib-11 gdc lto-dump-11 x86_64-apple-darwin21-gcc-ar-11 x86_64-apple-darwin21-gdc-11
gcc-11 gcov-11 gdc-11 x86_64-apple-darwin21-c++-11 x86_64-apple-darwin21-gcc-nm-11 x86_64-apple-darwin21-gfortran-11
Then using gcc-11 -v will get you actual version of gcc installed.
$ gcc-11 -v
Using built-in specs.
COLLECT_GCC=gcc-11
COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc/11.2.0_3/bin/../libexec/gcc/x86_64-apple-darwin21/11/lto-wrapper
Target: x86_64-apple-darwin21
Configured with: ../configure --prefix=/usr/local/opt/gcc --libdir=/usr/local/opt/gcc/lib/gcc/11 --disable-nls --enable-checking=release --with-gcc-major-version-only --enable-languages=c,c++,objc,obj-c++,fortran,d --program-suffix=-11 --with-gmp=/usr/local/opt/gmp --with-mpfr=/usr/local/opt/mpfr --with-mpc=/usr/local/opt/libmpc --with-isl=/usr/local/opt/isl --with-zstd=/usr/local/opt/zstd --with-pkgversion='Homebrew GCC 11.2.0_3' --with-bugurl=https://github.com/Homebrew/homebrew-core/issues --enable-libphobos --build=x86_64-apple-darwin21 --with-system-zlib --disable-multilib --with-native-system-header-dir=/usr/include --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.0 (Homebrew GCC 11.2.0_3)
gcc -dumpversion | cut -f1 -f2 -f3 -d.
When I compile a simple Hello World! program that uses the sscanf function on my local Debian lenny x64, it works. But when I upload the same program to the server running CentOS x86, it will not work. If I do not use sscanf, then the program works on both computers.
gcc -std=c99 -O2 -pipe -m32
If I compile it with sscanf but without -std=c99, then it works on both computers.
gcc -O2 -pipe -m32
What is the problem with sscanf and c99 on CentOS x86 ? I thought that compiling with the -m32 flag would work on all Linuxes ? (I have limited access to the CentOS server, so I do not have access to error messages.)
Probably the CentOS box is using an old version of glibc. Since the nonstandard GNU extensions to their scanf implementation ended up making glibc conflict with c99, they added a nasty hack of redirecting *scanf to __isoc99_*scanf when -std=c99 is in use; if your copy of glibc is missing the __isoc99_sscanf symbol, the program will then fail to run.
Static linking, or linking to a different libc without ugly backwardsness-compatibility hacks, would solve the problem.
Are you uploading the binary or the source and then recompiling? If you are uploading the binary, you are probably running into a library compatibility issue between Debian and CentOS.
If that is the case, upload the source only and recompile on CentOS.
If you do not have permission to compile # CentOS, then try compiling a static binary. You can use dietlibc which makes smaller binaries than glibc or try EGLIBC which is the default C library that Debian will use starting Debian "squeeze".
I came up with the similar problem, it works # Ubuntu 64-bit, but the compile fails # CenseOS 64-bit (REHL5 desktop):
the error message is:
undefined reference to `__isoc99_sscanf#GLIBC_2.7'
when i copied the executable file compiled #Ubuntu to REHL5, and run it another error appeared:
elf file os abi invalid
it is compiled without flag -std=c99, i'm a newbie at C, and looking forword some workarounds, ex. add some flag.
Makefile:
CC=gcc
CCFLAGS= -Wall -O2 -DLINUX -I../include
demos:linuxdemo.c
$(CC) $(CCFLAGS) -o demoA linuxdemo.c -L../lib -lsense4 -lusb
$(CC) $(CCFLAGS) -o demoSO linuxdemo.c -lusb -lsense4
clean:
rm -f demoA
rm -f demoSO
You need to update your glibc to 2.7
download the rpm package from here:
http://archive.fedoraproject.org/pub/archive/fedora/linux/releases/8/Everything/x86_64/os/Packages/
needs:
libc-common-2.7-2.x86_64.rpm
glibc-headers-2.7-2.x86_64.rpm
glibc-devel-2.7-2.x86_64.rpm
glibc-2.7-2.x86_64.rpm
command:
rpm -Uvh --aid --nodeps glibc-common-2.7-2.x86_64.rpm
rpm -Uvh --aid --nodeps glibc-headers-2.7-2.x86_64.rpm
rpm -Uvh --aid --nodeps glibc-devel-2.7-2.x86_64.rpm
rpm -Uvh --aid --nodeps glibc-2.7-2.x86_64.rpm