I am trying to compile Qscintilla 2.9.3 (obtained here) on mac (OS X 10.11.6), but the make step fails with the following error :
/Applications/Xcode.app/Contents/Developer/usr/bin/g++ -c -pipe -O2 -std=gnu++11 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk -mmacosx-version-min=10.8 -fvisibility=hidden -fvisibility-inlines-hidden -w -fPIC -DQSCINTILLA_MAKE_DLL -DSCINTILLA_QT -DSCI_LEXER -DQT_NO_DEBUG -DQT_PRINTSUPPORT_LIB -DQT_WIDGETS_LIB -DQT_MACEXTRAS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -I. -I. -I../include -I../lexlib -I../src -I/Applications/Utilities/Qt/5.7/clang_64/lib/QtPrintSupport.framework/Headers -I/Applications/Utilities/Qt/5.7/clang_64/lib/QtWidgets.framework/Headers -I/Applications/Utilities/Qt/5.7/clang_64/lib/QtMacExtras.framework/Headers -I/Applications/Utilities/Qt/5.7/clang_64/lib/QtGui.framework/Headers -I/Applications/Utilities/Qt/5.7/clang_64/lib/QtCore.framework/Headers -I. -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/System/Library/Frameworks/OpenGL.framework/Headers -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/System/Library/Frameworks/AGL.framework/Headers -I/Applications/Utilities/Qt/5.7/clang_64/mkspecs/macx-g++ -F/Applications/Utilities/Qt/5.7/clang_64/lib -o qsciscintilla.o qsciscintilla.cpp
In file included from qsciscintilla.cpp:23:
In file included from ./Qsci/qsciscintilla.h:29:
In file included from /Applications/Utilities/Qt/5.7/clang_64/lib/QtCore.framework/Headers/QByteArray:1:
In file included from /Applications/Utilities/Qt/5.7/clang_64/lib/QtCore.framework/Headers/qbytearray.h:44:
In file included from /Applications/Utilities/Qt/5.7/clang_64/lib/QtCore.framework/Headers/qrefcount.h:43:
In file included from /Applications/Utilities/Qt/5.7/clang_64/lib/QtCore.framework/Headers/qatomic.h:41:
In file included from /Applications/Utilities/Qt/5.7/clang_64/lib/QtCore.framework/Headers/qglobal.h:1145:
In file included from /Applications/Utilities/Qt/5.7/clang_64/lib/QtCore.framework/Headers/qatomic.h:46:
/Applications/Utilities/Qt/5.7/clang_64/lib/QtCore.framework/Headers/qbasicatomic.h:61:4: error:
"Qt requires C++11 support"
# error "Qt requires C++11 support"
^
/Applications/Utilities/Qt/5.7/clang_64/lib/QtCore.framework/Headers/qbasicatomic.h:90:13: error:
unknown type name 'QAtomicOps'
typedef QAtomicOps Ops;
Following other questions on the subject, I have added
\# With C++11 support
greaterThan(QT_MAJOR_VERSION, 4){
CONFIG += c++11
} else {
QMAKE_CXXFLAGS += -std=c++0x
}
in the qscintilla.pro file, to no avail.
This thread seems to show a similar problem. It was solved by suppressing an -ansi flag in a dependency, which prevented the use of c++11. However I do not see such a flag in the log above.
Do you have an idea as to what could cause that problem ?
I have QMake version 3.0 and Qt 5.7.
Thanks to the remarks above regarding the compiler used, I found on this thread that in order to use c++11 with clang/llvm on Mac, it is necessary to also use the library -stdlib=libc++ instead of the old libstdc++.
The problem was thus solved by adding
QMAKE_LFLAGS += -stdlib=libc++
QMAKE_CXXFLAGS += -stdlib=libc++
to the .pro file.
Related
I have a pretty simple CMake-based project that builds one lib and a small executable that uses it. It builds fine on Linux with GCC, but fails on Mac OS with loads of errors of the following kind. The inciting line of code in main.cpp is the second one here:
#include <cstdlib>
#include <memory>
The first of many similar errors:
[build] In file included from /Users/me/data/series2server/main.cpp:2:
[build] In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/usr/include/c++/v1/memory:671:
[build] /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk/usr/include/c++/v1/__algorithm/search.h:34:19: error: no member named 'make_pair' in namespace 'std::__1'
[build] return _VSTD::make_pair(__first1, __first1); // Everything matches an empty sequence
This appears to be a mismatch between Clang and GCC uses of std. But I can't figure out why CMake is configuring things to call clang++ but putting "std=gnu++14" in the compiler invocation. I did a full-text search for "std=gnu" in the whole source tree and didn't find it. I do see this in various CMakeLists.txt files:
set( CMAKE_CXX_STANDARD 14 )
A compiler invocation is below. Where might I look for where this gnu option is specified? Thanks!
[build] cd /Users/me/data/series2server/build/restbed && /usr/bin/clang++ -DBUILD_SSL -I/Users/me/data/series2server/restbed/source -isystem /Users/me/data/series2server/restbed/dependency/asio/asio/include -isystem /Users/me/data/series2server/restbed/dependency/openssl/include -Wall -Wextra -Weffc++ -pedantic -Wno-unknown-pragmas -Wno-deprecated-declarations -Wno-non-virtual-dtor -DASIO_STANDALONE=YES -Wno-deprecated-declarations -g -arch arm64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk -std=gnu++14 -MD -MT restbed/CMakeFiles/restbed-static.dir/source/corvusoft/restbed/detail/service_impl.cpp.o -MF CMakeFiles/restbed-static.dir/source/corvusoft/restbed/detail/service_impl.cpp.o.d -o CMakeFiles/restbed-static.dir/source/corvusoft/restbed/detail/service_impl.cpp.o -c /Users/me/data/series2server/restbed/source/corvusoft/restbed/detail/service_impl.cpp
From n.m.'s comment 10 years ago, for clarity:
set( CMAKE_CXX_STANDARD 14 ) sets gcc or clang flag to -std=gnu++14, unless CXX_EXTENSIONS property (or CMAKE_CXX_EXTENSIONS variable) is set to OFF.
Im using poky version of yocto, and adding zbar library in my yocto build. I found a readymade recipe at http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-support/zbar/zbar_0.10.bb and modified it a bit to get working with poky. I got it working fine with imagemagick, and the compiled zbarimg works on the target board.
The modified recipe is available here: http://paste.ubuntu.com/25725000/
When I proceed configuring python support (--with-python) to the build, some dependency issues crept up, which Im unable to resolve.
It appears as if the compiler doesn't find the appropriate headers, since the include paths don't contain appropriate folder.
The full compiler command is:
arm-poky-linux-gnueabi-libtool: compile: arm-poky-linux-gnueabi-gcc -march=armv7-a -mfloat-abi=hard -mfpu=neon -mtune=cortex-a7 --sysroot=/home/jlumme/imx_build/build-x11-pico-imx6ul/tmp/sysroots/pico-imx6ul-emmc -DHAVE_CONFIG_H -I. -I/home/jlumme/imx_build/build-x11-pico-imx6ul/tmp/work/cortexa7hf-vfp-neon-poky-linux-gnueabi/zbar/0.10-r0/zbar-0.10 -I./include -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -D_FORTIFY_SOURCE=2 -g -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -I/usr/include/python2.7 -I/usr/include/python2.7 -I/home/jlumme/imx_build/build-x11-pico-imx6ul/tmp/work/cortexa7hf-vfp-neon-poky-linux-gnueabi/zbar/0.10-r0/zbar-0.10/include -Wall -Wno-parentheses -O2 -pipe -g -feliminate-unused-debug-types -c /home/jlumme/imx_build/build-x11-pico-imx6ul/tmp/work/cortexa7hf-vfp-neon-poky-linux-gnueabi/zbar/0.10-r0/zbar-0.10/python/symbol.c -fPIC -DPIC -o python/.libs/python_zbar_la-symbol.o
You can see that sysroot variable is set, and it appears like the right location, and there is /usr/include/python2.7 there, though its pointing right at the host system include path.
There is a warning from compiler: cc1: warning: include location "/usr/include/python2.7" is unsafe for cross-compilation [-Wpoison-system-directories] which I don't know why it happens, but it seems like the python2.7 folder is appropriately looked at, just not under the sysroot (my host system doesn't have /usr/lib/python2.7)
If I go to the sysroot include (/home/jlumme/imx_build/build-x11-pico-imx6ul/tmp/sysroots/pico-imx6ul-emmc/usr/include/) folder, I can see that it has a subfolder python2.7. If under this usr/include folder I add a symlink Python.h -> python2.7/Python.h, the compiler will complain about the next header file which is not found.
So to me it seems, all I should do is add the appropriate 'sysroot' + usr/include/python2.7 as include search folder it would compile happily - but Im not sure how..
The full compilation log is available here: http://paste.ubuntu.com/25725014/
This is a bug in the zbar configure script.
Try inheriting pythonnative so the configure script can run a compatible Python to know where to look.
I'm trying to build clang, with all library static linked in. So that I can run it on CentOS 6 with ancient GCC 4.4 version.
At first, I think adding the option -static by turning on LLVM_BUILD_STATIC is enough. But in the link stage, it errors out.
dynamic STT_GNU_IFUNC symbol `strcmp' with pointer equality in `/usr/lib/../lib64/libc.a(strcmp.o)' can not be used when making an executable; recompile with -fPIE and relink with -pie
So, I add -fPIE -Wl,-pie to CMAKE_CXX_FLAGS, and it says
-- Performing Test HAVE_CXX_ATOMICS_WITH_LIB
-- Performing Test HAVE_CXX_ATOMICS_WITH_LIB - Failed
CMake Error at cmake/modules/CheckAtomic.cmake:49 (message):
Host compiler must support std::atomic!
Call Stack (most recent call first):
cmake/config-ix.cmake:307 (include)
CMakeLists.txt:590 (include)
I checked the cmake/modules/CheckAtomic.cmake file, It compiles the following code
#include <atomic>
std::atomic<float> x(0.0f);
int main() { return (float)x; }
with command
/home/hailin/gcc-4.8.3-boost-1.55/rtf/bin/g++ -fPIE -Wl,-pie -DHAVE_CXX_ATOMICS_WITHOUT_LIB -std=c++11 -static -lm
/home/hailin/gcc-4.8.3-boost-1.55/rtf/bin/g++ -fPIE -Wl,-pie -DHAVE_CXX_ATOMICS_WITH_LIB -std=c++11 -static -lm -latomic
The command with option -Wl,-pie reproduce the same error.
It seems like a dead end. Is there any conflict between -shared and -fPIE -Wl,-pie ?
Old question, but in case someone else hits it: apparently you need to pass -pie to the compiler driver (gcc/g++), not just the linker (-Wl,-pie). Some startup object files differ for PIE (e.g. Scrt1.o instead of crt1.o) and these are passed by the driver to the linker, so the driver needs to know that you're making a PIE.
Running the build script from ELLCC results in this error
gcc -DHAVE_CONFIG_H -I. -I../../../src/binutils/binutils -I. -I../../../src/binutils/binutils -I../bfd -I../../../src/binutils/binutils/../bfd -I../../../src/binutils/binutils/../include -I./../intl -DLOCALEDIR="\"/Library/Caches/Homebrew/ellcc--svn-HEAD/lib/share/locale\"" -Dbin_dummy_emulation=bin_vanilla_emulation -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -Wno-unused-value -Wno-shadow -MT nm.o -MD -MP -MF .deps/nm.Tpo -c -o nm.o ../../../src/binutils/binutils/nm.c
../../../src/binutils/binutils/nm.c:1690:28: error: 'sbrk' is deprecated
[-Werror,-Wdeprecated-declarations]
char *lim = (char *) sbrk (0);
^
/usr/include/unistd.h:582:7: note: 'sbrk' declared here
void *sbrk(int);
^
The following compilers have been used with the same result:
gcc 4.8
llvm-gcc 2.8
llvm 3.3
I had the same issue compiling binutils-2.24 on Mac OSX Mavericks 13.2.0 with clang. Thanks to Richard Pennington's suggestion, I was able to get binutils to compile by specifying a few other -Wno-error arguments to gcc by setting CFLAGS before running configure. Namely, these are the commands I ran to build and install binutils:
CFLAGS="-Wno-error=deprecated-declarations -Wno-error=unused-variable -Wno-error=unused-function" ./configure --prefix=/usr/local/toolchain-arm-linux-elf --target=arm-linux-elf
make
make install
EDIT: I just noticed that the binutils configure script accepts an --disable-werror argument, which disables gcc turning warnings into errors, and removes the need for the settings CFLAGS. With this argument, building could be done as follows:
./configure --prefix=/usr/local/toolchain-arm-linux-elf --target=arm-linux-elf --disable-werror
make
make install
This error is occurring because sbrk() is deprecated on OSX, -Werror is enabled for the binutils build, and the compiler (in this case "gcc" is an alias for clang) rightly complains about the use of sbrk(). I'll be looking into eliminating this error this weekend when I won't have to be at my day job. ;-)
I looked into it a bit more. This happened because the latest version of OS X (Mavericks) uses clang as its compiler and /usr/include/unistd.h has a deprecated declaration of sbrk().
The solution was to add a -Wno-error=deprecated-declarations option to the CFLAGS for binutils. I also had to make a few other changes to complete the Max OS build. You can find the latest stuff in the ELLCC subversion tree.
I'm using GCC 4.7.2 and LD 2.23 but when I add -flto to my compile options my compile time increases by over 20%! The manual seems to indicate that -fuse-linker-plugin is needed for the optimization to work. It also says that it's enabled by default with -flto but when I add it explicitly I see the following error in the link command:
g++: error: -fuse-linker-plugin is not supported in this configuration
According to manual, it should be supported by LD 2.21 or greater. Any idea why I'm getting this error? For reference here are examples of my full compile commands:
g++ -Wall -pipe -O3 -flto -fno-strict-aliasing -mtune=generic --no-exceptions -fPIC -c some.cc
g++ -o exec -Xlinker some1.o some2.o -static some1.a some2.a -Wl,--wrap,open -flto -fuse-linker-plugin
Running 'ld --help | grep plugin' shows "-plugin" option so I don't understand why GCC is complaining:
-plugin PLUGIN Load named plugin
-plugin-opt ARG Send arg to last-loaded plugin
Link time optimizations aren't supposed to reduce compilation time, but optimize runtime of your program.
#options, just add "-flto -fuse-linker-plugin" to your CFLAGS(or CXXFLAGS for c++) and LDFLAGS and it should work just fine.
#gold: ld --version is probably gonna return gnu LD, to switch to gold, make ld symlink which ld point to which ld.gold
e.g. ln -s /usr/bin/ld.gold /usr/bin/ld