autoconf detecting where pthread functions really are - pthreads

I'm looking for a way to detect where pthread functions really exist (libc, libpthread or both). My motivation is that GNU libc seems to be moving the pthread functions from libpthread to libc. I need to intercept these functions and to determine which library to intercept at configure time. To complicate the supported platforms are Linux glibc, Solaris, FreeBSD, macOS and Linux musl, with the emphasis on Linux glibc.
I don't think that AC_CHECK_LIB and AC_SEARCH_LIBS are suitable, they will just try to compile a little stub containing the function and linking with the library. Since libc gets linked by default this won't work.
So far I've come up with something like this
safe_CFLAGS=$CFLAGS
CFLAGS="$CFLAGS -nodefaultlibs -lc"
AC_MSG_CHECKING([if pthread_cond_destroy is in libc])
AC_LINK_IFELSE([AC_LANG_PROGRAM([[]], [[
#include <pthread.h>
(void)pthread_cond_destroy(0);
]])], [
PTHREAD_IN_LIBC=1
AC_MSG_RESULT([yes])
], [
AC_MSG_RESULT([no])
])
CFLAGS=$safe_CFLAGS
This seems to work OK-ish for detecting if functions are in libc (and perhaps AC_SEARCH_LIBS could do the same more easily).
But for checking libpthread I get
configure:16532: clang -o conftest -nodefaultlibs -lpthread
conftest.c >&5 ld: error: undefined symbol: atexit
>>> referenced by crt1.c:63 (/usr/src/lib/csu/amd64/crt1.c:63)
(plus similar errors for _init_tls and exit)
Plan B to use nm but that seems really brittle - libs may be stripped, and I'd have to handle every different path / library name.
UPDATE:
I've made some progress.
ac_pthread_create_in_libc=yes
ac_pthread_cond_destroy_in_libc=yes
ac_sem_open_in_libc=yes
AC_SEARCH_LIBS([pthread_create], , , [ac_pthread_create_in_libc=no],)
AC_SEARCH_LIBS([pthread_cond_destroy], , , [ac_pthread_cond_destroy_in_libc=no],)
AC_SEARCH_LIBS([sem_open], , , [ac_sem_open_in_libc=no],)
ac_thread_fns_only_in_libc=no
if test x$ac_pthread_create_in_libc = xyes \
-a x$ac_pthread_cond_destroy_in_libc = xyes \
-a x$ac_sem_open_in_libc = xyes ; then
ac_thread_fns_only_in_libc=yes
fi
ac_thread_fns_only_in_libpthread=no
if test x$ac_thread_fns_only_in_libc = xno ; then
ac_pthread_create_in_libpthread=no
ac_pthread_cond_destroy_in_libpthread=no
ac_sem_open_in_libpthread=no
if test x$ac_pthread_create_in_libc = xno ; then
unset ac_cv_search_pthread_create
safe_LIBS=$LIBS
AC_SEARCH_LIBS([pthread_create], [pthread], [ac_pthread_create_in_libpthread=yes], ,)
LIBS=$safe_LIBS
fi
if test x$ac_pthread_cond_destroy_in_libc = xno ; then
unset ac_cv_search_pthread_cond_destroy
AC_SEARCH_LIBS([pthread_cond_destroy], [pthread], [ac_pthread_cond_destroy_in_libc=yes], ,)
LIBS=$safe_LIBS
fi
if test x$ac_sem_open_in_libc= xyes ; then
unset ac_cv_search_sem_open
AC_SEARCH_LIBS([sem_open], [pthread], [ac_sem_open_in_libc=yes], ,)
LIBS=$safe_LIBS
fi
if test x$ac_pthread_create_in_libpthread = xyes \
-a x$ac_pthread_cond_destroy_in_libpthread = xyes \
-a x$ac_sem_open_in_libpthread = xyes ; then
ac_thread_fns_only_in_libpthread=yes
fi
fi
ac_thread_fns_in_libc_and_libpthread=no
if test x$ac_thread_fns_only_in_libc = xno -a \
x$ac_thread_fns_only_in_libpthread = xno ; then
ac_thread_fns_in_libc_and_libpthread=yes
fi
AC_MSG_NOTICE([libc $ac_thread_fns_only_in_libc pthread $ac_thread_fns_only_in_libpthread both $ac_thread_fns_in_libc_and_libpthread])
This seems to work. I'll make it an answer when it's production ready.

