So far I was building libxml2-2.9.2 and previous versions for iOS 32 bits only.
The command I'm using to call configuration script is:
./configure --with-debug=no --host=arm-apple-darwin12.5.0 --with-iconv=no --with-zlib=no
and this was working just fine.
Now to build it for 64 bit architecture I'm passing:
./configure --with-debug=no --host=arm64-apple-darwin12.5.0 --with-iconv=no --with-zlib=no
And this is printing out the following errors:
checking build system type... x86_64-apple-darwin12.5.0
checking host system type... Invalid configuration `arm64-apple-darwin12.5.0': machine `arm64-apple' not recognized
configure: error: /bin/sh ./config.sub arm64-apple-darwin12.5.0 failed
Do you know how to fix this problem?
Thanks in advance.
Related
I have been attempting to build Drake from source with Bazel on Ubuntu 18.04 but the following error occurs when I run
bazel build ...
from the Drake root directory:
ERROR: /home/username/dir/drake/bindings/pydrake/BUILD.bazel:56:37: Action bindings/pydrake/documentation_pybind.h failed (Exit 1) mkdoc failed: error executing command bazel-out/host/bin/tools/workspace/pybind11/mkdoc -DDRAKE_COMMON_SYMBOLIC_DETAIL_HEADER -DEIGEN_MPL2_ONLY -DHAVE_CSTDDEF '-DFMT_HEADER_ONLY=1' '-DFMT_NO_FMT_STRING_ALIAS=1' -DHAVE_SPDLOG ... (remaining 1096 argument(s) skipped)
Use --sandbox_debug to see verbose messages from the sandbox
external/eigen/include/_usr_include_eigen3/Eigen/Core:66:12: fatal error: 'new' file not found
Traceback (most recent call last):
File "/home/username/.cache/bazel/_bazel_username/6e98757561df7a931d098ab985a3e673/sandbox/linux-sandbox/1371/execroot/drake/bazel-out/host/bin/tools/workspace/pybind11/mkdoc.runfiles/drake/tools/workspace/pybind11/mkdoc.py", line 841, in <module>
main()
File "/home/username/.cache/bazel/_bazel_username/6e98757561df7a931d098ab985a3e673/sandbox/linux-sandbox/1371/execroot/drake/bazel-out/host/bin/tools/workspace/pybind11/mkdoc.runfiles/drake/tools/workspace/pybind11/mkdoc.py", line 805, in main
severities.count(cindex.Diagnostic.Fatal)))
RuntimeError: Parsing headers using the clang library failed with 0 error(s) and 1 fatal error(s)
----------------
Note: The failure of target //tools/workspace/pybind11:mkdoc (with exit code 1) may have been caused by the fact that it is running under Python 3 instead of Python 2. Examine the error to determine if that appears to be the problem. Since this target is built in the host configuration, the only way to change its version is to set --host_force_python=PY2, which affects the entire build.
If this error started occurring in Bazel 0.27 and later, it may be because the Python toolchain now enforces that targets analyzed as PY2 and PY3 run under a Python 2 and Python 3 interpreter, respectively. See https://github.com/bazelbuild/bazel/issues/7899 for more information.
----------------
INFO: Elapsed time: 2345.311s, Critical Path: 321.76s
INFO: 1378 processes: 1378 linux-sandbox.
FAILED: Build did NOT complete successfully
Prior to building, I ran:
sudo ./setup/ubuntu/install_prereqs.sh
as mentioned in the installation instructions.
I had also set the environment variables for the c and c++ compilers to $CC=/usr/bin/gcc and $CXX=/usr/bin/gcc because I was suspicious of compiler issues being the problem. To compare against this, I also tried to build with $CC=/usr/bin/clang-9 and $CXX=/usr/bin/clang++-9, with a different resulting error:
ERROR: /home/username/dir/drake/systems/framework/BUILD.bazel:213:17: C++ compilation of rule '//systems/framework:cache_and_dependency_tracker' failed (Exit 1) clang-9 failed: error executing command /usr/bin/clang-9 -U_FORTIFY_SOURCE -fstack-protector -Wall -Wthread-safety -Wself-assign -fcolor-diagnostics -fno-omit-frame-pointer -g0 -O2 '-D_FORTIFY_SOURCE=1' -DNDEBUG -ffunction-sections ... (remaining 77 argument(s) skipped)
Use --sandbox_debug to see verbose messages from the sandbox
In file included from systems/framework/cache.cc:1:
bazel-out/k8-opt/bin/systems/framework/_virtual_includes/cache_and_dependency_tracker/drake/systems/framework/cache.h:7:10: fatal error: 'cstdint' file not found
#include <cstdint>
^~~~~~~~~
I suspect that there is some issue with the include paths that are being used during build since both compilers were unable to find standard files, however I am unsure of what to try next or how to fix this. Any suggestions or advice would be greatly appreciated!
This seems to be the same problem that I encountered. My Question is here Encounter "RuntimeError: The operating system's C++ standard library is not installed correctly" when build drake from source using bazel and I solve my problem following #jwnimmer-tri's answer.
It turns out that Clang is looking for GCC's standard library and it seems that it looks for GCC with higher version (not sure). I guess the problem is that you have gcc-8 installed but not g++-8, so after you install g++-8 you can fix the issue. Another possible way to solve your problem is to follow #jwnimmer-tri's answer in my question to remove gcc-8 completely.
Im running yocto to build an image inside docker, but after all processes i get error related to automake. This is the error:
checking whether build environment is sane...
configure: error: newly created file is older than distributed files!
Check your system clock
The log is:
DEBUG: Executing shell function autotools_preconfigure
DEBUG: Shell function autotools_preconfigure finished
DEBUG: Executing python function autotools_aclocals
DEBUG: SITE files ['endian-little', 'common-linux', 'common-glibc', 'bit-64', 'x86_64-linux', 'common']
DEBUG: Python function autotools_aclocals finished
DEBUG: Executing shell function do_configure
NOTE: Running ../automake-1.15.1/configure --build=x86_64-linux --host=x86_64-linux --target=x86_64-linux --prefix=/shared/rpi3-custom/build/tmp/work/x86_64-linux/automake-native/1.15.1-r0/recipe-sysroot-native/usr --exec_prefix=/shared/rpi3-custom/build/tmp/work/x86_64-linux/automake-native/1.15.1-r0/recipe-sysroot-native/usr --bindir=/shared/rpi3-custom/build/tmp/work/x86_64-linux/automake-native/1.15.1-r0/recipe-sysroot-native/usr/bin --sbindir=/shared/rpi3-custom/build/tmp/work/x86_64-linux/automake-native/1.15.1-r0/recipe-sysroot-native/usr/sbin --libexecdir=/shared/rpi3-custom/build/tmp/work/x86_64-linux/automake-native/1.15.1-r0/recipe-sysroot-native/usr/libexec --datadir=/shared/rpi3-custom/build/tmp/work/x86_64-linux/automake-native/1.15.1-r0/recipe-sysroot-native/usr/share --sysconfdir=/shared/rpi3-custom/build/tmp/work/x86_64-linux/automake-native/1.15.1-r0/recipe-sysroot-native/etc --sharedstatedir=/shared/rpi3-custom/build/tmp/work/x86_64-linux/automake-native/1.15.1-r0/recipe-sysroot-native/com --localstatedir=/shared/rpi3-custom/build/tmp/work/x86_64-linux/automake-native/1.15.1-r0/recipe-sysroot-native/var --libdir=/shared/rpi3-custom/build/tmp/work/x86_64-linux/automake-native/1.15.1-r0/recipe-sysroot-native/usr/lib --includedir=/shared/rpi3-custom/build/tmp/work/x86_64-linux/automake-native/1.15.1-r0/recipe-sysroot-native/usr/include --oldincludedir=/shared/rpi3-custom/build/tmp/work/x86_64-linux/automake-native/1.15.1-r0/recipe-sysroot-native/usr/include --infodir=/shared/rpi3-custom/build/tmp/work/x86_64-linux/automake-native/1.15.1-r0/recipe-sysroot-native/usr/share/info --mandir=/shared/rpi3-custom/build/tmp/work/x86_64-linux/automake-native/1.15.1-r0/recipe-sysroot-native/usr/share/man --disable-silent-rules --disable-dependency-tracking --disable-static
configure: WARNING: unrecognized options: --disable-dependency-tracking, --disable-static
checking whether make supports nested variables... yes
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking for a BSD-compatible install... /shared/rpi3-custom/build/tmp/hosttools/install -c
checking whether build environment is sane... configure: error: newly created file is older than distributed files!
Check your system clock
NOTE: The following config.log files may provide further information.
NOTE: /shared/rpi3-custom/build/tmp/work/x86_64-linux/automake-native/1.15.1-r0/build/config.log
ERROR: configure failed
WARNING: exit code 1 from a shell command.
ERROR: Function failed: do_configure (log file is located at /shared/rpi3-custom/build/tmp/work/x86_64-linux/automake-native/1.15.1-r0/temp/log.do_configure.11873)
In latest Yocto version, there is this patch that removes clock sanity check.
I am trying to compile Erlang OTP-R16B03-1 on FreeBSD 10.1 OS. When i run the ./configure command the output is
odbc : ODBC library - header check failed
I have tried installing unixODBC, iODBC. Also /usr/ports/databases/unixODBC exists. The sql.h file is located in /usr/local/include.
I am still getting the link failed error. Any help will be useful
The log for ./configure |grep odbc command is as shown below
config.status: WARNING: 'Makefile.in' seems to ignore the --datarootdir setting
=== configuring in odbc/. (/root/otp_src_R16B03-1/lib/odbc/.)
checking for odbc in standard locations... -L/usr/local/lib
checking for SQLAllocHandle in -lodbc... no
configure: WARNING: "ODBC library - header check failed"
configure: WARNING: Check for large file support flags failed; getconf failed
odbc : ODBC library - header check failed
I had the same problem on erlang 21 but when I downloaded the newest version from github (erlang 22), and tried ./configure the error ODBC library - header check failed appeared again but after trying make install again, everything finished successfully.
What finally worked for me was
apt-get install unixodbc-dev
Then
otp_build configure --with-odbc=/usr/lib/x86_64-linux-gnu/
Recently I am trying to build OpenCV with CUDA support, and I met problem while building the module cudaarithm.
OpenCV source: git cloned from : http://github.com/Itseez/opencv.git
OpenCV branch: master branch
OpenCV commit:
`commit 5466e321b8c8f97536002a357e5b7ff49a5d2bf9, on Tue Feb 10 12:17:11 2015 +0000`
CUDA version: CUDA 6.5
Hardware: MacBook Pro (13-inch, Mid 2010)
GPU: NVIDIA GeForce 320M 256 MB
OS Version: OS X Yosemite
Steps I used:
1. cd in OpenCVSource, then mkdir myrelease, and cd myrelease
2. cmake -DPLANTUML_JAR=/usr/local/Cellar/plantuml/8002 -D BUILD_DOCS=1 -DPYTHON2_LIBRARY=/usr/local/Cellar/python/2.7.8_2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/config/libpython2.7.dylib -DPYTHON2_INCLUDE_DIR=/usr/local/Cellar/python/2.7.8_2/Frameworks/Python.framework/Versions/2.7/include/python2.7 -DPYTHON3_LIBRARY=/usr/local/Cellar/python3/3.4.2_1/Frameworks/Python.framework/Versions/3.4/lib/libpython3.4m.dylib -DPYTHON3_INCLUDE_DIR=/usr/local/Cellar/python3/3.4.2_1/Frameworks/Python.framework/Versions/3.4/include/python3.4m -D CMAKE_BUILD_TYPE=RELEASE -DCMAKE_INSTALL_PREFIX=/usr/local -Wno-dev -DNVCC_FLAGS_EXTRA="-Xcompiler -stdlib=libstdc++; -Xlinker -stdlib=libstdc++" -DOPENCV_EXTRA_CXX_FLAGS=" -stdlib=libstdc++" -DOPENCV_EXTRA_EXE_LINKER_FLAGS="-stdlib=libstdc++" ..
3. make VERBOSE=1
Expect Result: Building success without error
Actual Result: when building OpenCVSource/modules/cudaarithm/src/cuda/transpose.cu, error happend like below:
/Users/Hawk/Documents/study/DIP/OpenCV/OpenCVSource/modules/cudaarithm/src/cuda/transpose.cu(61): *error: identifier "getInputMat" is undefined*
/Users/Hawk/Documents/study/DIP/OpenCV/OpenCVSource/modules/cudaarithm/src/cuda/transpose.cu(67): *error: identifier "getOutputMat" is undefined*
/Users/Hawk/Documents/study/DIP/OpenCV/OpenCVSource/modules/cudaarithm/src/cuda/transpose.cu(92): *error: identifier "syncOutput" is undefined*
Then what action I take:
check the code and I found these undefined symboles are defined in OpenCVSource/modules/core/include/opencv2/core/private.cuda.hpp
check the code and I confrim that the "transpose.cu" file include "opencv2/core/private.cuda.hpp"
check the building log, and I the confirm the private.cuda.hpp is in the search path of header file
cp "opencv2/core/private.cuda.hpp" as another file "opencv2/core/hawk.hpp", and then edit "transpose.cu" to include this new file, and I found
the "undifined symbole error" disapeared.
Although this is a workable workaround, I would like know whether the original OpenCV source cannot be compiled.
All, I think I found the problem cause.
Before I met such problem, I've already build and install OpenCV using older code from the git repo. So that there already have header files in my /usr/local/include/opencv2, especially there is /usr/local/include/opencv2/core/private.cuda.hpp.
However, it is an older one that doesn't define the symbols reporting undefined in above question. At the same time I found during the building nvcc have -I/usr/local/include in the command line, so that it use wrong private.cuda.hpp. As you know it should use the one in OpenCVSource, not the older installed one.
I think the solution is to gracefully remove the original installed OpenCV from my computer, then build again. I am trying and I will report later.
I am trying to compile Sofia-SIP library for iOS for architectures armv6 and armv7 but I am running into problems. Below is what I am doing.
export DEVROOT=/Applications/Xcode_4_6.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer
export SDKROOT=$DEVROOT/SDKs/iPhoneOS6.1.sdk
export CC=$SDKROOT/usr/bin/llvm-gcc-4.2
export CFLAGS="-pipe -no-cpp-precomp -isysroot $SDKROOT -arch armv7"
export LDFLAGS="-syslibroot $SDKROOT -arch armv7"
export CPP=$SDKROOT/usr/bin/llvm-g++-4.2./configure --host=arm-apple-darwin10
sudo ./configure --host=arm-apple-darwin10
RESULT
Password:
configure: WARNING: if you wanted to set the --build type, don't use --host.
If a cross compiler is detected then cross compile mode will be used
checking build system type... x86_64-apple-darwin12.5.0
checking host system type... arm-apple-darwin10
checking target system type... arm-apple-darwin10
checking cached information... ok
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for arm-apple-darwin10-strip... no
checking for strip... strip
checking whether to enable maintainer-specific portions of Makefiles... no
checking for style of include used by make... GNU
checking for arm-apple-darwin10-gcc... no
checking for gcc... gcc
checking for arm-apple-darwin10-gcc... gcc
checking whether the C compiler works... yes
PROBLEM
I want the script to use llvm-gcc compiler. But instead it is looking for arm-apple-darwin10-gcc which it could not find and then finally ends up using gcc compiler.
I fought with this for a weekend, won the battle (with a lot of help), and have the following to return to the community:
Regarding su_os_nw.c and the
SCDynamicStore: function has been explicitly marked unavailable for iOS
issue:
I was about to give up, but noticed that a fellow named Antonis Tsakirids from Restcomm reported success in integrating Sofia in their iOS SDK.
I then went to their git repository and had a look at their SDK.
In /dependencies/sofia-sip/libsofia-sip-ua/su/ I found the culprit: su_os_nw.c
They elegantly updated
#if defined (__APPLE_CC__)
to
#if defined (__APPLE_CC__) && !defined(TARGET_OS_IPHONE)
This solves it…
…but it does not solve it just by itself…because apparently since Xcode 7, Apple did some toolchain utilities shuffling.
Stuff is not located in “usual” locations anylonger, and MishaBruckman’s $DEVROOT got obsolete.
For instance , I got errors about “ar” not being found.
export DEVROOT="$(xcrun --sdk iphoneos --show-sdk-platform-path)/Developer”
maps to /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer
However, the toolchain utilities (ld, ar, as, nm, ranlib, along with the almighty clang) have been moved to /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin.
I bolded the part that should map to the new $DEVROOT.
Hope this helps someone save 2 weekend days of their life...
…and in the end, the 2 points expressed above were not enough to get out of the woods…Compilation did finish OK and I left it at that initially.
However, today I wanted to actually use the library. Created a new project, imported the library, hit Build and…more suffering…
libsofia-sip-ua.a does not contain bitcode. You must rebuild it with bitcode enabled (Xcode setting ENABLE_BITCODE), obtain an updated library from the vendor, or disable bitcode for this target for architecture armv7.
At first I went “say wha’…?”
what’s this mumbo_jumbo about setting stuff in Xcode? I did things the old_school way, compiling in command line…
what do you mean “obtain an updated library from the vendor”…the “vendor” is me, I’m building the library…
what is this strange bitcode thing, anyway?
After doing my homework regarding bitcode I started wondering what hides behind Xcode’s ENABLE_BITCODE… Turns out it “means” passing the “-fembed-bitcode” flag to clang.
In conclusion, the line
export CFLAGS="-arch ${ARM_ARCH} -mios-version-min=7 -pipe -no-cpp-precomp -isysroot ${SDKROOT} -I${SDKROOT}/usr/include/"
became
export CFLAGS="-arch ${ARM_ARCH} -mios-version-min=7 -fembed-bitcode -pipe -no-cpp-precomp -isysroot ${SDKROOT} -I${SDKROOT}/usr/include/"
Rebuilt Sofia with the new settings, but then it started complaining that even though the main project itself is going ok, it's SUB-LIBRARIES (for example libstun.a) are not compiled with bitcode. A "make clean" got rid of the old garbage and compilation finished ok. Imported the newly produced lib into my Xcode project and everything was ok as well.
And that finally concludes it. Build successful for a project under Xcode 7 / iOS9 integrating Sofia library, in anno domini 2015…
...aaaand...I was still not out of the woods...
As soon I decided to add arm64 architecture to my project, Xcode started again to complain about Sofia:
ignoring file libsofia-sip-ua.a, file was built for archive which is not the architecture being linked (arm64)
Undefined symbols for architecture arm64
Pretty simple, I thought: I'll just replace armv7 with arm64:
export ARM_ARCH="arm64”
After that modification, disaster struck while ./configure-ing:
checking for gcc... /usr/bin/clang
checking for gcc... (cached) /usr/bin/clang
checking whether the C compiler works... no
configure: error: in `/work/fromSourceforge/sofia-sip-1.12.11':
configure: error: C compiler cannot create executables
See `config.log' for more details
The next day was spent figuring out what was wrong (I could not ./configure anylonger, even reverting back to armv7)
stormed stack overflow; no solution helped
checked ad re-checked every path on the system...I was surprised to find out that one can find clang and gcc in 3-4 places throughout macosx, but I digress...
trying to reinstall Xcode Developer Tools
ended up reinstalling Xcode itself...
...nothing helped.
An eagle-eyed colleague spotted what was wrong:
export ARM_ARCH="arm64”
The last quote sign was not "the same" as the first quote sign. The first quote sign is "the correct kind of quote sign".
Even if I didn't touch the second one with my own hand, TextEdit changed it all by itself while I was converting v7 to 64. Apparently it's "a feature", called SmartQuotes. I could not disable it, by the way.
Mental note: NEVER EVER use TextEdit again to edit the .bash_profile file.
Finally, I found myself in the posession of the 64 bit version of Sofia. Plugged it into my Xcode project, aaaaaaand....
ignoring file libsofia-sip-ua.a, file was built for archive which is not the architecture being linked (armv7)
Undefined symbols for architecture armv7
Hmmm...if I build it for 32 bits, it complains about 64 missing...If I build it for 64 bits, it complains about 32 missing...
Turns out there's a way to fuse together multiple libraries into a single "fat" one.
The utility is called lipo and you use it something like this:
lipo -create "path_to_lib_1" "path_to_lib2" -output "path_to_desired_name_of_the_merged_library"
So: SIP-ing along with Sofia, under iOS, as a single library that does both 32 and 64 bits...
Heewhhh...
.....aaaaaaaaand we're still not done...!
Problem: trying to do anything (REGISTER, for instance) promptly resulted in a 503 DNS Error
Cause : Sofia searches for the name servers list in etc/resolv.conf
Obviously, this being iOS, it either does not exist, OR it's outside of the app sandbox.
Solution : it's the second time when this guy, Antonis Tsakiridis, saves my ass. Respectful bow.
First, he talks about what he intends to do.
Second, he shows what he has actually done.
However, the solution exposes a new...
Problem: _res_9_init - undefined symbol for architecture (armv7 or arm64 here, depending on what I happened to have set for ARM_ARCH), while recompiling Sofia
Cause : I don't know. I can only infer from the solution, that the linker needed to be told about the "resolv" library
Solution : added -lresolv in two places:
LDFLAGS (in the .bash_profile file)
in the Xcode "application" project (the one that exercises the library); Targets ---> Linking ---> OtherLinkerFlags
Just like before, although the above solves what it was trying to solve, it also advances us to the next...
Problem: conditional execution of code under #IOS_BUILD (part of AT's solution at first problem) did not take place. Still getting 503 DNS Error...
Cause : I could not figure out for the life of me WHERE IT'S ACTUALLY DEFINED. Of course, defining it anywhere in my own code could have no effect, since Sofia is supposed to be an already compiled dependency; we don't get another chance at the preprocessor crunching through her code.
Solution: I replaced the IOS_BUID #define with an environment variable called IOS_BUILD that has the value...well...IOS_BUILD. I told Xcode about it (I'm trying to use not the word "define" to avoid confusion) at
Product ---> Scheme ---> EditScheme ---> Arguments ---> EnvironmentVariables.
In Sofia, I just substituted #Ifdef IOS_BUILD with calls to getenv() and strcmp().
After all that, behold...REGISTER takes place...
Also, DNS settings are correctly detected everytime I connect the iPhone to another wi-fi, thanks to Sofia's smart "resolver".
Note that llvm-gcc is deprecated; you should be using clang instead:
% ls -l /usr/bin/llvm-gcc
lrwxr-xr-x 1 root wheel 5 Nov 8 2013 /usr/bin/llvm-gcc# -> clang
The following seems to work for me:
export DEVROOT="$(xcrun --sdk iphoneos --show-sdk-platform-path)/Developer"
export SDKROOT="$(xcrun --sdk iphoneos --show-sdk-path)"
export CC="/usr/bin/clang"
export CXX="/usr/bin/clang++"
export LD="${DEVROOT}/usr/bin/ld"
export AR="${DEVROOT}/usr/bin/ar"
export AS="${DEVROOT}/usr/bin/as"
export NM="${DEVROOT}/usr/bin/nm"
export RANLIB="${DEVROOT}/usr/bin/ranlib"
export LDFLAGS="-L${SDKROOT}/usr/lib/"
export ARM_ARCH="armv7" # or "armv6" and adjust the --host=[...] flag below
export CFLAGS="-arch ${ARM_ARCH} -pipe -no-cpp-precomp -isysroot ${SDKROOT} -I${SDKROOT}/usr/include/"
export CPPFLAGS="${CFLAGS}"
export CXXFLAGS="${CFLAGS}"
Configure:
./configure --host=armv7-apple-darwin
Build:
make
Verify:
file `find . -name \*dylib`
Output:
./libsofia-sip-ua/.libs/libsofia-sip-ua.0.dylib: Mach-O dynamically linked shared library arm
./libsofia-sip-ua/.libs/libsofia-sip-ua.0.dylib.dSYM/Contents/Resources/DWARF/libsofia-sip-ua.0.dylib: Mach-O dSYM companion file arm
./libsofia-sip-ua/.libs/libsofia-sip-ua.dylib: Mach-O dynamically linked shared library arm
Credits:
most flags above were adapted from this question
xcrun command via a comment by Alex Denisov on this page
Notes:
I dropped the -miphoneos-version-min=[...] flag from the other question as I did not think it was relevant to your question; up to you if you want to add it back into CFLAGS.