I try to build 2.5.0.3 driver from file 2011_0719_RT3070_RT3370_RT5370_RT5372_Linux_STA_V2.5.0.3_DPO.bz2 to RT5370 chipset.
Install STLinux 2.4 under Ubuntu 10.04.4 x32, make under kernel linux-sh4-2.5.32.59_stm24_0211. But I wrote /opt/STM/STLinux-2.2/devkit/sources/kernel/linux-sh4-2.5.32.59_stm24_0211 in path instead of STLinux-2.4, because Makefile have some defects:
install:
ifeq ($(TARGET), LINUX)
ifneq (,$(findstring 2.4,$(LINUX_SRC)))
$(MAKE) -C $(RT28xx_DIR)/os/linux -f Makefile.4 install
else
$(MAKE) -C $(RT28xx_DIR)/os/linux -f Makefile.6 install
endif
endif
The mention in a path 2.4 build a kernel as 2.4 that in my case a mistake.
Wrote in Makefile:
PLATFORM = ST
...
LINUX_SRC = /opt/STM/STLinux-2.2/devkit/sources/kernel/linux-sh4-2.5.32.59_stm24_0211
CROSS_COMPILE = /opt/STM/STLinux-2.2/devkit/sh4/bin/sh4-linux-
In ./os/linux/config.mk wrote:
HAS_WPA_SUPPLICANT=y
HAS_NATIVE_WPA_SUPPLICANT_SUPPORT=y
CC := sh4-linux-gcc
LD := sh4-linux-ld
Build at run make command. But have the error:
script/Makefile.build:49: *** CFLAGS was changed in "/home/vitaliy/drv_src/os/linux/Makefile". Fix it to use EXTRA_CFLAGS.
Founded strings at ./os/linux/config.mk:
ifeq ($(PLATFORM),ST)
CFLAGS := -D__KERNEL__ -I$(LINUX_SRC)/include -I$(RT28xx_DIR)/include -Wall -O2 -Wundef -Wstrict-prototypes -Wno-trigraphs -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-aliasing -fno-common -fomit-frame-pointer -ffreestanding -m4-nofpu -o $(WFLAGS)
export CFLAGS
endif
And change CFLAGS to EXTRA_CFLAGS in them.
Again error:
sh4-linux-gcc: error: -pg and -fomit-frame-pointer are incompatible.
Ok. Remove flag -fomit-frame-pointer.
Again error:
error: cpu/cache.h: No such file or directory.
In string:
WFLAGS := -DAGGREGATION_SUPPORT -DPIGGYBACK_SUPPORT -DWMM_SUPPORT -DLINUX -Wall -Wstrict-prototypes -Wno-trigraphs
Remove flag -DLINUX.
Again error with unknown types (for example: ./os/linux/../../common/crypt_md5.c:638:1: error: unknown type name 'VOID' and so on with types 'UCHAR', 'ULONG' etc).
Second way to build with help of
KBUILD_NOPEDANTIC=1 make without changes in sources files of drivers.
Error in this case too:
./os/linux/../../common/crypt_md5.c:28:23: fatal error: rt_config.h: No such file or directory.
What is wrong in my building? Or can I fix sources code and build driver for SH4-platform.
Thank you!
I recently got myself the same adapter, and I was trying to cross compile for ARM, and run into the same problem.
Basically, you just have to add the include folder from the root of the driver package.
I did these modifications to get it working:
in DRIVER_DIR/Makefile, added:
PLATFORM = MYPLATFORM
All other platforms are commented out.
Later in same file:
ifeq ($(PLATFORM),MYPLATFORM)
LINUX_SRC = /DIR_TO_MY_KERNEL_SRC/freescale_mainline/linux-mainline
CROSS_COMPILE = /DIR_TO_MY_CROSS_COMPILER/arm-unknown-linux-uclibcgnueabi-
CROSS_COMPILE_INCLUDE = /DRIVER_DIR/include /*Might not be necessary*/
endif
Then in DRIVER_DIR/os/linux/config.mk, added:
ifeq ($(PLATFORM),MYPLATFORM)
EXTRA_CFLAGS := $(WFLAGS) -I$(RT28xx_DIR)/include
endif
Also, please note that in your kernel configuration you need to have couple of flags enabled:
CONFIG_WEXT_CORE=y
CONFIG_WEXT_PROC=y
CONFIG_WEXT_SPY=y
CONFIG_WEXT_PRIV=y
You can find them under Device Drivers-->Network Device Support-->Wireless LAN-->IEEE 802.11 for Host AP
I compile it just like this now:
DRIVER_DIR$ ARCH=arm make
Hope it helps!
Related
Background: I want to make some small modifications to lld, the llvm linker (specifically, to the WebAssembly version wasm-ld). I have implemented a WebAssembly interpreter on a smart card, and I want to be able to compile and link C programs for it. Some modifications are required; a smart card has two distinct types of memory, transient and persistent (or RAM and Flash), and I want the data sections that are present in the object files to be instantiated as two different memory items in the executable.
So I want to be able to debug wasm-ld, because it is a little complicated :-/
Problem: I can build wasm-ld from source, but when I try to build a debug version, it fails on a particular source file, because one of the object files is too big.
I am using MinGW for Windows. My configuration command is:
cmake -DCMAKE_BUILD_TYPE=Debug -DLLVM_ENABLE_PROJECTS=libcxxabi;libcxx;libunwind;lld
-G Ninja -DCMAKE_CXX_FLAGS="-D_WIN32_WINNT=0x601 -D_LIBCPP_HAS_THREAD_API_EXTERNAL=1" ../llvm
And the error message is (deep breath):
[2410/2592] Building CXX object
lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.obj FAILED:
lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.obj
C:\mingw-w64\x86_64-8.1.0-posix-seh-rt_v6-rev0\mingw64\bin\c++.exe
-DGTEST_HAS_RTTI=0 -D_FILE_OFFSET_B ITS=64 -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -ID:/clang/build/lib/Pass es -ID:/clang/llvm/lib/Passes -ID:/clang/build/include
-ID:/clang/llvm/include -D_WIN32_WINNT=0x601 -D
_LIBCPP_HAS_THREAD_API_EXTERNAL=1 -Wa,-mbig-obj -Werror=date-time -Wall -Wextra -Wno-unused-parameter
-Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallth rough -Wno-maybe-uninitialized -Wno-class-memaccess -Wno-noexcept-type -Wdelete-non-virtual-dtor -Wno- comment -Wmisleading-indentation -g -fno-exceptions -fno-rtti -std=c++14 -MD -MT lib/Passes/CMakeFile s/LLVMPasses.dir/PassBuilder.cpp.obj -MF
lib\Passes\CMakeFiles\LLVMPasses.dir\PassBuilder.cpp.obj.d -o
lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.obj -c
D:/clang/llvm/lib/Passes/PassBuilder.cpp
C:/mingw-w64/x86_64-8.1.0-posix-seh-rt_v6-rev0/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/8.1.0/../../.
./../x86_64-w64-mingw32/bin/as.exe:
lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.obj: section
.pdata$_ZN4llvm6detail17getAnalysisResultINS_27PassInstrumentationAnalysisENS_4LoopEJRNS_27LoopStandar
dAnalysisResultsEEJS5_RNS_10LPMUpdaterEEEENT_6ResultERNS_15AnalysisManagerIT0_JDpT1_EEERSB_St5tupleIJD
pT2_EE: string table overflow at offset 10000104
C:\Users\Tony\AppData\Local\Temp\ccXD93Jo.s: Assembler messages:
C:\Users\Tony\AppData\Local\Temp\ccXD93Jo.s: Fatal error: can't close
lib/Passes/CMakeFiles/LLVMPasses .dir/PassBuilder.cpp.obj: File too
big [2411/2592] Linking CXX static library lib\libLLVMAnalysis.a
ninja: build stopped: subcommand failed.
The important bit here is:
Fatal error: can't close lib/Passes/CMakeFiles/LLVMPasses
.dir/PassBuilder.cpp.obj: File too big
Has anybody met this problem? Does anybody have any suggestions to get this thing built? I don't need debug information for PassBuilder.cpp. How can I convery this to CMake or Ninja? (Please don't tell me to switch to MSVC...)
I built up a tool chain with gcc-6.2 with all the latest components.
CC = arm-none-eabi-gcc
AS = arm-none-eabi-as
LD = arm-none-eabi-ld
My Makefile flags are:
CFLAGS = -std=c11 -Wall -Werror -Wfatal-errors -Wstrict-prototypes -Wundef -gdwarf-2 -O2 -mthumb -mthumb-interwork -mcpu=cortex-m7 -mfloat-abi=softfp -mfpu=fpv4-sp-d16 -mlittle-endian
LDFLAGS = -nodefaultlibs -T./STM32F746NGHx_FLASH.ld -Wl,-Map=ugui3.map,--cref
I am linking by having via the compiler. CFLAGS at the front and LDFLAGS at the rear:
Linking: ugui3.elf
arm-none-eabi-gcc -std=c11 -Wall -Werror -Wfatal-errors -Wstrict prototypes -Wundef -gdwarf-2 -O2 -mthumb -mthumb-interwork -mcpu=cortex-m7 -mfloat-abi=softfp -mfpu=fpv4-sp-d16 -mlittle-endian stm32746g_discovery.o stm32746g_discovery_lcd.o stm32746g_discovery_sdram.o stm32746g_discovery_ts.o system_stm32f7xx.o stm32f7xx_hal.o stm32f7xx_hal_cortex.o stm32f7xx_hal_dma.o stm32f7xx_hal_dma2d.o stm32f7xx_hal_dma_ex.o stm32f7xx_hal_gpio.o stm32f7xx_hal_i2c.o stm32f7xx_hal_i2c_ex.o stm32f7xx_hal_ltdc.o stm32f7xx_hal_pwr.o stm32f7xx_hal_pwr_ex.o stm32f7xx_hal_rcc.o stm32f7xx_hal_rcc_ex.o stm32f7xx_hal_sdram.o stm32f7xx_hal_uart.o stm32f7xx_ll_fmc.o stm32f7xx_hal_msp.o stm32f7xx_it.o main.o ugui.o ltdc.o sdram.o ft5336.o small_printf.o startup_stm32f746xx.o --output ugui3.elf -nodefaultlibs -T./STM32F746NGHx_FLASH.ld -Wl,-Map=ugui3.map,--cref
I can reduce what is in CFLAGS to just:
CFLAGS = -mthumb -mthumb-interwork
Linking: ugui3.elf
arm-none-eabi-gcc -mthumb -mthumb-interwork -mcpu=cortex-m7 -mfloat-abi=softfp -mfpu=fpv4-sp-d16 -mlittle-endian stm32746g_discovery.o stm32746g_discovery_lcd.o stm32746g_discovery_sdram.o stm32746g_discovery_ts.o system_stm32f7xx.o stm32f7xx_hal.o stm32f7xx_hal_cortex.o stm32f7xx_hal_dma.o stm32f7xx_hal_dma2d.o stm32f7xx_hal_dma_ex.o stm32f7xx_hal_gpio.o stm32f7xx_hal_i2c.o stm32f7xx_hal_i2c_ex.o stm32f7xx_hal_ltdc.o stm32f7xx_hal_pwr.o stm32f7xx_hal_pwr_ex.o stm32f7xx_hal_rcc.o stm32f7xx_hal_rcc_ex.o stm32f7xx_hal_sdram.o stm32f7xx_hal_uart.o stm32f7xx_ll_fmc.o stm32f7xx_hal_msp.o stm32f7xx_it.o main.o ugui.o ltdc.o sdram.o ft5336.o small_printf.o startup_stm32f746xx.o --output ugui3.elf -nodefaultlibs -T./STM32F746NGHx_FLASH.ld -Wl,-Map=ugui3.map,--cref
My questions:
Is invoking the linker (shown above) via the compiler preferred?
Is the first method better than the second method? Is there a better way?
I migrated to a few other projects and continued looking into this.
A:
arm-none-eabi-gcc -mthumb < .o files > --output image.elf -T./lpc1768.ld -nostartfiles -Wl,-Map=image.map,--cref
B:
arm-none-eabi-gcc < .o files > --output image.elf -T./lpc1768.ld -nostartfiles -Wl,-Map=image.map,--cref -L /usr/local/arm-none-eabi/lib/thumb
A and B both work. Method A with "-mthumb" assumes you want to link with the thumb version of libc.a. Method B specifies the thumb version as -L /usr/local/arm-none-eabi/lib/thumb
On yet another project I can get away with a minimal line on the link, no -mthumb flag and no library path.
C:
arm-none-eabi-gcc < .o files > --output image.elf -T./lpc2132.ld -nostartfiles -Wl,-Map=image.map,--cref
Method C works on a lpc2132(arm7tdmi-s) project. But method C does not work on the lpc1768(Cortex-m3) project (A & B). They have almost identical .ld files and start files.
The reason that method C does not work (no explicit library or path) is that the ARM libraries are linked by default. Since the lpc1768 is a thumb-only processor this is not good. A "-mthumb" or a "-L path to thumb library" is necessary.
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.
I am currently try to compile these files using HDF5
I have directly linked and included everything necessary ( I think) but still the compile unable to find the files that is needed
This is my Makefile:
CC = h5cc
FC = h5fc
LD = h5fc
FDEBUG = -std -g -traceback
CFLAGS = -g -O0 -Wall -pedantic
FFLAGS = -g -O0 -Wall -I$(H5DIR)/include -L$(H5DIR)/lib/libhdf5hl_fortran.a
LDFLAGS = -I$(H5DIR)/include -L$(H5DIR)/lib/libhdf5hl_fortran.a
#LDFLAGS = -I$(MKLROOT)/include -L$(MKLROOT) -mkl=sequential
# -opt-block-factor=16 -opt-prefetch=4 \
.SUFFIXES:
.SUFFIXES: .c .f .f90 .F90 .o
OBJS = timing.o \
kinds.o \
rw_matrix.o \
EXE = matmul_omp.exe
all: $(EXE)
$(EXE): $(OBJS) matmul_omp.o
$(LD) $(LDFLAGS) -o $# $^
.f90.o:
-$(RM) -f $*.o $*.mod
$(FC) $(FFLAGS) -c $<
.c.o:
$(CC) $(CFLAGS) -c $<
.PHONEY: clean
clean:
THis is the err:
h5fc -I/curc/tools/x_86_64/rh6/hdf5/1.8.13/szip/2.1/zlib/1.2.8/jpeglib/9a/openmpi/1.8.2/intel/13.0.0/include -L/curc/tools/x_86_64/rh6/hdf5/1.8.13/szip/2.1/zlib/1.2.8/jpeglib/9a/openmpi/1.8.2/intel/13.0.0/lib/libhdf5hl_fortran.a -o matmul_omp.exe timing.o matmul_omp.o
gfortran: /usr/lib64/libhdf5hl_fortran.a: No such file or directory
gfortran: /usr/lib64/libhdf5_hl.a: No such file or directory
gfortran: /usr/lib64/libhdf5_fortran.a: No such file or directory
gfortran: /usr/lib64/libhdf5.a: No such file or directory
As you can see that I directly link libhdf5hl_fortran.a. but i dont know why the error is giving a different directory /usr/lib64/
I think you have a couple of things wrong here.
If you are using h5fc then you shouldn't need to add all the include and lib paths. That is the whole point of the helper applications.
You are adding the paths that have Intel, yet your h5fc has a GNU (gfortran) error.
The gfortran build of HDF5 looks as if it does not have the fortran bindings built.
I would suggest trying the following. Using the full paths (as you have done) but call ifort instead of h5fc:
ifort -I/curc/tools/x_86_64/rh6/hdf5/1.8.13/szip/2.1/zlib/1.2.8/jpeglib/9a/openmpi/1.8.2/intel/13.0.0/include \
-L/curc/tools/x_86_64/rh6/hdf5/1.8.13/szip/2.1/zlib/1.2.8/jpeglib/9a/openmpi/1.8.2/intel/13.0.0/lib/libhdf5hl_fortran.a \
-o matmul_omp.exe timing.o matmul_omp.o
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)