Related

How to build LLVM (clang,clang++) for Apple M1?

I am trying to build LLVM compilers so that I can enable OpenMP on the Apple M1.
I am using the LLVM development tree, (since I saw some OpenMP runtime go into that for this recently).
I have ended up with this script to invoke cmake:
# Xcode, Ninja
BUILD_SYSTEM=Ninja
BUILD_TAG=Ninja
cmake ../llvm \
-G$BUILD_SYSTEM -B ${BUILD_TAG}_build \
-DCMAKE_OSX_ARCHITECTURES='arm64' \
-DCMAKE_C_COMPILER=`which clang` \
-DCMAKE_CXX_COMPILER=`which clang++` \
-DCMAKE_BUILD_TYPE=Release \
-DCMAKE_BUILD_WITH_INSTALL_RPATH=1 \
-DCMAKE_INSTALL_PREFIX=$HOME/software/clang-12.0.0/arm64 \
-DLLVM_ENABLE_WERROR=FALSE \
-DLLVM_TARGETS_TO_BUILD='AArch64' \
-DLLVM_ENABLE_PROJECTS='clang;openmp,polly' \
-DLLVM_DEFAULT_TARGET_TRIPLE='aarch64-apple-darwin20.1.0'
The compilers used here are
$ /usr/bin/clang --version
Apple clang version 12.0.0 (clang-1200.0.32.27)
Target: arm64-apple-darwin20.1.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
ninja can then successfully build clang, clang++ and the OpenMp runtime and install them. (As simple, Arm64 images targeting Arms64)
$ file ~/software/clang-12.0.0/arm64/bin/clang
/Users/jcownie/software/clang-12.0.0/arm64/bin/clang: Mach-O 64-bit executable arm64
$ ~/software/clang-12.0.0/arm64/bin/clang --version
clang version 12.0.0 (https://github.com/llvm/llvm-project.git 879c15e890b4d25d28ea904e92497f091f796019)
Target: aarch64-apple-darwin20.1.0
Thread model: posix
InstalledDir: /Users/jcownie/software/clang-12.0.0/arm64/bin
Which all looks sane, except that when I try to compile anything with them they are missing the include path to get system headers.
$ ~/software/clang-12.0.0/arm64/bin/clang hello.c
hello.c:1:10: fatal error: 'stdio.h' file not found
#include <stdio.h>
^~~~~~~~~
1 error generated.
So, after all that,
Does anyone know how to fix that include path problem?
Does anyone know how to configure and build a fat binary for the compilers (and libraries) so that the x86_64 embedded compiler targets x86_64 and the aarch64 binary aarch64? (This is what the Xcode clang and clang++ do...)
My attempt at this ended up with a compiler fat binary where both architectures targeted x86_64 :-(
Thanks
You can set -DDEFAULT_SYSROOT=/path/to/MacOSX11.1.sdk at build time or do export SDKROOT=/path/to/MacOSX11.1.sdk at runtime.
You need to compile with clang -arch arm64 -arch x86_64 to get a fat binary out of clang. You need to do this for Apple clang as well.
UPDATED 8 Feb 2021
Homebrew now supports the M1 based Arm machines, so using that is a better answer than the one below.
The info below is potentially still useful if you want to do this on your own, but using brew is likely to be much simpler.
Pre-brew answer
I haven't found a clean solution, but in case it helps anyone else, I do have a horrible hack.
The full recipe, then is configure with this script, then build and install.
# Xcode, Ninja
BUILD_SYSTEM=Ninja
BUILD_TAG=ninja
INSTALLDIR=$HOME/software/clang-12.0.0/arm64
cmake ../llvm \
-G$BUILD_SYSTEM -B ${BUILD_TAG}_build \
-DCMAKE_OSX_ARCHITECTURES='arm64' \
-DCMAKE_C_COMPILER=`which clang` \
-DCMAKE_CXX_COMPILER=`which clang++` \
-DCMAKE_BUILD_TYPE=Release \
-DCMAKE_INSTALL_PREFIX=$INSTALLDIR \
-DLLVM_LOCAL_RPATH=$INSTALLDIR/lib \
-DLLVM_ENABLE_WERROR=FALSE \
-DLLVM_TARGETS_TO_BUILD='AArch64' \
-DLLVM_DEFAULT_TARGET_TRIPLE='aarch64-apple-darwin20.1.0' \
-DDEFAULT_SYSROOT="$(xcrun --show-sdk-path)" \
-DLLVM_ENABLE_PROJECTS='clang;openmp;polly;clang-tools-extra;libcxx;libcxxabi' \
# -DLLVM_ENABLE_PROJECTS='clang;openmp;polly'
That gives a compiler that finds the right headers, but won't link successfully if OpenMP is used because it doesn't pass on any useful -L path or add a necessary rpath.
To overcome that I created a small shell script that sits in my ~/bin, at the front of my $PATH, which adds those extra linker flags.
#
# A truly awful hack, but it seems necessary.
# Install this with execute permissions as clang and clang++ in
# a directory early in your path, so that it is executed when clang or
# clang++ is needed.
#
# For brew...
INSTALLDIR=/usr/local/opt/llvm
# For a local build.
INSTALLDIR=${HOME}/software/clang-12.0.0/arm64/
# Find out the name of this file, and then invoke the same file in the
# compiler installation, adding the necessary linker directives
CMD=`echo $0 | sed "s/\/.*\///"`
${INSTALLDIR}/bin/${CMD} -L${INSTALLDIR}/lib -Wl,-rpath,${INSTALLDIR}/lib $*
I am not recommending this particularly; there should clearly be a better way to make it work, but it'll do for now, and lets me get back to using the compiler rather than building it!
I was able to build with -DDEFAULT_SYSROOT="$(xcrun --show-sdk-path)" -DCMAKE_INSTALL_PREFIX=/Users/foo/lokal/ and install into the lokal/bin lokal/lib path. Once that is done you can use LD_LIBRARY_PATH=/Users/foo/lokal/lib and all the libraries should be found without mucking with anything else rpath related.

AM_PROG_LEX and undefined yywrap

My program uses the documented autoconf macro AM_PROG_LEX. It builds fine on RHEL 6.5 and other distros, but fails on RHEL 6.6 and later.
The configure script cannot compile its tests. When it tries gcc with -ll, -lfl, linking fails with:
/usr/bin/ld: cannot find -lfl
When it tries gcc without extra libraries, linking fails with:
undefined reference to `yywrap'
libfl.a or libfl.so is missing from official repos of those systems. On RHEL 6.5 it's part of flex package.
RHEL 6.5
configure:5334: checking whether yytext is a pointer
configure:5351: gcc -o conftest -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -O0 conftest.c -lfl >&5
configure:5351: $? = 0
configure:5359: result: yes
RHEL 6.8
configure:5196: checking whether yytext is a pointer
configure:5217: gcc -o conftest -g -O2 conftest.c >&5
/tmp/ccNJtVgv.o: In function `input':
/home/git/rpmbuild/BUILD/snacc-1.3.1_16_g23ba7a6/lex.yy.c:1168: undefined reference to `yywrap'
/tmp/ccNJtVgv.o: In function `yylex':
/home/git/rpmbuild/BUILD/snacc-1.3.1_16_g23ba7a6/lex.yy.c:867: undefined reference to `yywrap'
/tmp/ccNJtVgv.o: In function `main':
/home/git/rpmbuild/BUILD/snacc-1.3.1_16_g23ba7a6/conftest.l:17: undefined reference to `yywrap'
collect2: ld returned 1 exit status
configure:5224: $? = 1
configure: failed program was:
...
configure:5246: result: no
libfl contains two and only two functions, both of which are normally unnecessary in production use of flex:
int main() { extern int yylex(void); while (yylex()) ; return 0; }
int yywrap(void) { return 1; }
The yywrap implementation (which essentially disables the yywrap functionality) is not necessary if you use the option
%option noyywrap
in your flex definition, or if you pass the command-line option --noyywrap to flex.
For quick-and-dirty flex scanners, or for debugging, it is sometimes handy to be able to use libfl to fill in the above functions. But it also can create problems on systems which provide both 32- and 64-bit environments. For this reason, libfl was removed from the RHEL flex rpm in 2014. See this RedHat bug fix advisory for details.
So you could install the appropriate flex-devel rpm in order to have libfl available. Or you could compile it yourself using the above code (which is not precisely the source code you'll find in the flex source bundle, but should produce precisely the same library).
Or you could try to fix autoconf so that it doesn't depend on libfl. It didn't used to have any such dependency; if it couldn't find libfl, it would just assume that it wasn't required for the program being compiled.
Workaround is to install flex-devel package containing libfl.a. RHEL version available to subscribers ony. Alternative is CentOS package or recompiling from source.

Running Erlang on Xeon Phi

How can I compile the VM and run Erlang programs on the Intel Xeon Phi coprocessor?
Intel Xeon Phi is not a typical x86_64 architecture, therefore it's not possible to run the official Erlang VM on it. The only way to do it is to use cross-compilation and build the VM yourself on a different (host) machine where Erlang is supported, so that it runs on a target system (Phi in this case).
Xeon Phi also supports slightly different instruction set than a typical x86_64 architecture, so you also need to edit the code. If you just cross-compile the VM without touching the code, you will probably get an error:
/tmp/iccvaLP3vas_.s: Assembler messages:
/tmp/iccvaLP3vas_.s:25794: Error: `mfence' is not supported on `k1om'
So first of all you need to add #ifndef clauses around memory fence instructions, which are not supported on Phi (mfence, lfence and sfence). This boils down to opening the erts/include/internal/i386/ethr_membar.h file and adding following preprocessor directives:
#ifndef __MIC__
...
#endif
around __asm__ statements in funtions ethr_mfence__, ethr_sfence__ and ethr_lfence__ e.g.
static __inline__ void
ethr_mfence__(void)
{
#if ETHR_SIZEOF_PTR == 4
if (ETHR_X86_RUNTIME_CONF_HAVE_NO_SSE2__)
ETHR_NO_SSE2_MEMORY_BARRIER__;
else
#endif
#ifndef __MIC__
__asm__ __volatile__ ("mfence\n\t" : : : "memory");
#endif
}
Now you can try to cross-compile it. First download the sources (in my case Erlang VM 17.5), then run:
$ cd otp_src_17.5
$ export ERL_TOP=`pwd`;
$ ./configure \
--host=k1om-unknown-linux-gnu \
--build=x86_64-pc-linux-gnu \
--without-termcap \
--without-javac \
--without-ssl \
--prefix=/path/to/my/new_installation \
CC=icc \
CFLAGS=-mmic \
LDFLAGS=-mmic \
DED_LD=icc \
DED_LDFLAGS="-mmic -shared -Wl,-Bsymbolic" \
DED_LD_FLAG_RUNTIME_LIBRARY_PATH="-Wl,-R"
$ make
$ make install
icc is the official Intel Compiler and -mmic flag is required for compiling for Xeon Phi. The host and build flags are the systems/architectures of respectively the machine where you compile and the machine which you compile for (Phi). In my case they had following values, but if it's different for you, you might want to use the config.guess script which automatically detects your OS/CPU architecture.
$ ./config.guess
$ x86_64-pc-linux-gnu
And that's it! Now you should be able to ssh on your Phi and run Erlang.
$ ssh my-phi-coprocessor
$ cd /path/to/my/new_installation/
$ export PATH=`pwd`/bin:$PATH;
$ erl -version
Erlang (SMP,ASYNC_THREADS) (BEAM) emulator version 6.4

How to build boost 1.56.0 boost::context for iphone (ARM)

I'm trying to build boost for iOS development and I found a auto build script on github.
Most libraries build fine and I got a boost.a. I have the asio library tested, it works.
But the boost::coroutine build fails, in fact the boost::context build fails with this error.
darwin.compile.c++ iphone-build/boost/bin.v2/libs/context/build/darwin-8.1~iphone/release/architecture-arm/link-static/macosx-version-iphone-8.1/target-os-iphone/threading-multi/unsupported.o
libs/context/src/unsupported.cpp:7:2: error: "platform not supported"
#error "platform not supported"
^
1 error generated.
"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++" "-arch" "armv7" "-arch" "armv7s" "-arch" "arm64" "-fvisibility=hidden" "-fvisibility-inlines-hidden" "-DBOOST_AC_USE_PTHREADS" "-DBOOST_SP_USE_PTHREADS" "-std=c++11" "-stdlib=libc++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -gdwarf-2 -fexceptions -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS8.1.sdk -pthread -arch arm -DBOOST_ALL_NO_LIB=1 -DBOOST_CONTEXT_SOURCE -DNDEBUG -D_LITTLE_ENDIAN -I"." -c -o "iphone-build/boost/bin.v2/libs/context/build/darwin-8.1~iphone/release/architecture-arm/link-static/macosx-version-iphone-8.1/target-os-iphone/threading-multi/unsupported.o" "libs/context/src/unsupported.cpp"
...failed darwin.compile.c++ iphone-build/boost/bin.v2/libs/context/build/darwin-8.1~iphone/release/architecture-arm/link-static/macosx-version-iphone-8.1/target-os-iphone/threading-multi/unsupported.o...
And the boost::context requirements says we should
specify certain additional properties at bjam command line: target-os, abi, binary-format, architecture and address-model.
I change build script's bjam command line from
./bjam -j16 --build-dir=iphone-build -sBOOST_BUILD_USER_CONFIG=$BOOST_SRC/tools/build/example/user-config.jam --stagedir=iphone-build/stage --prefix=$PREFIXDIR toolset=darwin architecture=arm target-os=iphonemacosx-version=iphone-${IPHONE_SDKVERSION} define=_LITTLE_ENDIAN link=static stage > "${LOG}" 2>&1
to
./bjam -j16 --build-dir=iphone-build -sBOOST_BUILD_USER_CONFIG=$BOOST_SRC/tools/build/example/user-config.jam --stagedir=iphone-build/stage --prefix=$PREFIXDIR toolset=darwin abi=aapcs binary-format=mach-o address-model=32 architecture=arm target-os=iphone macosx-version=iphone-${IPHONE_SDKVERSION} define=_LITTLE_ENDIAN link=static stage > "${LOG}" 2>&1
now the compiler doing the right thing but I got another error
darwin.compile.asm iphone-build/boost/bin.v2/libs/context/build/darwin-8.1~iphone/release/abi-aapcs/address-model-32/architecture-arm/link-static/macosx-version-iphone-8.1/target-os-iphone/threading-multi/asm/jump_arm_aapcs_macho_gas.o
libs/context/src/asm/jump_arm_aapcs_macho_gas.S:94:11: error: invalid operand for instruction
pop v1
^
"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++" "-arch" "armv7" "-arch" "armv7s" "-arch" "arm64" "-fvisibility=hidden" "-fvisibility-inlines-hidden" "-DBOOST_AC_USE_PTHREADS" "-DBOOST_SP_USE_PTHREADS" "-std=c++11" "-stdlib=libc++" -x assembler-with-cpp -O3 -finline-functions -Wno-inline -Wall -gdwarf-2 -fexceptions -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS8.1.sdk -arch arm -DBOOST_ALL_NO_LIB=1 -DBOOST_CONTEXT_SOURCE -DNDEBUG -D_LITTLE_ENDIAN -I"." -c -o "iphone-build/boost/bin.v2/libs/context/build/darwin-8.1~iphone/release/abi-aapcs/address-model-32/architecture-arm/link-static/macosx-version-iphone-8.1/target-os-iphone/threading-multi/asm/jump_arm_aapcs_macho_gas.o" "libs/context/src/asm/jump_arm_aapcs_macho_gas.S"
`
Not just pop v1, and lots of other compile errors and after read the clang's Cross-compilation doc,
I decide to add -target arm-macho to auto script line 213.
Now, only one error pop v1 and 8 warnings like these:
clang: warning: unknown platform, assuming -mfloat-abi=soft
clang: warning: argument unused during compilation: '-arch armv7'
clang: warning: argument unused during compilation: '-stdlib=libc++'
clang: warning: argument unused during compilation: '-arch arm'
I know a little x86 asm and I read the libs/context/src/asm/jump_arm_aapcs_macho_gas.S, it seems that pop v1 should be pop {v1}, I don't know ARM asm, whatever, I just wanna make this pass and check error later.
So I change libs/context/src/asm/jump_arm_aapcs_macho_gas.S:94
from pop v1 to pop {v1} and build this again it finally works fine.
But just the context and coroutine library build fine. Other library such as libs/atomic/src/lockpool.cpp fails with error
libs/atomic/src/lockpool.cpp:15:10: fatal error: 'cstddef' file not found
As a dummy donkey, I'm out of skills.
Can somebody help me about this?
I should link all references, but my reputation is less than 10. I cannot post more than 2 links.
I just managed to build Boost.Context (1.59.0) with some modifications to the solution as provided by ofxiOSBoost from GitHub.
The problems with the original solution against building Boost.Context are:
the build script hard-codes the darwin toolset to use "clang++", which can only build pure C++ code, not the assembly code
as you have already figured out, the b2 command line as supplied by the build script doesn't include all the requirements to build Boost.Context, namely: abi, address-model, architecture, binary-format, these requirements are used to match the correct assembly source files inside "context/build/Jamfile.v2"
Even after you correctly specify all of the requirements, you still get compilation errors, which are actually generated from attempting to use the hardcoded clang++ to compile the assembly source code - btw, you should not modify the original assembly source code to just see it compiles.
Inside context/build/Jamfile.v2, you have to build the assembly code inline, instead of using clang++. Fortunately, there are some nice examples inside the same file teaching you how to build the assembly source code inline, so eventually clang++ will just see the generated object files, and the rest of the toolchain pipeline can happily consume them.
I am pasting the modifications I made in the Boost.Context Jamfile below (you should be smart enough to figure out where to put those sections):
actions gasarmv7
{
cpp -x assembler-with-cpp "$(>)" | as -arch armv7 -o "$(<)"
}
actions gasarm64
{
cpp -x assembler-with-cpp "$(>)" | as -arch arm64 -o "$(<)"
}
-
# ARM DARWIN 32_64
alias asm_context_sources
: [ make asm/make_arm_aapcs_macho_gas.o : asm/make_arm_aapcs_macho_gas.S : #gasarmv7 ]
[ make asm/jump_arm_aapcs_macho_gas.o : asm/jump_arm_aapcs_macho_gas.S : #gasarmv7 ]
[ make asm/make_arm64_aapcs_macho_gas.o : asm/make_arm64_aapcs_macho_gas.S : #gasarm64 ]
[ make asm/jump_arm64_aapcs_macho_gas.o : asm/jump_arm64_aapcs_macho_gas.S : #gasarm64 ]
: <abi>aapcs
<address-model>32_64
<architecture>arm
<binary-format>mach-o
<toolset>darwin
;
And below are the modifications to the build-libc++.sh:
Boost 1.58.0+ is recommended, since it Boost.Context added support for arm64
BOOST_V1=1.59.0
BOOST_V2=1_59_0
-
buildBoostForIPhoneOS()
{
cd $BOOST_SRC
# Install this one so we can copy the includes for the frameworks...
set +e
echo "------------------"
LOG="$LOGDIR/build-iphone-stage.log"
echo "Running bjam for iphone-build stage"
echo "To see status in realtime check:"
echo " ${LOG}"
echo "Please stand by..."
./bjam -j${PARALLEL_MAKE} --build-dir=iphone-build -sBOOST_BUILD_USER_CONFIG=$BOOST_SRC/tools/build/example/user-config.jam --stagedir=iphone-build/stage --prefix=$PREFIXDIR --toolset=darwin-${IPHONE_SDKVERSION}~iphone cxxflags="-stdlib=$STDLIB" variant=release linkflags="-stdlib=$STDLIB" architecture=arm address-model=32_64 abi=aapcs binary-format=mach-o target-os=iphone macosx-version=iphone-${IPHONE_SDKVERSION} define=_LITTLE_ENDIAN link=static stage > "${LOG}" 2>&1
if [ $? != 0 ]; then
tail -n 100 "${LOG}"
echo "Problem while Building iphone-build stage - Please check ${LOG}"
exit 1
else
echo "iphone-build stage successful"
fi
echo "------------------"
LOG="$LOGDIR/build-iphone-install.log"
echo "Running bjam for iphone-build install"
echo "To see status in realtime check:"
echo " ${LOG}"
echo "Please stand by..."
./bjam -j${PARALLEL_MAKE} --build-dir=iphone-build -sBOOST_BUILD_USER_CONFIG=$BOOST_SRC/tools/build/example/user-config.jam --stagedir=iphone-build/stage --prefix=$PREFIXDIR --toolset=darwin-${IPHONE_SDKVERSION}~iphone cxxflags="-stdlib=$STDLIB" variant=release linkflags="-stdlib=$STDLIB" architecture=arm address-model=32_64 abi=aapcs binary-format=mach-o target-os=iphone macosx-version=iphone-${IPHONE_SDKVERSION} define=_LITTLE_ENDIAN link=static install > "${LOG}" 2>&1
if [ $? != 0 ]; then
tail -n 100 "${LOG}"
echo "Problem while Building iphone-build install - Please check ${LOG}"
exit 1
else
echo "iphone-build install successful"
fi
doneSection
echo "------------------"
LOG="$LOGDIR/build-iphone-simulator-build.log"
echo "Running bjam for iphone-sim-build "
echo "To see status in realtime check:"
echo " ${LOG}"
echo "Please stand by..."
./bjam -j${PARALLEL_MAKE} --build-dir=iphonesim-build -sBOOST_BUILD_USER_CONFIG=$BOOST_SRC/tools/build/example/user-config.jam --stagedir=iphonesim-build/stage --toolset=darwin-${IPHONE_SDKVERSION}~iphonesim architecture=x86 address-model=32_64 binary-format=mach-o abi=sysv target-os=iphone variant=release macosx-version=iphonesim-${IPHONE_SDKVERSION} link=static stage > "${LOG}" 2>&1
if [ $? != 0 ]; then
tail -n 100 "${LOG}"
echo "Problem while Building iphone-simulator build - Please check ${LOG}"
exit 1
else
echo "iphone-simulator build successful"
fi
doneSection
}
Pay special attention to the b2 command lines above (the requirements are specified there to match the Boost.Context Jamfile.v2 changes.
Also, as the original build script always tries to download and unpack the boost archive, so you need to might want to save the modifications to the Boost.Context Jamfile.v2 somewhere and re-apply it, or for the second run (after downloading, unpacking, and patching boost for at least once):
#cleanEverythingReadyToStart #may want to comment if repeatedly running during dev
#restoreBoost
#downloadBoost
#unpackBoost
#inventMissingHeaders
prepare
bootstrapBoost
#updateBoost
buildBoostForIPhoneOS
scrunchAllLibsTogetherInOneLibPerPlatform
buildIncludes
#restoreBoost
#postcleanEverything
Again, please get latest version from https://github.com/danoli3/ofxiOSBoost and use Boost 1.59.0
Hope this helps!

autotools for pthreads not setting correct linker flags

I am adding some pthreads code into my Linux application that I'm building with autotools. I was getting an error about not linking in libpthreads. So I want to specify the pthreads dependency and compiler/linker flags in autotools.
I found some references that say use an ACX_PTHREAD macro. GNU provides an AX_PTHREAD macro. Both are very similar in concept. But I've tried both (on Ubuntu 13.04 64-bit), and found that they set -pthread in $PTHREAD_CFLAGS, but for some reason they don't set the -lpthread linker flag in $PTHREAD_LIBS.
The build fails. When I run make, I get:
...
/bin/sh ../libtool --tag=CXX --mode=link g++ -g -O2 -o myapp main.o ... -lconfuse -llog4cpp -lnsl -lpopt -lfuse -L/usr/local/lib -lrt
libtool: link: g++ -g -O2 -o .libs/myapp main.o ... -lconfuse -llog4cpp -lnsl /usr/lib/x86_64-linux-gnu/libpopt.so -lfuse -L/usr/local/lib -lrt
/usr/bin/ld: app-fuse.o: undefined reference to symbol 'pthread_kill##GLIBC_2.2.5'
/usr/bin/ld: note: 'pthread_kill##GLIBC_2.2.5' is defined in DSO /lib/x86_64-linux-gnu/libpthread.so.0 so try adding it to the linker command line
/lib/x86_64-linux-gnu/libpthread.so.0: could not read symbols: Invalid operation
collect2: error: ld returned 1 exit status
...
In this case, the ./configure step shows:
...
checking for the pthreads library -lpthreads... no
checking whether pthreads work without any flags... no
checking whether pthreads work with -Kthread... no
checking whether pthreads work with -kthread... no
checking for the pthreads library -llthread... no
checking whether pthreads work with -pthread... yes
checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE
checking if more special flags are required for pthreads... no
checking for PTHREAD_PRIO_INHERIT... yes
...
I notice it checks for -lpthreads, but shouldn't it be checking for -lpthread?
I've found that I can use:
AC_CHECK_LIB(pthread, pthread_create, [PTHREAD_LIBS+=-lpthread])
and then the build succeeds. But I assume this isn't the best way to make it work on the widest variety of platforms.
I see Ubuntu also has a package libpthread-stubs0-dev. But I'm not sure what it's for.
What is the "right way" to use pthreads with autotools?
Thanks to Peter Simons who asked on the autoconf mailing list, we have a somewhat official answer:
Compiler flags and linker flags are not mutually-exclusive sets, not
least because linking is typically done via the compiler frontend (cc)
and not by invoking the linker (ld) directly. Any flags that you can
use in the compile step (e.g. -O2, -DFOO, -I/tmp/include) will
generally be accepted in the linking step, even if it's not applicable
then. (The reverse may not be true, e.g. -lfoo.)
Given that, it's a lot less error-prone to use PTHREAD_CFLAGS (and
other CFLAGS variables) when linking, rather than duplicating the
applicable flags into PTHREAD_LIBS/LDFLAGS/etc. variables and not
using any CFLAGS variables then.
So just use PTHREAD_CFLAGS for your linker, too.
I bumped into this same issue when I added a first C++ source to an otherwise working C project (a shared library). Adding this C++ file caused libtool to switch from linking with gcc to linking with g++. Seems that linking with gcc a '-pthread' is enough to add the dynamic dependency to libpthread, but when linking with g++, it is not.
I tried with the above patch to a local ax_pthread.m4, but this didn't help. Passing '-lpthread' to g++ would fix the issue.
Edit: for some reason, ax_pthread.m4 forces C as the test language even if the AC_LANG is set as C++. This patch makes things work for me:
--- m4/ax_pthread.m4_orig 2013-06-15 20:03:36.000000000 +0300
+++ m4/ax_pthread.m4 2013-06-15 20:03:51.000000000 +0300
## -87,7 +87,6 ##
AU_ALIAS([ACX_PTHREAD], [AX_PTHREAD])
AC_DEFUN([AX_PTHREAD], [
AC_REQUIRE([AC_CANONICAL_HOST])
-AC_LANG_PUSH([C])
ax_pthread_ok=no
# We used to check for pthread.h first, but this fails if pthread.h
## -313,5 +312,4 ##
ax_pthread_ok=no
$2
fi
-AC_LANG_POP
])dnl AX_PTHREAD
It seems that the AX_PTHREAD macro is finding the -pthread compiler flag, and using that. But it looks as though for that particular flag, it should be specified to the linker as well (it apparently does the equivalent of -lpthread in the linker). I modified the macro as follows, so that the -pthread flag is specified as a linker flag too:
diff --git a/m4/ax_pthread.m4 b/m4/ax_pthread.m4
index 6d400ed..f426654 100644
--- a/m4/ax_pthread.m4
+++ b/m4/ax_pthread.m4
## -172,6 +172,12 ## for flag in $ax_pthread_flags; do
AC_MSG_CHECKING([whether pthreads work without any flags])
;;
+ -pthread)
+ AC_MSG_CHECKING([whether pthreads work with $flag])
+ PTHREAD_CFLAGS="$flag"
+ PTHREAD_LIBS="$flag"
+ ;;
+
-*)
AC_MSG_CHECKING([whether pthreads work with $flag])
PTHREAD_CFLAGS="$flag"
I guess I should submit this to the macro authors.
Expanding on a suggestion above (https://stackoverflow.com/a/20253318/221802) with exact script, this error went away for me after updating my PKbuild.sh script with pthread args:
./bootstrap && \
CPPFLAGS=" -g3 -Wall -pthread "\
CFLAGS=" -pthread -g3 -Wall "\
LDFLAGS=" -lpthread "\
./configure --enable-maintainer-mode \
--enable-debug \
--prefix=/usr \
--mandir=/usr/share/man \
--enable-pie \
--prefix=/usr \
--enable-library \
--enable-test \
......... [and so on]
I used the advice from another post: autoconf with -pthread
Here they mentioned you could download this file:
http://svn.sleuthkit.org/repos/sleuthkit/trunk/configure.ac
Place it into your m4 directory.
Then include this in your configure.ac:
ACX_PTHREAD
Finally, add this to your Makefile.am:
bin_PROGRAMS = main
main_SOURCES = main.c
main_CFLAGS = $(PTHREAD_CFLAGS)
main_LDADD = $(PTHREAD_LIBS)

Resources