Problems with dhclient arm cross compilation - arm

I'm trying to connect to a wireless network from a Dart card (which is like a Raspberry Pi with a iMX6 CPU) using a WiFi dongle.
I followed the accepted answer here.
When I tried:
wpa_supplicant -B -i wlan0 -c spark_wifi.conf -D nl80211 && dhclient wlan0
I got:
sh: dhclient: command not found
So I looked for dhclient for ARM and the best I found was this
I followed the instructions but no matter how hard I tried I couldn't manage to compile it...
I am using yocto cross compiler which includes the following env variables:
export SDKTARGETSYSROOT=/opt/poky/1.8/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi
export PATH=/opt/poky/1.8/sysroots/x86_64-pokysdk-linux/usr/bin:/opt/poky/1.8/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi:$PATH
export CCACHE_PATH=/opt/poky/1.8/sysroots/x86_64-pokysdk-linux/usr/bin:/opt/poky/1.8/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi:$CCACHE_PATH
export PKG_CONFIG_SYSROOT_DIR=$SDKTARGETSYSROOT
export PKG_CONFIG_PATH=$SDKTARGETSYSROOT/usr/lib/pkgconfig
export CONFIG_SITE=/opt/poky/1.8/site-config-cortexa9hf-vfp-neon-poky-linux-gnueabi
export OECORE_NATIVE_SYSROOT="/opt/poky/1.8/sysroots/x86_64-pokysdk-linux"
export OECORE_TARGET_SYSROOT="$SDKTARGETSYSROOT"
export OECORE_ACLOCAL_OPTS="-I /opt/poky/1.8/sysroots/x86_64-pokysdk-linux/usr/share/aclocal"
export PYTHONHOME=/opt/poky/1.8/sysroots/x86_64-pokysdk-linux/usr
export CC="arm-poky-linux-gnueabi-gcc -march=armv7-a -marm -mthumb-interwork -mfloat-abi=hard -mfpu=neon -mtune=cortex-a9 --sysroot=$SDKTARGETSYSROOT"
export CXX="arm-poky-linux-gnueabi-g++ -march=armv7-a -marm -mthumb-interwork -mfloat-abi=hard -mfpu=neon -mtune=cortex-a9 --sysroot=$SDKTARGETSYSROOT"
export CPP="arm-poky-linux-gnueabi-gcc -E -march=armv7-a -marm -mthumb-interwork -mfloat-abi=hard -mfpu=neon -mtune=cortex-a9 --sysroot=$SDKTARGETSYSROOT"
export AS="arm-poky-linux-gnueabi-as "
export LD="arm-poky-linux-gnueabi-ld --sysroot=$SDKTARGETSYSROOT"
export GDB=arm-poky-linux-gnueabi-gdb
export STRIP=arm-poky-linux-gnueabi-strip
export RANLIB=arm-poky-linux-gnueabi-ranlib
export OBJCOPY=arm-poky-linux-gnueabi-objcopy
export OBJDUMP=arm-poky-linux-gnueabi-objdump
export AR=arm-poky-linux-gnueabi-ar
export NM=arm-poky-linux-gnueabi-nm
export M4=m4
export TARGET_PREFIX=arm-poky-linux-gnueabi-
export CONFIGURE_FLAGS="--target=arm-poky-linux-gnueabi --host=arm-poky-linux-gnueabi --build=x86_64-linux --with-libtool-sysroot=$SDKTARGETSYSROOT"
export CFLAGS=" -O2 -pipe -g -feliminate-unused-debug-types"
export CXXFLAGS=" -O2 -pipe -g -feliminate-unused-debug-types"
export LDFLAGS="-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed"
export CPPFLAGS=""
export KCFLAGS="--sysroot=$SDKTARGETSYSROOT"
export OECORE_DISTRO_VERSION="1.8"
export OECORE_SDK_VERSION="1.8"
export ARCH=arm
export CROSS_COMPILE=arm-poky-linux-gnueabi-
# Append environment subscripts
if [ -d "$OECORE_TARGET_SYSROOT/environment-setup.d" ]; then
for envfile in $OECORE_TARGET_SYSROOT/environment-setup.d/*.sh; do
source $envfile
done
fi
if [ -d "$OECORE_NATIVE_SYSROOT/environment-setup.d" ]; then
for envfile in $OECORE_NATIVE_SYSROOT/environment-setup.d/*.sh; do
source $envfile
done
fi
I am runing:
./configure --host=arm-poky-linux-gnueabi --cache-file=config.cache
The result summery is this:
ISC DHCP source configure results:
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Package:
Name: DHCP
Version: 4.2.5-P1
C Compiler: arm-poky-linux-gnueabi-gcc -march=armv7-a -marm -mthumb-interwork -mfloat-abi=hard -mfpu=neon -mtune=cortex-a9 --sysroot=/opt/poky/1.8/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi
Flags:
DEFS: -DHAVE_CONFIG_H
CFLAGS: -O2 -pipe -g -feliminate-unused-debug-types -I${top_srcdir}/bind/include
Features:
debug: no
failover:
execute:
Developer:
ATF unittests : no
Now you can type make to build ISC DHCP
Next thing to do is make which ends up with errors:
Making all in bind
make[1]: Entering directory `/home/user/workbench/dhcp/src/bind'
Configuring BIND Export libraries for DHCP.
configure: error: in `/home/user/workbench/dhcp/src/bind/bind-9.8.4-P2':
configure: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details
make[1]: *** [all] Error 1
make[1]: Leaving directory `/home/user/workbench/dhcp/src/bind'
make: *** [all-recursive] Error 1
I tired to debug this and I found that configure file contains these checks:
# There might be people who depend on the old broken behavior: `$host'
# used to hold the argument of --host etc.
# FIXME: To remove some day.
build=$build_alias
host=$host_alias
target=$target_alias
# FIXME: To remove some day.
if test "x$host_alias" != x; then
if test "x$build_alias" = x; then
cross_compiling=maybe
echo "$as_me: 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." >&2
elif test "x$build_alias" != "x$host_alias"; then
cross_compiling=yes
fi
fi
echo $cross_compiling after this part gives maybe.
I didn't manage to set $host_alias and $build_alias correctly to make this thing work.
Changing cross_compiling=maybe to cross_compiling=yes didn't work either.
It feels like I'm shaving a Yak...
I just want to connect to WiFi :)
If there is a place that I can download a dhclient binary compiled to ARM it would be great to hear.

Related

Can't compile a C program on a Mac after upgrading to Catalina 10.15

There's a previous question Can't compile C program on a Mac after upgrade to Mojave, and the answers to that have covered most of the variations on what goes wrong.
Now — as of Monday 2019-10-07 — you can upgrade to macOS Catalina 10.15. Once again, during the upgrade, the /usr/include directory has been blown away by the update, even though XCode 11.0 was installed before upgrading (from Mojave 10.14.6) to Catalina. Consequently, compilers built to expect that there is a /usr/include directory do not work any longer.
The main recommended step for the Mojave issues — using the command:
open /Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg
does not work out of the gate because the directory /Library/Developer/CommandLineTools/Packages/ does not exist (so there's not yet a .pkg file to open).
Is there a good (official) way to create and populate the directory /usr/include?
Before you proceed, make sure to install xcode command line tools.
xcode-select --install
Actually, you can do it! Actually all the C headers are found here in this folder:
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/
We just need to create symlink for all the headers file into this folder:
/usr/local/include/
It worked for me! the following command line will take care of all the problems:
sudo ln -s /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/* /usr/local/include/
You will get some warning. Some of the headers already exists, like this:
ln: /usr/local/include//tcl.h: File exists
ln: /usr/local/include//tclDecls.h: File exists
ln: /usr/local/include//tclPlatDecls.h: File exists
ln: /usr/local/include//tclTomMath.h: File exists
ln: /usr/local/include//tclTomMathDecls.h: File exists
ln: /usr/local/include//tk.h: File exists
ln: /usr/local/include//tkDecls.h: File exists
ln: /usr/local/include//tkPlatDecls.h: File exists
totally ok to ignore. that's all.
For me adding the following path to CPATH solved the issue:
export CPATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include
TL;DR
It appears that Apple considers /usr/include as something that has gone the way of the dodo — it is extinct — or maybe it's like Monty Python's Parrot.
Using the Apple-provided GCC (actually, that's Clang by any other name, as the version information shows) or Clang avoids problems. Both /usr/bin/gcc and /usr/bin/clang will find the system libraries four directory levels below:
/Applications/Xcode.app/Contents/Developer/Platforms/…
If you build your own GCC or other compiler, you will (probably) need to configure it to find the system libraries under the Xcode application directory.
Explorations
Immediately after the upgrade, I ran XCode 11.0. It wanted to install some extra components, so I let it do so. However, that did not reinstate /usr/include or the directory under /Library.
One of the other bits of advice in the previous question was to run:
xcode-select --install
When doing so, it claimed that it downloaded the command line utilities, and it ensured that /usr/bin/gcc and /usr/bin/clang etc were present. That's a useful step (though I didn't definitively check whether they were present before).
$ /usr/bin/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/MacOSX.sdk/usr/include/c++/4.2.1
Apple clang version 11.0.0 (clang-1100.0.33.8)
Target: x86_64-apple-darwin19.0.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
$
Using /usr/bin/gcc, it is now possible to compile programs:
$ make CC=/usr/bin/gcc al
co RCS/al.c,v al.c
RCS/al.c,v --> al.c
revision 1.7
done
/usr/bin/gcc -I/Users/jleffler/inc -g -O3 -std=c11 -pedantic -Wall -Wextra -Werror -Wshadow -Wmissing-prototypes -Wpointer-arith -Wold-style-definition -Wcast-qual -Wstrict-prototypes -DHAVE_MEMMEM -DHAVE_STRNDUP -DHAVE_STRNLEN -DHAVE_GETDELIM -o al al.c -L/Users/jleffler/lib/64 -ljl
$
However, /usr/include is still missing. There is a directory under /Library now:
$ ls /Library/Developer
CommandLineTools PrivateFrameworks
$ ls /Library/Developer/CommandLineTools
Library SDKs usr
$ ls /Library/Developer/CommandLineTools/SDKs
MacOSX.sdk MacOSX10.14.sdk MacOSX10.15.sdk
$ ls /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/
Entitlements.plist SDKSettings.json System
Library SDKSettings.plist usr
$
Neither the System nor the Library directory contain anything very promising.
When all else fails, read the manual
Next step — find and read the release notes:
Xcode 11 Release Notes
macOS Catalina 10.15 Release Notes
There's no information in there that relates to this. So, the probability is (AFAICS, after only an hour or two's effort) that Apple no longer support /usr/include — though it does still have a fully-loaded /usr/lib (no /lib though).
Time to check another compilation with GCC option -v added (in the makefile I used, setting UFLAGS adds the option to C compiler command line):
$ make UFLAGS=-v CC=/usr/bin/gcc ww
co RCS/ww.c,v ww.c
RCS/ww.c,v --> ww.c
revision 4.9
done
/usr/bin/gcc -I/Users/jleffler/inc -g -O3 -std=c11 -pedantic -Wall -Wextra -Werror -Wshadow -Wmissing-prototypes -Wpointer-arith -Wold-style-definition -Wcast-qual -Wstrict-prototypes -DHAVE_MEMMEM -DHAVE_STRNDUP -DHAVE_STRNLEN -DHAVE_GETDELIM -v -o ww ww.c -L/Users/jleffler/lib/64 -ljl
Apple clang version 11.0.0 (clang-1100.0.33.8)
Target: x86_64-apple-darwin19.0.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang" -cc1 -triple x86_64-apple-macosx10.15.0 -Wdeprecated-objc-isa-usage -Werror=deprecated-objc-isa-usage -emit-obj -disable-free -disable-llvm-verifier -discard-value-names -main-file-name ww.c -mrelocation-model pic -pic-level 2 -mthread-model posix -mdisable-fp-elim -fno-strict-return -masm-verbose -munwind-tables -target-sdk-version=10.15 -target-cpu penryn -dwarf-column-info -debug-info-kind=standalone -dwarf-version=4 -debugger-tuning=lldb -ggnu-pubnames -target-linker-version 512.4 -v -resource-dir /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/11.0.0 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -I /Users/jleffler/inc -D HAVE_MEMMEM -D HAVE_STRNDUP -D HAVE_STRNLEN -D HAVE_GETDELIM -I/usr/local/include -O3 -Wall -Wextra -Werror -Wshadow -Wmissing-prototypes -Wpointer-arith -Wold-style-definition -Wcast-qual -Wstrict-prototypes -Wno-framework-include-private-from-public -Wno-atimport-in-framework-header -Wno-extra-semi-stmt -Wno-quoted-include-in-framework-header -pedantic -std=c11 -fdebug-compilation-dir /Users/jleffler/src/cmd -ferror-limit 19 -fmessage-length 110 -stack-protector 1 -fstack-check -mdarwin-stkchk-strong-link -fblocks -fencode-extended-block-signature -fregister-global-dtors-with-atexit -fobjc-runtime=macosx-10.15.0 -fmax-type-align=16 -fdiagnostics-show-option -fcolor-diagnostics -vectorize-loops -vectorize-slp -o /var/folders/77/zx9nk6dn7_dg4xd4stvt42v00000gn/T/ww-4cb85b.o -x c ww.c
clang -cc1 version 11.0.0 (clang-1100.0.33.8) default target x86_64-apple-darwin19.0.0
ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/local/include"
ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/Library/Frameworks"
#include "..." search starts here:
#include <...> search starts here:
/Users/jleffler/inc
/usr/local/include
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/11.0.0/include
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks (framework directory)
End of search list.
"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld" -demangle -lto_library /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/libLTO.dylib -dynamic -arch x86_64 -macosx_version_min 10.15.0 -syslibroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -o ww -L/Users/jleffler/lib/64 /var/folders/77/zx9nk6dn7_dg4xd4stvt42v00000gn/T/ww-4cb85b.o -ljl -L/usr/local/lib -lSystem /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/11.0.0/lib/darwin/libclang_rt.osx.a
"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/dsymutil" -o ww.dSYM ww
$
The key information in that blizzard of data is:
-isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk
That's effectively the 'root' directory for the compilation, so there should be sub-directories under that for usr and usr/include:
$ ls /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk
Entitlements.plist SDKSettings.json System
Library SDKSettings.plist usr
$ ls /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr
bin include lib libexec share
$ ls /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include
AppleTextureEncoder.h dns_util.h memory.h simd
AssertMacros.h dtrace.h menu.h slapi-plugin.h
Availability.h editline miscfs spawn.h
AvailabilityInternal.h err.h module.modulemap sqlite3.h
AvailabilityMacros.h errno.h monetary.h sqlite3ext.h
AvailabilityVersions.h eti.h monitor.h stab.h
…lots more lines…
dirent.h mach-o security xcselect.h
disktab.h mach_debug semaphore.h xlocale
dispatch machine servers xlocale.h
dlfcn.h malloc setjmp.h xpc
dns.h math.h sgtty.h zconf.h
dns_sd.h membership.h signal.h zlib.h
$
This shows that the mile-long and totally unmemorable directory name does contain the standard C and POSIX headers, plus Apple-specific extras.
The previous /usr/local/ directory appears to be intact; the warning about usr/local/include not existing under the -isysrootdir is harmless (and not visible without the -v option).
Set the following implicit Make variables to point to where the headers are now located for Xcode Command Line Tools (Xcode CLI):
export CFLAGS+=-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
export CCFLAGS+=-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
export CXXFLAGS+=-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
export CPPFLAGS+=-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
The -isysroot option updates the location of the root files away from the system root directory /.
So, this ensures that the common /usr/* files are found in their new place.
That is, the files at /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk are now found. These files are:
Entitlements.plist
Library
SDKSettings.json
SDKSettings.plist
System
usr
On MacOS Catalina 10.15.4, with Xcode Version 11.5 (11E608c) I also needed to update the library path in my .zshrc (the MacOSX.sdk paths are new):
export CPATH='/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include:/opt/local/include'
export LIBRARY_PATH='/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/lib:/opt/local/lib'
I am a newbie with C++ compiler for R in OSX and I got the same issue that C++ could not find the header after OS was updated (missing math.h although it was there). I followed instructions from https://thecoatlessprofessor.com/programming/cpp/r-compiler-tools-for-rcpp-on-macos/ but nothing changed.
Finally, it worked for me after I reinstalled the Xcode CLI
xcode-select --install
and then change the flags to Var as #Coatless suggested:
export CFLAGS=-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
export CCFLAGS=-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
export CXXFLAGS=-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
export CPPFLAGS=-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
If you have both the command line tools and XCode installed, make sure the SDK installed by the command line tools is actually being used:
#Check the current sdk
$ xcrun --show-sdk-path
#Change sdk
$ sudo xcode-select -s /Library/Developer/CommandLineTools #Using CommandLineTools SDK
$ sudo xcode-select -s /Applications/Xcode.app/Contents/Developer #Using XCode.app SDK
kudos to https://stackoverflow.com/a/61526989/596599 for this answer.
For me, it works well as follow:
1. xcode-select --install
2. sudo ln -s /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/* /usr/local/include/
3. export SDKROOT=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
In my case I seemed to have llvm and gcc also installed using homebrew. When I removed those, and thus relied fully on the macOS clang, it could find the headers and the compiling worked again.
Short Answer
/Library/Developer/CommandLineTools/usr/bin/clang++ -o main main.cpp -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk
The Result
Explanation
In current macOS version, the c/c++ headers are searched inside /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/, instead of /usr/include. So you need to 'reset' the root directory using -isysroot option.
Hope this makes sense 🙂.
If using an external LLVM installation, add these to your ~/.bash_profile
LLVM_PATH="/usr/local/opt/llvm/" # or any other path
LLVM_VERSION="11.0.0"
export PATH="$LLVM_PATH:$PATH"
export SDKROOT=$(xcrun --sdk macosx --show-sdk-path)
export LD_LIBRARY_PATH="$LLVM_PATH/lib/:$LD_LIBRARY_PATH"
export DYLD_LIBRARY_PATH="$LLVM_PATH/lib/:$DYLD_LIBRARY_PATH"
export CPATH="$LLVM_PATH/lib/clang/$LLVM_VERSION/include/"
export LDFLAGS="-L$LLVM_PATH/lib"
export CPPFLAGS="-I$LLVM_PATH/include"
export CC="$LLVM_PATH/bin/clang"
export CXX="$LLVM_PATH/bin/clang++"
(adjust the clang version and the external llvm installation path.)
Then run source ~/.bash_profile
apue.h dependency was still missing in my /usr/local/include after following Komol Nath Roy answer in this question.
I downloaded the dependency manually from git and placed it in /usr/local/include
The solution was simpler than I thought. Install clang/llvm.
brew install llvm
Then we need to create symlinks ourselves.
for f in /usr/local/Cellar/llvm/9.0.0_1/bin/clang*; do ln -s ${f} /usr/local/bin/"${f##*/}"; done
And
ln -s /usr/local/Cellar/llvm/9.0.0_1/include/c++ /usr/local/include/c++
Depending upon your llvm version, modify the above commands.
Now, you can compile C++ programs without passing any custom flags.
clang++ hello.cpp
I tried 1) manually linking 2) brew install llvm, but they did not work.
Finally, this worked for me:
https://gitmemory.com/issue/pytorch/pytorch/31190/565153503
By setting the following env vars:
export CC=clang
export CXX=clang++
export MACOSX_DEPLOYMENT_TARGET=10.9
In my case, i did a millions things but i reckon following steps helped fix ruby installation.
xcode-select --install
Set these flags
export CFLAGS=-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
export CCFLAGS=-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
export CXXFLAGS=-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
export CPPFLAGS=-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
sudo ln -s /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/* /usr/local/include/
export SDKROOT=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
rbenv install 2.6.3 -v
For me the error was: xcrun[20873:1179298] Failed to open macho file at /Library/Developer/CommandLineTools/usr/bin/clang++ for reading: Too many levels of symbolic links
So I opened my terminal and went to the following folder (as mentioned by the error message): /Library/Developer/CommandLineTools/usr/bin/
Then I deleted the shortcut file named clang++
sudo rm clang++
Next, I made a copy of executable file named clang and renamed the copied file to clang++
sudo cp clang clang++
And finally it works.

QT5.7 Cross compile for AM1808 ARM9

Currently, we are working on QT for application development for our hardware that runs on the AM1808 processor.
At present, we developed our app using QT creator with compiler version Qt 4.8.7.
We are planning to upgrade it with Qt 5.7 and for that, we download the corresponding package from
http://download.qt.io/official_releases/qt/5.7/5.7.1/single/qt-everywhere-opensource-src-5.7.1.tar.gz
We successfully download this and now need to configure according to our current arm toolchain.
we have modified the qmake.conf as per below,
#
# qmake configuration for building with arm-linux-gnueabi-g++
#
MAKEFILE_GENERATOR = UNIX
CONFIG += incremental
QMAKE_INCREMENTAL_STYLE = sublib
include(../common/linux.conf)
include(../common/gcc-base-unix.conf)
include(../common/g++-unix.conf)
// modifications to g++.conf
//QMAKE_CC = arm-linux-gnueabi-gcc
//QMAKE_CXX = arm-linux-gnueabi-g++
//QMAKE_LINK = arm-linux-gnueabi-g++
//QMAKE_LINK_SHLIB = arm-linux-gnueabi-g++
// modifications to linux.conf
//QMAKE_AR = arm-linux-gnueabi-ar cqs
//QMAKE_OBJCOPY = arm-linux-gnueabi-objcopy
//QMAKE_NM = arm-linux-gnueabi-nm -P
//QMAKE_STRIP = arm-linux-gnueabi-strip
QMAKE_CC = arm-none-linux-gnueabi-gcc
QMAKE_CXX = arm-none-linux-gnueabi-g++
QMAKE_LINK = arm-none-linux-gnueabi-g++
QMAKE_LINK_SHLIB = arm-none-linux-gnueabi-g++
QMAKE_AR = arm-none-linux-gnueabi-ar cqs
QMAKE_OBJCOPY = arm-none-linux-gnueabi-objcopy
QMAKE_STRIP = arm-none-linux-gnueabi-strip
load(qt_config)
after that, we run config command
./configure -opensource -confirm-license -prefix /usr/local/Qt5 -no-pch -xplatform linux-arm-gnueabi-g++
but we found the following error,
System architecture: 'arm'
Host architecture: 'i386'
arm-none-linux-gnueabi-g++ -c -fvisibility=hidden fvisibility.c
Symbol visibility control enabled.
cc1plus: error: unrecognized command line option '-fuse-ld=gold'
arm-none-linux-gnueabi-g++ -o libtest.so -shared -Wl,-Bsymbolic-functions -fPIC bsymbolic_functions.c
bsymbolic_functions.c:2:2: error: #error "Symbolic function binding on this architecture may be broken, disabling it (see QTBUG-36129)."
Symbolic function binding disabled.
checking for C++14...
arm-none-linux-gnueabi-g++ -c -pipe -O2 -std=gnu++1y -Wall -W -fPIC -I. -I../../../mkspecs/linux-arm-gnueabi-g++ -o c++14.o c++14.cpp
cc1plus: error: unrecognized command line option '-std=gnu++1y'
make: *** [c++14.o] Error 1
C++14 disabled.
checking for default C++ standard edition...
arm-none-linux-gnueabi-g++ -pipe -O2 -Wall -W -fPIC -I. -I../../../mkspecs/linux-arm-gnueabi-g++ -o c++default.ii -E c++default.cpp
default C++ standard edition enabled.
checking for 64-bit std::atomic...
arm-none-linux-gnueabi-g++ -c -pipe -O2 -std=gnu++11 -Wall -W -fPIC -I. -I../../../mkspecs/linux-arm-gnueabi-g++ -o atomic64.o atomic64.cpp
cc1plus: error: unrecognized command line option '-std=gnu++11'
make: *** [atomic64.o] Error 1
64-bit std::atomic disabled.
checking for 64-bit std::atomic in -latomic...
arm-none-linux-gnueabi-g++ -c -pipe -O2 -std=gnu++11 -Wall -W -fPIC -I. -I../../../mkspecs/linux-arm-gnueabi-g++ -o atomic64.o atomic64.cpp
cc1plus: error: unrecognized command line option '-std=gnu++11'
make: *** [atomic64.o] Error 1
64-bit std::atomic in -latomic disabled.
checking for std::atomic for function pointers...
arm-none-linux-gnueabi-g++ -c -pipe -O2 -std=gnu++11 -Wall -W -fPIC -I. -I../../../mkspecs/linux-arm-gnueabi-g++ -o atomicfptr.o atomicfptr.cpp
cc1plus: error: unrecognized command line option '-std=gnu++11'
make: *** [atomicfptr.o] Error 1
std::atomic for function pointers disabled.
ERROR: detected a std::atomic implementation that fails for function pointers.
Please apply the patch corresponding to your Standard Library vendor, found in
/opt/qt-everywhere-opensource-src-5.7.1/qtbase/config.tests/common/atomicfptr
so, please suggest us correct method to compile this qt5 version.
Your toolchain is too old. Qt 5.6 was the last release which doesn't require a more or less fully C++ 11 compliant compiler. This changed with Qt 5.7.
Either upgrade your toolchain to 4.8 (at least) or try Qt 5.6.

error linking to LibPng library

I am having trouble linking to the libpng library.
The build seems unable to define references to Libpng calls.
I think the problem is in my Libpng install.
I am runing in the Mingw environment on a Win7 laptop
My build environment is as follows:
My path starts with C:\MinGW\bin;C:\MinGW\msys\1.0\bin;C:\MinGW\git\cmd;C:\Program Files
C:\Users\Bob\Home\png23d>g++ --version
g++ (GCC) 5.3.0
I have built and installed libpng-1.6.28 which creates the following:
C:\MinGW\bin>
libpng-config
libpng16-config
libpng16.dll
C:\MinGW\include\libpng
png.h
pngconf.h
pnglibconf.h
C:\MinGW\include\libpng16
png.h
pngconf.h
pnglibconf.h
C:\MinGW\lib\pkgconfig
C:\MinGW\lib>
libpng.a
libpng.dll.a
libpng16.a
libpng16.dll.a
a symbolic link `libpng' to `libpng16'
a symbolic link `libpng.pc' to `libpng16.pc'
a symbolic link `libpng.a' to `libpng16.a'
a symbolic link `libpng-config' to `libpng16-config
when I try to build a program "png23d" I get the following
C:\Users\Bob\Home\png23d>make
g++ -DUSE_LIBPNG -lpng png23d.o option.o bitmap.o mesh.o mesh_gen.o mesh_index.o mesh_simplify.o out_pgm.o out_rscad.o out_pscad.o out_stl.o -o png23d
bitmap.o:bitmap.c:(.text+0x102): undefined reference to `png_sig_cmp'
bitmap.o:bitmap.c:(.text+0x142): undefined reference to `png_create_read_struct'
.
.
.
bitmap.o:bitmap.c:(.text+0x418): undefined reference to `png_read_end'
bitmap.o:bitmap.c:(.text+0x466): undefined reference to `png_destroy_read_struct'
collect2.exe: error: ld returned 1 exit status
<builtin>: recipe for target 'png23d' failed
make: *** [png23d] Error 1
I am almost sure its the -lpng that is not working.... I am just don't know how to fix it.
I am guessing that it is a symbolic link problem and I know I did not create one during the libpng build.
If I am right what do I need to link it to.
I tried changing -lpng to -llpng16. It made no difference.
Thanks from the command prompt that work fine.
just have to figure out how to change the make file.
#!/usr/bin/make
#
# png23d is a program to convert png images into 3d files
#
# Copyright 2011 Vincent Sanders <vince#kyllikki.org>
#
# Released under the MIT License,
# http://www.opensource.org/licenses/mit-license.php
CC = g++
VERSION=100
PREFIX =
WARNFLAGS = -W -Wall -Wundef -Wpointer-arith \
-Wcast-align -Wwrite-strings -Wstrict-prototypes \
-Wmissing-prototypes -Wmissing-declarations -Wredundant-decls \
-Wnested-externs
ifneq ($(GCCVER),2)
WARNFLAGS += -Wno-unused-parameter
endif
OPTFLAGS=-O2
#OPTFLAGS=-O0
CFLAGS+=$(WARNFLAGS) -MMD -DVERSION=$(VERSION) $(OPTFLAGS) -g
LDFLAGS+= -DUSE_LIBPNG -lpng
PNG23D_OBJ=png23d.o option.o bitmap.o mesh.o mesh_gen.o mesh_index.o mesh_simplify.o out_pgm.o out_rscad.o out_pscad.o out_stl.o
.PHONY : all clean
all:png23d
png23d:$(PNG23D_OBJ)
-include $(PNG23D_OBJ:.o=.d)
-include test/Makefile.sub
clean: testclean
${RM} png23d $(PNG23D_OBJ) *.d *~ png23d.png
install:png23d
install -D png23d $(DESTDIR)$(PREFIX)/bin
install-man:png23d.1
install -D png23d.1 $(DESTDIR)$(PREFIX)/share/man/man1
# logo creation
png23d.png:png23d.pov
povray +L/usr/share/povray/include/ -D +Q11 +O$# +UV +UL +A0.2 +FP8 +W400 +H300 $<
Move -lpng to after the object files.

Elf error: Request error: invalid ELF_C_* argument (when i try to run my programm)

I created a programm which obtains adreses of load/store operations to create a memory profile. It compiles fine. But, I am getting following error when I try to run it:
Elf error: Request error: invalid ELF_C_* argument
--FATAL-- #68: Dyninst was unable to create the specified process
--FATAL-- #68: create process failed bootstrap
profile: profile.c:27: void createProcess(const char*, const char**):
Assertion `g_bpProcess' failed.
I am using Red Hat system. With core 3.10.26. GCC 4.8.2.
I am installed boost 1.53. added it rath to PATH and to LD_LIBRARY_PATH,
installed libelf with --prefix=/path/to/elf_bld/
installed libwarf with --enable-shared --prefix=/path/to/dwarf_bld/ and with export LIBS="-lelf", export LDFLAGS="-L/path/to/elf_bld/lib/" , CPPFLAGS="-I/path/to/elf_bld/include"
installed DyninstAPI-8.1.1 with --prefix=/path/to/Dyn_bld/ --with-boost=/path/to/boost_1_53_0/ --with-libelf=/path/to/elf_bld --with-libdwarf-incdir=/path/to/lobdwarf --with-libdwarf-libdir=/path/to/libdwarf
Istallation was with not a root user.
I compile so
CC = g++
CFLAGS = -Wall -static
EXECNAME= profile
LIB = -L /path/to/boost_1_53_0/stage/lib -L/path/to/Dyn_bld/lib -L /path/to/libdwarf -L /path/to/elf_bld/lib
INCLUDE = -I /path/to/boost_1_53_0/ -I /path/to/Dyn_bld/include/ -I /path/to/libdwarf/ -I /path/to/elf_bld/include/
DYNINST_ROOT =/path/to/Dyn_bld/lib
$(EXECNAME): $(EXECNAME).o
$(CC) $(EXECNAME).o ${INCLUDE} ${LIB} \
-ldyninstAPI -lsymtabAPI -lcommon -ldwarf -lelf -o $(EXECNAME)
$(EXECNAME).o: ./$(EXECNAME).c
$(CC) -g -c $(CFLAGS) $(EXECNAME).c
clean:
#rm -f $(EXECNAME).o $(EXECNAME) core
and
export CC=gcc
export DYNINST_ROOT=/path/to/Dyn_bld
export DYNINSTAPI_RT_LIB=/path/to/Dyn_bld/lib/libdyninstAPI_RT.so.8.1.1
So, can anybody help me with this?
I am stuck at this really badly. Any help is appreciated.
Thanks,
Dmitriy

Cross compile xalan-c 1.11, arm gcc, CodeSourcery 4.3.3, ./configure

I have been trying to compile xalan-c specifically 1.11 with xerces 3.1.1. with an arm cross-compile toolchain 4.3.3 from CodeSourcery on a ubuntu 14.x 64.
xalan-c has two configure scripts. First the usual ./configure and second ./runConfigure.
Up until now I have been cross-compiling other libs (e.g. libusb-1.0/libusb-0.1/openssl) with
--host../configure --host=arm-none-linux-gnueabi --prefix="/home/user/sysroot-arm-sf/usr/local/"
This time however I believe I need to use ./runConfigure otherwise some environment variables are not set (e.g. how it deals with messages)
I use:
./runConfigure -p linux -x arm-none-linux-gnueabi-g++ -c arm-none-linux-gnueabi-gcc -P "/home/user/sysroot-arm-sf/usr/local/" -C--host=arm-none-linux-gnueabi
instead which I believe to be the equivalent to ./configure . the ./runConfigure is using all default values (except for the c and c++ compiler which it does not recognize, unfortunately)
Generating makefiles with the following options ...
Platform: linux
C Compiler: arm-none-linux-gnueabi-gcc
C++ Compiler: arm-none-linux-gnueabi-g++
Extra compile options:
Extra link options:
Transcoder: default
Localization system: inmem
Locale: en_US
Thread option: pthread
bitsToBuild option: 32
Extra configure options: --prefix=/home/user/sysroot-arm-sf/usr/local/ --host=arm-none-linux-gnueabi
Debug is OFF
I do not recognize the C compiler 'arm-none-linux-gnueabi-gcc'. Continuing anyway ...
I do not recognize the C++ compiler 'arm-none-linux-gnueabi-g++'. Continuing anyway ...
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 for arm-none-linux-gnueabi-gcc... arm-none-linux-gnueabi-gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... yes
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether arm-none-linux-gnueabi-gcc accepts -g... yes
checking for arm-none-linux-gnueabi-gcc option to accept ANSI C... none needed
checking for arm-none-linux-gnueabi-g++... arm-none-linux-gnueabi-g++
checking whether we are using the GNU C++ compiler... yes
checking whether arm-none-linux-gnueabi-g++ accepts -g... yes
checking for a BSD-compatible install... /usr/bin/install -c
checking for autoconf... autoconf
checking build system type... x86_64-unknown-linux-gnu
checking host system type... arm-none-linux-gnueabi
checking for floor in -lm... yes
checking how to run the C++ preprocessor... arm-none-linux-gnueabi-g++ -E
checking for egrep... grep -E
checking for ANSI C header files... yes
checking for mbstowcs... yes
checking if mbstowcs can count only... cross-compiling default
configure: creating ./config.status
config.status: creating Makefile.incl
config.status: creating Makefile
config.status: creating src/xalanc/Makefile
config.status: creating src/xalanc/Utils/Makefile
config.status: creating src/xalanc/Utils/MsgCreator/Makefile
config.status: creating src/xalanc/Utils/XalanMsgLib/Makefile
config.status: creating samples/Makefile
config.status: creating Tests/Makefile
If the result of the above commands look OK to you, go to the directory
/home/user/xalan-c-1.11/c/ and type "gmake" or "make" to make the XALAN-C system.
Note: You must use GNU make to use the Xalan Makefile.
Then I'll try
make
make -C src/xalanc all
make[1]: Entering directory `/home/user/xalan-c-1.11/c/src/xalanc'
Preparing the directory structure for a build ...
mkdir -p ../../obj
mkdir -p ../../lib
mkdir -p ../../bin
make -C Utils prepare
make[2]: Entering directory `/home/user/xalan-c-1.11/c/src/xalanc/Utils'
mkdir -p ../../../nls
mkdir -p ../../../nls/include
make[2]: Leaving directory `/home/user/xalan-c-1.11/c/src/xalanc/Utils'
make -C Utils locale
make[2]: Entering directory `/home/user/xalan-c-1.11/c/src/xalanc/Utils'
make -C MsgCreator
make[3]: Entering directory `/home/user/xalan-c-1.11/c/src/xalanc/Utils/MsgCreator'
arm-none-linux-gnueabi-g++ -O3 -DNDEBUG -pthread -D_REENTRANT -Wall -fPIC -DLINUX -D_REENTRANT -DXALAN_INMEM_MSG_LOADER -c -I/home/user/xalan-c-1.11/c//src -I/home/user/xalan-c-1.11/c//include -I../../../../nls/include -I/home/user/xerces-c-3.1.1//src/ -I/home/user/xerces-c-3.1.1//include/xercesc -I/home/user/xerces-c-3.1.1//include/ -o ../../../../obj/MsgFileOutputStream.o /home/user/xalan-c-1.11/c//src/xalanc/Utils/MsgCreator/MsgFileOutputStream.cpp
arm-none-linux-gnueabi-g++ -O3 -DNDEBUG -pthread -D_REENTRANT -Wall -fPIC -DLINUX -D_REENTRANT -DXALAN_INMEM_MSG_LOADER -c -I/home/user/xalan-c-1.11/c//src -I/home/user/xalan-c-1.11/c//include -I../../../../nls/include -I/home/user/xerces-c-3.1.1//src/ -I/home/user/xerces-c-3.1.1//include/xercesc -I/home/user/xerces-c-3.1.1//include/ -o ../../../../obj/ICUResHandler.o /home/user/xalan-c-1.11/c//src/xalanc/Utils/MsgCreator/ICUResHandler.cpp
arm-none-linux-gnueabi-g++ -O3 -DNDEBUG -pthread -D_REENTRANT -Wall -fPIC -DLINUX -D_REENTRANT -DXALAN_INMEM_MSG_LOADER -c -I/home/user/xalan-c-1.11/c//src -I/home/user/xalan-c-1.11/c//include -I../../../../nls/include -I/home/user/xerces-c-3.1.1//src/ -I/home/user/xerces-c-3.1.1//include/xercesc -I/home/user/xerces-c-3.1.1//include/ -o ../../../../obj/InMemHandler.o /home/user/xalan-c-1.11/c//src/xalanc/Utils/MsgCreator/InMemHandler.cpp
arm-none-linux-gnueabi-g++ -O3 -DNDEBUG -pthread -D_REENTRANT -Wall -fPIC -DLINUX -D_REENTRANT -DXALAN_INMEM_MSG_LOADER -c -I/home/user/xalan-c-1.11/c//src -I/home/user/xalan-c-1.11/c//include -I../../../../nls/include -I/home/user/xerces-c-3.1.1//src/ -I/home/user/xerces-c-3.1.1//include/xercesc -I/home/user/xerces-c-3.1.1//include/ -o ../../../../obj/MsgCreator.o /home/user/xalan-c-1.11/c//src/xalanc/Utils/MsgCreator/MsgCreator.cpp
arm-none-linux-gnueabi-g++ -O3 -DNDEBUG -pthread -D_REENTRANT -Wall -fPIC -DLINUX -D_REENTRANT -DXALAN_INMEM_MSG_LOADER -c -I/home/user/xalan-c-1.11/c//src -I/home/user/xalan-c-1.11/c//include -I../../../../nls/include -I/home/user/xerces-c-3.1.1//src/ -I/home/user/xerces-c-3.1.1//include/xercesc -I/home/user/xerces-c-3.1.1//include/ -o ../../../../obj/NLSHandler.o /home/user/xalan-c-1.11/c//src/xalanc/Utils/MsgCreator/NLSHandler.cpp
arm-none-linux-gnueabi-g++ -O3 -DNDEBUG -pthread -D_REENTRANT -Wall -fPIC -DLINUX -D_REENTRANT -DXALAN_INMEM_MSG_LOADER -c -I/home/user/xalan-c-1.11/c//src -I/home/user/xalan-c-1.11/c//include -I../../../../nls/include -I/home/user/xerces-c-3.1.1//src/ -I/home/user/xerces-c-3.1.1//include/xercesc -I/home/user/xerces-c-3.1.1//include/ -o ../../../../obj/SAX2Handler.o /home/user/xalan-c-1.11/c//src/xalanc/Utils/MsgCreator/SAX2Handler.cpp
arm-none-linux-gnueabi-g++ -DLINUX -fPIC -pthread -D_REENTRANT -DXALAN_INMEM_MSG_LOADER \
-lm -lpthread ../../../../obj/MsgFileOutputStream.o ../../../../obj/ICUResHandler.o ../../../../obj/InMemHandler.o ../../../../obj/MsgCreator.o ../../../../obj/NLSHandler.o ../../../../obj/SAX2Handler.o -o ../../../../bin/MsgCreator -L/home/user/xerces-c-3.1.1//lib -lxerces-c
make[3]: Leaving directory `/home/user/xalan-c-1.11/c/src/xalanc/Utils/MsgCreator'
../../../bin/MsgCreator /home/user/xalan-c-1.11/c//src/xalanc/NLS/en_US/XalanMsg_en_US.xlf -TYPE inmem -LOCALE en_US
../../../bin/MsgCreator: ../../../bin/MsgCreator: cannot execute binary file
make[2]: *** [../../../nls/include/LocalMsgData.hpp] Error 126
make[2]: Leaving directory `/home/user/xalan-c-1.11/c/src/xalanc/Utils'
make[1]: *** [locale] Error 2
make[1]: Leaving directory `/home/user/xalan-c-1.11/c/src/xalanc'
make: *** [all] Error 2
and it will fail executing
../../../bin/MsgCreator /home/user/xalan-c-1.11/c//src/xalanc/NLS/en_US/XalanMsg_en_US.xlf -TYPE inmem -LOCALE en_US
which is
bin/MsgCreator: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.14, not stripped
a binary for an Arm arch. I though ./runConfigure had used the --host option and was aware this was a cross build. Or maybe this is something xalan-c specific?
It does say
checking whether we are cross compiling... yes
So this looks like a poorly tested makefile, to me.
You could try to debug it, or you could just install qemu so that ARM binaries magically Just Work (assuming they can find their libraries).
I tried the following workaround which apparently worked.
The files in the xalanc bin/ Folder seem to be only used at compile time (at least I guessed so). Xalan generates headerfiles etc. in order to compile the libxalanMsg.so .
It was a long shot but I simply precompile those bin/ files for Ubuntu x86 and copied those files into my cross compile bin folder.
done. (at least for now)
This problem is really tough and weird. Fortunately, I find a way to resolve this problem.
From the error, we can conclude that the build process uses an executable tool named 'MsgCreator'.
Where is it from?
Actually, this tool is an intermediate product of the build process. Xalan generate it and use this tool to do something he wants.
What happens?
You may remember that you are now cross-compiling Xalan, so the target executable platform of MsgCreator may not support your build platform. This case will cause the error you see.
How to solve this problem
Use the local compiler to build a local MsgCreator which means this tool can run on your build platform.
Update the code in …./xalan-c-1.11/c/src/xalanc/Utils/MsgCreator/Malefile.in.
$(XSL_BIN_DIR)/MsgCreator -> $(XSL_BIN_TMP_DIR)/MsgCreator
Export XSL_BIN_TMP_DIR to your local MsgCreator tool path.
export LD_LIBRARY_PATH to add MsgCreator dependency libraries. These libraries can be generated by compiling Xerces-C (the version must greater than 3.0) with your local compiler.
Cross compile Xalan, everything will go well.

Resources