I'm trying to build the OpenSceneGraph for iOS as specified in the README file.
cmake -G Xcode \
-D OSG_BUILD_PLATFORM_IPHONE:BOOL=ON \
-D CMAKE_CXX_FLAGS:STRING="-ftree-vectorize -fvisibility-inlines-hidden -mno-thumb -arch armv6 -pipe -no-cpp-precomp -miphoneos-version-min=3.2 -mno-thumb" \
-D BUILD_OSG_APPLICATIONS:BOOL=OFF \
-D OSG_BUILD_FRAMEWORKS:BOOL=OFF \
-D OSG_WINDOWING_SYSTEM:STRING=IOS \
-D OSG_BUILD_PLATFORM_IPHONE:BOOL=ON \
-D CMAKE_OSX_ARCHITECTURES:STRING="armv6;armv7" \
-D CMAKE_OSX_SYSROOT:STRING=/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.3.sdk \
-D OSG_GL1_AVAILABLE:BOOL=OFF \
-D OSG_GL2_AVAILABLE:BOOL=OFF \
-D OSG_GLES1_AVAILABLE:BOOL=ON \
-D OSG_GL_DISPLAYLISTS_AVAILABLE:BOOL=OFF \
-D OSG_GL_FIXED_FUNCTION_AVAILABLE:BOOL=ON \
-D OSG_GL_LIBRARY_STATIC:BOOL=OFF \
-D OSG_GL_MATRICES_AVAILABLE:BOOL=ON \
-D OSG_GL_VERTEX_ARRAY_FUNCS_AVAILABLE:BOOL=ON \
-D OSG_GL_VERTEX_FUNCS_AVAILABLE:BOOL=OFF \
-D DYNAMIC_OPENSCENEGRAPH:BOOL=OFF \
-D DYNAMIC_OPENTHREADS:BOOL=OFF .
But I'm getting following error.
-- The C compiler identification is GNU
-- The CXX compiler identification is unknown
-- Checking whether C compiler has -isysroot
-- Checking whether C compiler has -isysroot - yes
-- Checking whether C compiler supports OSX deployment target flag
-- Checking whether C compiler supports OSX deployment target flag - yes
-- Check for working C compiler using: Xcode
-- Check for working C compiler using: Xcode -- broken
CMake Error at /opt/local/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake:52 (MESSAGE):
The C compiler "/usr/bin/gcc" is not able to compile a simple test program.
It fails with the following output:
Change Dir: /Volumes/MY_DATA/AugmentedReality/osg/OpenSceneGraph-3.0.1/CMakeFiles/CMakeTmp
Run Build Command:/opt/local/bin/cmakexbuild -project
CMAKE_TRY_COMPILE.xcodeproj build -target cmTryCompileExec -configuration
Debug
=== BUILD NATIVE TARGET cmTryCompileExec OF PROJECT CMAKE_TRY_COMPILE WITH
CONFIGURATION Debug ===
Check dependencies
target specifies product type 'com.apple.product-type.tool', but there's no
such product type for the 'iphoneos' platform
** BUILD FAILED **
The following build commands failed:
Check dependencies
(1 failure)
CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
CMakeLists.txt:30 (PROJECT)
-- Configuring incomplete, errors occurred!
What might cause this and how do I solve it?
I'm trying to do the same thing and get a similar error. I found the following post indicating cmake is not yet compatible with Xcode 4 when building for iOS:
http://forum.openscenegraph.org/viewtopic.php?t=9034
Related
I tried to manage the gtest package by conan in my project. The conanfile.txt is as follow:
[requires]
gtest/1.10.0
[generators]
cmake
And my CMakeLists.txt is as follow:
cmake_minimum_required(VERSION 3.5)
project(TinyWebServer)
include(${CMAKE_BINARY_DIR}/conanbuildinfo.cmake)
conan_basic_setup()
set(CMAKE_CXX_STANDARD 11)
set(THREADS_PREFER_PTHREAD_FLAG ON)
find_package(Threads REQUIRED)
if("${CMAKE_CXX_COMPILER_ID}" STREQUAL "Clang")
add_compile_options(-Wthread-safety )
endif()
add_compile_options(
# -DVALGRIND
-DCHECK_PTHREAD_RETURN_VALUE
-D_FILE_OFFSET_BITS=64
-Wall
-Wno-unused-parameter
-Woverloaded-virtual
-Wpointer-arith
-Wwrite-strings
)
enable_testing()
add_subdirectory(Logger)
add_subdirectory(Tools)
add_subdirectory(Pools)
add_subdirectory(Http)
add_subdirectory(Timer)
add_subdirectory(Net)
add_subdirectory(Test)
add_executable(${PROJECT_NAME} main.cc Config.cc)
target_link_libraries(${PROJECT_NAME}
Threads::Threads
Log::lib
Tools::lib
Pools::lib
Http::lib
Net::lib
Timer::lib
)
install(TARGETS ${PROJECT_NAME} DESTINATION ${CMAKE_SOURCE_DIR})
When I use command which is shown below to build my project, everything goes well.
mkdir -p build/
cd build/
conan install .. --build missing -s compiler=clang -s compiler.version=3.8 -s compiler.libcxx=libstdc++11 -s build_type=Release
cmake .. -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_BUILD_TYPE=Release
make install -j4
But when I switched the build_type option from Release to Debug, just like :
conan install .. --build missing -s compiler=clang -s compiler.version=3.8 -s compiler.libcxx=libstdc++11 -s build_type=Debug
I got some error message :
phoenix#phoenix-virtual-machine:~/MyProject/MyTinyWebServer/build$ conan install .. --build missing -s compiler=clang -s compiler.version=3.8 -s compiler.libcxx=libstdc++11 -s build_type=Debug
Configuration:
[settings]
arch=x86_64
arch_build=x86_64
build_type=Debug
compiler=clang
compiler.libcxx=libstdc++11
compiler.version=3.8
os=Linux
os_build=Linux
[options]
[build_requires]
[env]
gtest/1.10.0: WARN: Package is corrupted, removing folder: /home/phoenix/.conan/data/gtest/1.10.0/_/_/package/d5608ac34c43db836b618b9cfd33cb77c7dec959
conanfile.txt: Installing package
Requirements
gtest/1.10.0 from 'conan-center' - Cache
Packages
gtest/1.10.0:d5608ac34c43db836b618b9cfd33cb77c7dec959 - Build
Installing (downloading, building) binaries...
gtest/1.10.0: WARN: Build folder is dirty, removing it: /home/phoenix/.conan/data/gtest/1.10.0/_/_/build/d5608ac34c43db836b618b9cfd33cb77c7dec959
gtest/1.10.0: Copying sources to build folder
gtest/1.10.0: Building your package in /home/phoenix/.conan/data/gtest/1.10.0/_/_/build/d5608ac34c43db836b618b9cfd33cb77c7dec959
gtest/1.10.0: Generator cmake created conanbuildinfo.cmake
gtest/1.10.0: Calling build()
-- The C compiler identification is GNU 5.4.0
-- The CXX compiler identification is GNU 5.4.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Conan: called by CMake conan helper
-- Conan: called inside local cache
-- Conan: Adjusting output directories
-- Conan: Using cmake global configuration
-- Conan: Adjusting default RPATHs Conan policies
-- Conan: Adjusting language standard
-- Conan: Adjusting fPIC flag (ON)
CMake Error at conanbuildinfo.cmake:578 (message):
Incorrect 'clang', is not the one detected by CMake: 'GNU'
Call Stack (most recent call first):
conanbuildinfo.cmake:141 (conan_check_compiler)
CMakeLists.txt:5 (conan_basic_setup)
-- Configuring incomplete, errors occurred!
See also "/home/phoenix/.conan/data/gtest/1.10.0/_/_/build/d5608ac34c43db836b618b9cfd33cb77c7dec959/CMakeFiles/CMakeOutput.log".
gtest/1.10.0:
gtest/1.10.0: ERROR: Package 'd5608ac34c43db836b618b9cfd33cb77c7dec959' build failed
gtest/1.10.0: WARN: Build folder /home/phoenix/.conan/data/gtest/1.10.0/_/_/build/d5608ac34c43db836b618b9cfd33cb77c7dec959
ERROR: gtest/1.10.0: Error in build() method, line 59
cmake = self._configure_cmake()
while calling '_configure_cmake', line 53
cmake.configure()
ConanException: Error 1 while executing cd '/home/phoenix/.conan/data/gtest/1.10.0/_/_/build/d5608ac34c43db836b618b9cfd33cb77c7dec959' && cmake -G "Unix Makefiles" -DCMAKE_BUILD_TYPE="Debug" -DCONAN_IN_LOCAL_CACHE="ON" -DCONAN_COMPILER="clang" -DCONAN_COMPILER_VERSION="3.8" -DCONAN_CXX_FLAGS="-m64" -DCONAN_SHARED_LINKER_FLAGS="-m64" -DCONAN_C_FLAGS="-m64" -DCONAN_LIBCXX="libstdc++11" -DBUILD_SHARED_LIBS="OFF" -DCMAKE_INSTALL_PREFIX="/home/phoenix/.conan/data/gtest/1.10.0/_/_/package/d5608ac34c43db836b618b9cfd33cb77c7dec959" -DCMAKE_INSTALL_BINDIR="bin" -DCMAKE_INSTALL_SBINDIR="bin" -DCMAKE_INSTALL_LIBEXECDIR="bin" -DCMAKE_INSTALL_LIBDIR="lib" -DCMAKE_INSTALL_INCLUDEDIR="include" -DCMAKE_INSTALL_OLDINCLUDEDIR="include" -DCMAKE_INSTALL_DATAROOTDIR="share" -DCONAN_CMAKE_POSITION_INDEPENDENT_CODE="ON" -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY="ON" -DCONAN_EXPORTED="1" -DCUSTOM_DEBUG_POSTFIX="d" -DBUILD_GMOCK="True" -DGTEST_NO_MAIN="False" -Dgtest_hide_internal_symbols="False" -Wno-dev '/home/phoenix/.conan/data/gtest/1.10.0/_/_/build/d5608ac34c43db836b618b9cfd33cb77c7dec959'
That really makes me confuse. The command conan install .. --build missing -s compiler=clang -s compiler.version=3.8 -s compiler.libcxx=libstdc++11 -s build_type=Debug has specified the compiler to be clang. But from the message Incorrect 'clang', is not the one detected by CMake: 'GNU', it looks as if the conan detected the gcc compiler. Why this happend? And how should I do if I want to build my project to a debug version?
Thanks~
Oh, I think I have made some mistakes. To use conan install the gtest package and to build my project to debug version are two totally different things. So if I want to build my project to a debug version, I should use comand like this:
conan install .. --build missing -s compiler=clang -s compiler.version=3.8 -s compiler.libcxx=libstdc++11 -s build_type=Release
cmake .. -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_BUILD_TYPE=Debug
That the version of gtest is Release doesn't prevent me me from compiling my project to the debug version. 😅
1.conanfile.txt
[generators]
cmake
virtualenv
2.after conan install,use env
source activate.sh
cmake ..
3.quit env
source deactivate.sh
This is not a duplicate of ncurses not found when trying to build vim. ncurses not found when trying to build vim shows how to solve a problem, while I'm asking why it is a problem.
I want to build vim from source. Used a following command line to do it:
./configure --with-features=huge \
--enable-multibyte \
--enable-rubyinterp=yes \
--enable-pythoninterp=yes \
--with-python-config-dir=/usr/lib64/python2.7/config \
--enable-python3interp=yes \
--with-python3-config-dir=/usr/lib64/python3.6/config-3.6m-x86_64-linux-gnu \
--enable-perlinterp=yes \
--enable-luainterp=yes \
--enable-cscope \
--prefix=/usr/local
Got the follow error:
checking --with-tlib argument... empty: automatic terminal library selection
checking for tgetent in -ltinfo... yes
tinfo library is not usable
checking for tgetent in -lncurses... yes
ncurses library is not usable
checking for tgetent in -ltermlib... no
checking for tgetent in -ltermcap... yes
termcap library is not usable
checking for tgetent in -lcurses... yes
curses library is not usable
no terminal library found
checking for tgetent()... configure: error: NOT FOUND!
You need to install a terminal library; for example ncurses.
Or specify the name of the library with --with-tlib.
I do have curses library installed
Here is what find /usr -type f -name "libncurses*" revealed
/usr/lib/libncursesw.so.6.1
/usr/lib/libncurses.so.6.1
/usr/lib64/libncurses++w.so.5.9
/usr/lib64/libncurses++w.so.6.1
/usr/lib64/libncursesw.so.5.9
/usr/lib64/libncurses++.so.5.9
/usr/lib64/libncursesw.so.6.1
/usr/lib64/libncurses.so
/usr/lib64/vlc/plugins/gui/libncurses_plugin.so
/usr/lib64/libncurses.so.6.1
/usr/lib64/libncurses.so.5.9
/usr/lib64/libncursesw.so
/usr/lib64/libncurses++.so.6.1
After several hours of googling I tried the following approach
CFLAGS+=-fPIC ./configure --with-features=huge \
--enable-multibyte \
--enable-rubyinterp=yes \
--enable-pythoninterp=yes \
--with-python-config-dir=/usr/lib64/python2.7/config \
--enable-python3interp=yes \
--with-python3-config-dir=/usr/lib64/python3.6/config-3.6m-x86_64-linux-gnu \
--enable-perlinterp=yes \
--enable-luainterp=yes \
--enable-cscope \
--prefix=/usr/local
i.e. I simply added a CFLAGS+=-fPIC. I know what the flag does. However I fail to see a connection between this flag and my ncurses library being unusable.
So my questions are:
What makes my ncurses library unusable?
Why using -fPIC works?
My system:
$ uname -a
Linux user-fedora-PC0PVGAT 4.18.16-200.fc28.x86_64 #1 SMP Sat Oct 20 23:53:47 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
$ cat /etc/os-release
NAME=Fedora
VERSION="28 (Workstation Edition)"
ID=fedora
VERSION_ID=28
PLATFORM_ID="platform:f28"
PRETTY_NAME="Fedora 28 (Workstation Edition)"
ANSI_COLOR="0;34"
CPE_NAME="cpe:/o:fedoraproject:fedora:28"
HOME_URL="https://fedoraproject.org/"
SUPPORT_URL="https://fedoraproject.org/wiki/Communicating_and_getting_help"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Fedora"
REDHAT_BUGZILLA_PRODUCT_VERSION=28
REDHAT_SUPPORT_PRODUCT="Fedora"
REDHAT_SUPPORT_PRODUCT_VERSION=28
PRIVACY_POLICY_URL="https://fedoraproject.org/wiki/Legal:PrivacyPolicy"
VARIANT="Workstation Edition"
VARIANT_ID=workstation
I encountered the same question, and, solve it by replace compiler to clang like that:
CC=clang CXX=clang++ LD=clang LDFLAGS=-fno-lto ./configure ....
How to deal with? I tried with the following steps:
Check src/auto/config.log
Found an abnormal hint usr/bin/ld: output.o: relocation R_X86_64_32 against '.rodata.str1.1' can not be used when maki
then remember the first time I installed vim about 1 year ago, with above clang options...
Finnally, if the method above does not work, try to use the shared object form of libpython.
hope to help you~
I am working though the Linux from scratch book when I encountered an error configuring Glibc (step 5.7):
checking for sysdeps preconfigure fragments... aarch64 alpha arm configure: error: Old ABI no longer supported
I am using:
../glibc-2.20/configure \
--prefix=/tools \
--host=$LFS_TGT \
--build=$(../glibc-2.20/scripts/config.guess) \
--disable-profile \
--enable-kernel=2.6.32 \
--with-headers=/tools/include \
libc_cv_forced_unwind=yes \
libc_cv_ctors_header=yes \
libc_cv_c_cleanup=yes
I have had no trouble until now. My $LFS_TGT=armv6l-lfs-linux-gnueabihf
you should upgrade to the latest glibc release. most likely you don't have a compiler yet, so when glibc attempts to run a compile test, it fails and assumes you're trying to use an OABI toolchain.
this was fixed here:
https://sourceware.org/git/?p=glibc.git;a=commit;h=34d97d87bb1c08e34d08a9d4be24a3b1d53a4ddb
I have a project in QtCreator that contains .c and .cpp files and now builds and run fine under my current toolchain GCC.
I want to port this code to run it on arm5 core running linux angstrom distribution.
To do that:
1-I need get QTlibraries built with linux-armv5te-linux-gnueabi-toolchain for example,
2- make a new project in QT and add this version of qt to it.
3- add linux-armv5te-linux-gnueabi-toolchain in the toolchain path of qtcreator so I can build my code with it.
4- when I press build, qmake will generate a makefile that willuse this linux-armv5te-linux-gnueabi-toolchain to compile the .c files with gcc and the .cpp files with g++.
Am I correct with my logic?
Also, how can I perform step1 above?
Thank you
If I download the above toolchain and add it it's bin path to QTcreator, would I be able to build the same project I was discussing above (containing c and cpp files)?
I used ARM9 S3C Mini2440. Please download the source code from Qt site and compile it. Below configuration work with Qt4.6
#host:/qt-everywhere-opensource-src-4.6.2#./configure \
-opensource \
-confirm-license \
-release -shared \
-embedded arm \
-xplatform qws/linux-arm-g++ \
-depths 16,18,24 \
-fast \
-optimized-qmake \
-pch \
-qt-sql-sqlite \
-qt-libjpeg \
-qt-zlib \
-qt-libpng \
-qt-freetype \
-little-endian -host-little-endian \
-no-qt3support \
-no-libtiff -no-libmng \
-no-opengl \
-no-mmx -no-sse -no-sse2 \
-no-3dnow \
-no-openssl \
-no-webkit \
-no-qvfb \
-no-phonon \
-no-nis \
-no-opengl \
-no-cups \
-no-glib \
-no-xcursor -no-xfixes -no-xrandr -no-xrender \
-no-separate-debug-info \
-nomake examples -nomake tools -nomake docs \
-qt-mouse-tslib -I/usr/local/tslib/include -L/usr/local/tslib/lib
#host:/qt-everywhere-opensource-src-4.6.2# make
#host:/qt-everywhere-opensource-src-4.6.2# make install
After the install command, you will have ARM Qt4.6 in your /usr/local/Trolltech/QtEmbedded-4.6.2-arm. Create a symblic link to ARM qmake tool
ln -s /usr/local/Trolltech/QtEmbedded-4.6.2-arm/bin/qmake /usr/local/bin/qmake-arm
Create and environment file in order to switch to Qt ARM. Let's call it setenv-qt-arm.sh
export QTEDIR=/usr/local/Trolltech/QtEmbedded-4.6.2-arm
export PATH=/usr/local/Trolltech/QtEmbedded-4.6.2-arm/bin:$PATH
export LD_LIBRARY_PATH=/usr/local/Trolltech/QtEmbedded-4.6.2-arm/lib:$LD_LIBRARY_PATH
export CPLUS_INCLUDE_PATH=/usr/local/arm/4.3.2/arm-none-linux-gnueabi/include/c++:/usr/local/arm/4.3.2/arm-none-linux-gnueabi/include/c++/4.3.2/arm-none-linux-gnueabi:$CPLUS_INCLUDE_PATH
In order to cross compile your project
cd /your_project_dir
. /<path_to>/setenv-qt-arm.sh
qmake-arm
make
I did not cross compile Qt project with QtCreator, I used the previous commands instead. If you set your qmake to the correct file (qmake-arm), I think there should be no problem, because this qmake will generate all the Makefile needed to compile your project
I am looking to create a native build of GCC for an ARM system and I am running into some trouble. The build machine is i686-linux. Every tutorial I see tells me how to set up the actual cross compiling suite (which I have already done using crosstools-ng). However, I don't see anything related to compiling native ARM GCC. The configure string I used is below, I have set up the sysroot only with headers. I have also cross-compiled and installed GMP and MPFR.
../../gcc-4.3.5/configure \
--host=arm-unknown-linux-gnueabi \
--build=i686-build_pc-linux-gnu \
--target=arm-unknown-linux-gnueabi \
--prefix=/home/vm/gcc-native/sysroot \
--with-sysroot=/home/vm/gcc-native/sysroot \
--enable-shared --enable-threads --disable-libmudflap --disable-libssp \
--disable-libgomp --disable-libstdcxx-pch --with-gnu-as --with-gnu-ld \
--enable-languages=c,c++ --enable-symvers=gnu --enable-__cxa_atexit \
--disable-nls --disable-multilib \
--with-gmp=/home/vm/gcc-native/sysroot/ \
--with-mpfr=/home/vm/gcc-native/sysroot/
GCC will build for a while but then dies with this:
checking for suffix of object files... configure: error: cannot compute suffix of object files: cannot compile.
I am not sure how this would even run on my system as I am building on i686-linux and the target/host are both arm-linux. My thought right now is to find a ltib distro and looking at a spec file for GCC and trying to follow all of the steps. The GCC that ltib shipped with for my board fails to compile on my system due to conflicts with the std namespace.
Any info/links would be appreciated!
Look in the config.log file (maybe not the top-level one) and see what it was trying to do when the test failed. Just grep for the cannot compute suffix message and you should find the right bit (it won't be at the end of the file).
Note that you'll need a working arm-unknown-linux-gnueabi-gcc on your path somewhere if you want to build a cross-native toolchain. I.e. you need a cross compiler to build cross-native compiler.