According to this answer, gcc and g++ have some functional differences. As confirmed by this script, the commands point to the exact same binary, effectively making them duplicates. Why is that so?
$ uname
Darwin
$ md5 `which cc c++ gcc g++ clang clang++`
fac4668657765c8dfe89d8995acfb5a2 /usr/bin/cc
fac4668657765c8dfe89d8995acfb5a2 /usr/bin/c++
fac4668657765c8dfe89d8995acfb5a2 /usr/bin/gcc
fac4668657765c8dfe89d8995acfb5a2 /usr/bin/g++
fac4668657765c8dfe89d8995acfb5a2 /usr/bin/clang
fac4668657765c8dfe89d8995acfb5a2 /usr/bin/clang++
The executable can determine the name it was called with by inspecting the first (or zeroth) command line argument passed to it. By convention it is the name of the executable and is passed by whatever program is invoking the compiler (typically e.g. a shell).
Although it is the same executable, it can then take different actions based on whether or not that value is gcc or g++.
Also, the files you are seeing are unlikely to be duplicate files. They are most likely just (soft or hard) links to the same file.
For the part that clang/clang++ and gcc/g++ seem to be the same, although they are completely different compilers, that is an Apple quirk. They link gcc and g++ to clang and clang++ for some reason, but in reality both refer to Apple clang, which is also different from upstream clang. It often causes confusion (at least for me).
the commands point to the exact same binary, effectively making them duplicates
Yes, they're intended to be the same, and are actually the same single file on disk, given the inode number of them is the same
$ which cc c++ gcc g++ clang clang++ | xargs ls -li
1152921500312779808 -rwxr-xr-x 76 root wheel 167120 May 10 04:30 /usr/bin/c++
1152921500312779808 -rwxr-xr-x 76 root wheel 167120 May 10 04:30 /usr/bin/cc
1152921500312779808 -rwxr-xr-x 76 root wheel 167120 May 10 04:30 /usr/bin/clang
1152921500312779808 -rwxr-xr-x 76 root wheel 167120 May 10 04:30 /usr/bin/clang++
1152921500312779808 -rwxr-xr-x 76 root wheel 167120 May 10 04:30 /usr/bin/g++
1152921500312779808 -rwxr-xr-x 76 root wheel 167120 May 10 04:30 /usr/bin/gcc
On a typical *nix system symlinks are usually used instead of hard links like that
$ ls -al /usr/bin | grep 'vim'
lrwxr-xr-x 1 root wheel 3 May 10 04:30 ex -> vim
lrwxr-xr-x 1 root wheel 3 May 10 04:30 rview -> vim
lrwxr-xr-x 1 root wheel 3 May 10 04:30 rvim -> vim
lrwxr-xr-x 1 root wheel 3 May 10 04:30 vi -> vim
lrwxr-xr-x 1 root wheel 3 May 10 04:30 view -> vim
-rwxr-xr-x 1 root wheel 5056496 May 10 04:30 vim
lrwxr-xr-x 1 root wheel 3 May 10 04:30 vimdiff -> vim
-rwxr-xr-x 1 root wheel 2154 May 10 04:30 vimtutor
That said, in any case the command can be determined easily, regardless of the full executable file, a hard link or a symlink, by checking the command executed which is argv[0] in a typical C or C++ program, or $0 in bash. This is extremely common and one notable usage of it is in BusyBox where almost all POSIX utilities are in a single busybox binary and anything you run like ls, mv, test, rm... will eventually run busybox
But why is gcc and clang the same binary? It's another weird thing in macOS because Apple stopped using/including gcc for more than a decade ago due to licensing issues. They lie to others by telling "clang is gcc" and the only way you can know it is by running gcc --version
OS X: installed gcc links to clang
What is the difference between c++ and g++ on Mac OS X (CommandLineTools)?
How do I make sure that my default C/C++ compiler is GCC
OS X 10.9 gcc links to clang
Related
I started working with c++ a few weeks ago, and I started a new project to start learning more. I'm encountering an issue with an external dependency. I'm trying to use a library called:
libbgp, and I installed it base on their documentation.
Here is my code:
https://gist.github.com/amb1s1/9b2c72294da0ec9416810c8686d3adce
Error:
/usr/bin/ld: /tmp/ccsdO32O.o: in function `ticker(libbgp::BgpFsm&)':
ambgp.cpp:(.text+0xa7): undefined reference to `libbgp::BgpFsm::tick()'
collect2: error: ld returned 1 exit status
I'm not sure if there is anything else that I have to do after installing the lib for the library to be accessible in my source code.
Update
I ran it with the -lbgp flag and when running it, i get the following error:
g++ -lbgp ambgp.cpp -o ambgp
Error:
./ambgp: error while loading shared libraries: libbgp.so.0: cannot open shared object file: No such file or directory
My Lib:
ls -l /usr/local/lib/
-rw-r--r-- 1 root root 10875880 Jan 18 16:56 libbgp.a
-rwxr-xr-x 1 root root 924 Jan 18 16:56 libbgp.la
lrwxrwxrwx 1 root root 15 Jan 18 16:56 libbgp.so -> libbgp.so.0.0.0
lrwxrwxrwx 1 root root 15 Jan 18 16:56 libbgp.so.0 -> libbgp.so.0.0.0
-rwxr-xr-x 1 root root 4291128 Jan 18 16:56 libbgp.so.0.0.0
drwxrwsr-x 3 root staff 4096 Dec 16 19:27 python3.7
echo $LD_LIBRARY_PATH
:/usr/local/lib
Before running the executable, you have to tell it where to find the libgdp.so file, if it is not stored in a standard place such as /usr/lib or /lib. Following should help you:
$ export LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:/usr/local/lib"
$ ./ambgp
If you do not want to export the LD_LIBRARY_PATH each time you start the shell manually, add the line to your /home/<user>/.bashrc file.
Additionally, i think the -lbgp flag should go after the source file in the compiler command (g++ ambgp.cpp -lbgp -o ambgp)
TL;DR :
ld states it cannot find libbgp.so.0, and you wrote in the comments that you found libbgp.so without a trailing .0. So, creating a symlink to the library could help too:
$ sudo ln -s /usr/local/lib/libbgp.so /usr/local/lib/libbgp.so.0
For linking, you need a library file without a trailing .0, but for loading, the library name must have a trailing .0.
The last thing to try is to directly specify the library location to the linker with -Wl,-rpath=/usr/local/lib (as you worked out already !)
I was just trying to explain to someone the difference between compiled and interpreted code, when I was greeted with a
main.cpp:1:10: fatal error: 'iostream' file not found
when calling g++ main.cpp for a simple hello world c++ file.
I looked into this a bit and found ...
JM:Desktop user$ which g++
/usr/local/bin/g++
JM:Desktop user$ ls -al /usr/local/bin/g++
lrwxr-xr-x 1 user admin 47 4 Dez 2018 /usr/local/bin/g++ -> /Library/Developer/CommandLineTools/usr/bin/c++
JM:Desktop user$ ls -al /Library/Developer/CommandLineTools/usr/bin/c++
lrwxr-xr-x 1 root wheel 5 3 Feb 20:29 /Library/Developer/CommandLineTools/usr/bin/c++ -> clang
...that g++ is linked to clang and not clang++ and I therefore call the C-compiler.
I just deleted the Developer tools and installed them again - same thing.
Is this normal or did something mess up my system? Does it make any sense? What am I missing?
Thanks for the help!
It may actually be Homebrew's fault somehow...
JM:Desktop user$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/TeX/texbin
/usr/local/bin is added by Homebrew.
'C++' for example links correctly to clang++ but it is in /usr/bin:
JM:Desktop user$ which c++
/usr/bin/c++
...and so is /usr/bin/g++.
I solved it by just deleting /user/local/bin/g++. The links are still strange.
I've recently updated Xcode to version 10.0 and after that when I try to build version for iOS I've the following problem.
1:04:17: Running steps for project Diasteca...
11:04:17: Starting: "/Users/belladellifabio/Qt/5.11.1/ios/bin/qmake" /Users/belladellifabio/Desktop/QtProjects/Diasteca/mqtt_test/mqtt_test.pro -spec macx-ios-clang CONFIG+=iphoneos CONFIG+=device CONFIG+=qml_debug
Project MESSAGE: This project is using private headers and will therefore be tied to this specific Qt module build version.
Project MESSAGE: Running this project against other versions of the Qt modules may crash at any arbitrary point.
Project MESSAGE: This is not a bug, but a result of using Qt internals. You have been warned!
11:04:18: The process "/Users/belladellifabio/Qt/5.11.1/ios/bin/qmake" exited normally.
11:04:18: Starting: "/usr/bin/make" qmake_all
make: Nothing to be done for `qmake_all'.
11:04:18: The process "/usr/bin/make" exited normally.
11:04:18: Starting: "/usr/bin/make"
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -c -pipe -stdlib=libc++ -g -fPIC -std=gnu++11 -arch arm64 -arch x86_64 -Xarch_arm64 -miphoneos-version-min=12.0 -Xarch_arm64 -isysroot/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS11.3.sdk -Xarch_x86_64 -mios-simulator-version-min=12.0 -Xarch_x86_64 -isysroot/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator11.3.sdk -fobjc-nonfragile-abi -fobjc-legacy-dispatch -fembed-bitcode-marker -Wall -W -DQT_COMPILER_SUPPORTS_SSE2 -DMQTT_TEST_LIBRARY -DQT_DEPRECATED_WARNINGS -DQT_QML_DEBUG -DQT_NETWORK_LIB -DQT_CORE_LIB -I../../Diasteca/mqtt_test -I. -I../../../../Qt/5.11.1/ios/mkspecs/common/uikit -I../../../../Qt/5.11.1/ios/include -I../../../../Qt/5.11.1/ios/include/QtNetwork -I../../../../Qt/5.11.1/ios/include/QtCore/5.11.1 -I../../../../Qt/5.11.1/ios/include/QtCore/5.11.1/QtCore -I../../../../Qt/5.11.1/ios/include/QtCore -I. -I../../../../Qt/5.11.1/ios/mkspecs/macx-ios-clang -o qmqttclient.o ../../Diasteca/mqtt_test/qmqttclient.cpp
clang: warning: no such sysroot directory: '/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS11.3.sdk' [-Wmissing-sysroot]
clang: warning: no such sysroot directory: '/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator11.3.sdk' [-Wmissing-sysroot]
In file included from ../../Diasteca/mqtt_test/qmqttclient.cpp:30:
In file included from ../../Diasteca/mqtt_test/qmqttclient.h:33:
In file included from ../../Diasteca/mqtt_test/qmqttglobal.h:33:
In file included from ../../../../Qt/5.11.1/ios/include/QtCore/qglobal.h:47:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/utility:202:
In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/cstring:61:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/string.h:61:15: fatal error: 'string.h' file not found
Probably the real problem is not the file not found error, but is connected to the fact that qty tries to build the app using an SDK that is no more installed on the system. Is this a qt problem? How could I specify the version of iOS SDK to use to build the app? Is it possible?
Finally, I've found and delete .qmake.cache and .qmake.stash files. I've restart QtCreator and now it seems to work.
Qt stores SDK information somewhere deep in the build output and the .pro.user file.
Remove the user file (you might want to backup your user file in case you have custom build steps), the complete (shadow) build tree and modify your .pro file so that there is no such line as QMAKE_MAC_SDK = macosx10.13.
Then call qmake and build your project again, the inconsistency should be gone.
This occurs when the iOS SDK that Qt is expecting is different than the iOS SDK that you have installed. For instance Qt 5.13.1 expects iPhoneOS13.1.sdk but my Xcode currently has iPhoneOS13.2.sdk:
$ cd /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs
$ ls -l
total 0
drwxrwxr-x 7 root wheel 224 Nov 5 2019 iPhoneOS.sdk
lrwxr-xr-x 1 root wheel 12 Jan 15 2020 iPhoneOS13.2.sdk -> iPhoneOS.sdk
$ cd /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs
$ ls -l
total 0
drwxrwxr-x 8 root wheel 256 Jul 22 14:14 iPhoneSimulator.sdk
lrwxr-xr-x 1 root wheel 19 Jan 15 2020 iPhoneSimulator13.2.sdk -> iPhoneSimulator.sdk
To remedy this, we can get Qt to use the iPhoneOS13.2.sdk:
$ cd /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs
$ ls -l
total 0
drwxrwxr-x 7 root wheel 224 Nov 5 2019 iPhoneOS.sdk
lrwxr-xr-x 1 root wheel 12 Jan 15 2020 iPhoneOS13.2.sdk -> iPhoneOS.sdk
$ sudo ln -s iPhoneOS.sdk iPhoneOS13.1.sdk
$ ls -l
total 0
drwxrwxr-x 8 root wheel 256 Jul 22 14:20 iPhoneOS.sdk
lrwxr-xr-x 1 root wheel 12 Jul 22 14:20 iPhoneOS13.1.sdk -> iPhoneOS.sdk
lrwxr-xr-x 1 root wheel 12 Jan 15 2020 iPhoneOS13.2.sdk -> iPhoneOS.sdk
$ cd /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs
$ ls -l
total 0
drwxrwxr-x 8 root wheel 256 Jul 22 14:14 iPhoneSimulator.sdk
lrwxr-xr-x 1 root wheel 19 Jan 15 2020 iPhoneSimulator13.2.sdk -> iPhoneSimulator.sdk
$ sudo ln -s iPhoneSimulator.sdk iPhoneSimulator13.1.sdk
$ ls -l
total 0
drwxrwxr-x 8 root wheel 256 Jul 22 14:14 iPhoneSimulator.sdk
lrwxr-xr-x 1 root wheel 19 Jul 22 14:39 iPhoneSimulator13.1.sdk -> iPhoneSimulator.sdk
lrwxr-xr-x 1 root wheel 19 Jan 15 2020 iPhoneSimulator13.2.sdk -> iPhoneSimulator.sdk
I met a similar problem, because my xcode project was created by different XCode SDK, and it's generated by CMake, so I deleted the cache and solved the problem.
Following this howto I'm cross-compiling a bluetooth application for Raspberry Pi (ARM). When I try to link with libbluetooth I get the error below. Even the simplest helloworld application (without bluetooth code) won't link.
arm-linux-gnueabihf-g++ -c hello.cpp -o hello.o
arm-linux-gnueabihf-g++ hello.o -o hello -lbluetooth -L/home/sbf/raspberrypi/rootfs/usr/lib/arm-linux-gnueabihf
/home/sbf/raspberrypi/rootfs/usr/lib/arm-linux-gnueabihf/libbluetooth.so: undefined reference to `__fdelt_chk#GLIBC_2.15'
sbf#sbf-VirtualBox ~/raspberrypi/projects/test $ ls -al /home/sbf/raspberrypi/rootfs/usr/lib/arm-linux-gnueabihf/libbluetooth*
-rw-r--r-- 1 sbf sbf 132886 May 27 2016 /home/sbf/raspberrypi/rootfs/usr/lib/arm-linux-gnueabihf/libbluetooth.a
lrwxrwxrwx 1 sbf sbf 23 Nov 24 21:20 /home/sbf/raspberrypi/rootfs/usr/lib/arm-linux-gnueabihf/libbluetooth.so -> libbluetooth.so.3.17.11
lrwxrwxrwx 1 sbf sbf 23 Nov 24 21:20 /home/sbf/raspberrypi/rootfs/usr/lib/arm-linux-gnueabihf/libbluetooth.so.3 -> libbluetooth.so.3.17.11
-rw-r--r-- 1 sbf sbf 103376 May 27 2016 /home/sbf/raspberrypi/rootfs/usr/lib/arm-linux-gnueabihf/libbluetooth.so.3.17.11
Edit (added):
GLIBC Version 2.19
pi#raspberrypi:~ $ ldd --version
ldd (Debian GLIBC 2.19-18+deb8u6) 2.19
What's going wrong?
I was experiencing the same issue yesterday trying to link libbluetooth using raspberry pi tools.
To solve this I downloaded a newer version of Linaro dev tools (6.1.1) than what is supplied by the raspberry pi tools repository.
Here is the link to the latest linaro toolchain release
Download "gcc-linaro-6.1.1-2016.08-x86_64_arm-linux-gnueabihf.tar.xz" and put that folder in your raspberrypi/tools/arm-bcm2708/ directory along with the other toolchains.
Then set compiler/linker paths to point to the new directory.
(I am using cmake)
SET(CMAKE_C_COMPILER $ENV{HOME}/raspberrypi/tools/arm-bcm2708/gcc-linaro-6.1.1-2016.08-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf-gcc)
SET(CMAKE_CXX_COMPILER $ENV{HOME}/raspberrypi/tools/arm-bcm2708/gcc-linaro-6.1.1-2016.08-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf-g++)
(edit) I had trouble running my executable with this version of the toolchain compiled since jessie doesn't support gcc versions 5 or 6. Instead try using this release https://releases.linaro.org/components/toolchain/binaries/4.9-2016.02/arm-linux-gnueabihf/
When I tried to compile a [.cpp] file to [.swc] file, I got this:
dyld: Library not loaded: /usr/lib/libltdl.3.dylib
And I found that my libltdl is
Poechant:src poechant$ ls -l /usr/lib/libltdl.*
lrwxr-xr-x 1 root wheel 15 10 11 08:17 /usr/lib/libltdl.7.2.2.dylib -> libltdl.7.dylib
-rwxr-xr-x 1 root wheel 88848 10 11 08:17 /usr/lib/libltdl.7.dylib
lrwxr-xr-x 1 root wheel 15 10 11 08:17 /usr/lib/libltdl.dylib -> libltdl.7.dylib
How to solve it?
According to the post here
http://forums.adobe.com/message/3892045:
The following set of commands would work( i tested, too )
cd /usr/lib/
sudo ln -s libltdl.7.dylib libltdl.3.dylib