crosscompile libcurl for arm on freeRtos and LWIP - c

I'm trying to cross-compile libcurl from a linux ubuntu x86_64 system.
My target is an embedded platform based on an arm crotex-m4 NXP micro, flash ram and flash memory are not a concern.
AFAIK libcurl does not require a OS to run over but just wanted a UNIX like flavaour TCP_IP stack. To complain with this point I use a port of LWIP tcp-ip stack for my architecture.
In addition I've already built a library (.a) out from FreeRtos + LWIP + drivers and named it libProject_prova1.a (you will find it in the directives)
Then I wrote a shell script to perform the configure step of the make build that shows as follows:
#! /bin/sh
export PATH=/usr/local/mcuxpressoide-10.0.2_411/ide/tools/bin:$PATH
PATH=/home/user/Documents/MCUXpresso_10.0.2_411/workspace/libProject_prova1/Release:$PATH
export ROOTDIR="${PWD}"
export MBEDDIR=/home/user/Desktop/mbed_TLS_NXP/build
export PROJDIR=/home/user/Documents/MCUXpresso_10.0.2_411/workspace/libProject_prova1
cd ./curl-7.55.0
export CPPFLAGS="-DUSE_LWIPSOCK -D__REDLIB__ -DLWIP_DNS=1 -DUSE_RTOS=1 -DCR_INTEGER_PRINTF -DSDK_DEBUGCONSOLE=0 -D__MCUXPRESSO -D__USE_CMSIS -DNDEBUG -DFSL_RTOS_FREE_RTOS -DSDK_OS_FREE_RTOS -DCPU_LPC54608J512ET180 -DCPU_LPC54608J512ET180_cm4 -I${PROJDIR}/lwip/src/include/lwip -I${PROJDIR}/lwip/src/include/lwip/priv -I${PROJDIR}/lwip/src/include/lwip/prot -I${PROJDIR}/lwip/src/include/netif -I${PROJDIR}/lwip/src/include/netif/ppp -I${PROJDIR}/lwip/src/include/netif/ppp/polarssl -I${PROJDIR}/lwip/src/include/posix -I${PROJDIR}/lwip/src/include/posix/sys -I${PROJDIR}/lwip/port -I${PROJDIR}/lwip/port/arch -I${PROJDIR}/lwip/src -I${PROJDIR}/lwip/src/include -I${PROJDIR}/lwip/src/netif -I${PROJDIR} -I${PROJDIR}/drivers -I${PROJDIR}/utilities -I${PROJDIR}/freertos -I${PROJDIR}/CMSIS -I${PROJDIR}/startup -I${MBEDDIR}/include/mbedtls"
export CFLAGS="-O0 -fno-common -g3 -Wall -c -fmessage-length=0 -fno-builtin -ffunction-sections -fdata-sections -mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -mfloat-abi=hard -mthumb -specs=redlib.specs"
export LDFLAGS="-L${MBEDDIR}/lib -L${PROJDIR}/Release"
export LIBS="-lProject_prova1"
export CROSS_COMPILE=arm-none-eabi
export AR=${CROSS_COMPILE}-ar
export AS=${CROSS_COMPILE}-as
export LD=${CROSS_COMPILE}-ld
export RANLIB=${CROSS_COMPILE}-ranlib
export CC=${CROSS_COMPILE}-gcc
export NM=${CROSS_COMPILE}-nm
export PREFIX=${ROOTDIR}/build
./configure --target=${CROSS_COMPILE} --host=${CROSS_COMPILE} --prefix=${ROOTDIR}/build --build=x86_64-linux-gnu --without-ssl --with-mbedtls --enable-static --disable-shared --disable-ftp --disable-file --disable-pop3 --disable-smb --disable-smtp --disable-imap --disable-ldap --disable-ldaps --disable-dict --disable-telnet --disable-tftp --disable-manual --disable-ipv6 --disable-unix-sockets --disable-versioned-symbols --disable-ares --disable-sspi --disable-gopher --without-zlib --without-libssh2 --without-ca-bundle -without-ca-path --without-libidn --without-librtmp --without-libidn
Unfortunatly what I obtain is:
checking for grep... /bin/grep
checking for egrep... /bin/grep -E
checking for a BSD-compatible install... /usr/bin/install -c
checking for arm-none-eabi-gcc... arm-none-eabi-gcc
checking whether the C compiler works... no
configure: error: in `/home/user/Desktop/curl_libProject_prova1/curl-7.55.0':
configure: error: C compiler cannot create executables
See `config.log' for more details
In the log file I cannot find an explanation:
configure:4781: checking whether the C compiler works
configure:4803: arm-none-eabi-gcc -O0 -fno-common -g3 -Wall -c -fmessage-length=0 -fno-builtin -ffunction-sections -fdata-sections -mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -mfloat-abi=hard -mthumb --specs=redlib.specs -D__REDLIB__ -DUSE_LWIPSOCK -DLWIP_DNS=1 -DUSE_RTOS=1 -DCR_INTEGER_PRINTF -DSDK_DEBUGCONSOLE=0 -D__MCUXPRESSO -D__USE_CMSIS -DNDEBUG -DFSL_RTOS_FREE_RTOS -DSDK_OS_FREE_RTOS -DCPU_LPC54608J512ET180 -DCPU_LPC54608J512ET180_cm4 -I/home/user/Documents/MCUXpresso_10.0.2_411/workspace/libProject_prova1/lwip/src/include/lwip -I/home/user/Documents/MCUXpresso_10.0.2_411/workspace/libProject_prova1/lwip/src/include/lwip/priv -I/home/user/Documents/MCUXpresso_10.0.2_411/workspace/libProject_prova1/lwip/src/include/lwip/prot -I/home/user/Documents/MCUXpresso_10.0.2_411/workspace/libProject_prova1/lwip/src/include/netif -I/home/user/Documents/MCUXpresso_10.0.2_411/workspace/libProject_prova1/lwip/src/include/netif/ppp -I/home/user/Documents/MCUXpresso_10.0.2_411/workspace/libProject_prova1/lwip/src/include/netif/ppp/polarssl -I/home/user/Documents/MCUXpresso_10.0.2_411/workspace/libProject_prova1/lwip/src/include/posix -I/home/user/Documents/MCUXpresso_10.0.2_411/workspace/libProject_prova1/lwip/src/include/posix/sys -I/home/user/Documents/MCUXpresso_10.0.2_411/workspace/libProject_prova1/lwip/port -I/home/user/Documents/MCUXpresso_10.0.2_411/workspace/libProject_prova1/lwip/port/arch -I/home/user/Documents/MCUXpresso_10.0.2_411/workspace/libProject_prova1/lwip/src -I/home/user/Documents/MCUXpresso_10.0.2_411/workspace/libProject_prova1/lwip/src/include -I/home/user/Documents/MCUXpresso_10.0.2_411/workspace/libProject_prova1/lwip/src/netif -I/home/user/Documents/MCUXpresso_10.0.2_411/workspace/libProject_prova1 -I/home/user/Documents/MCUXpresso_10.0.2_411/workspace/libProject_prova1/drivers -I/home/user/Documents/MCUXpresso_10.0.2_411/workspace/libProject_prova1/utilities -I/home/user/Documents/MCUXpresso_10.0.2_411/workspace/libProject_prova1/freertos -I/home/user/Documents/MCUXpresso_10.0.2_411/workspace/libProject_prova1/CMSIS -I/home/user/Documents/MCUXpresso_10.0.2_411/workspace/libProject_prova1/startup -I/home/user/Desktop/mbed_TLS_NXP/build/include/mbedtls -L/home/user/Desktop/mbed_TLS_NXP/build/lib -L/home/user/Documents/MCUXpresso_10.0.2_411/workspace/libProject_prova1/Release conftest.c -lProject_prova1 >&5
configure:4807: $? = 0
configure:4845: result: no
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "curl"
| #define PACKAGE_TARNAME "curl"
| #define PACKAGE_VERSION "-"
| #define PACKAGE_STRING "curl -"
| #define PACKAGE_BUGREPORT "a suitable curl mailing list: https://curl.haxx.se/mail/"
| #define PACKAGE_URL ""
| /* end confdefs.h. */
|
| int main (void)
| {
|
| ;
| return 0;
| }
configure:4850: error: in `/home/user/Desktop/curl_libProject_prova1/curl-7.55.0':
configure:4852: error: C compiler cannot create executables
See `config.log' for more details
I'm not understanding where the problem is.
redlib.spec is a nxp custom C library, see:
https://community.nxp.com/thread/389152
It's important to use redlib otherwise I will have conflicts with what is defined in LWIP and arm-gnu-none-eabi standard C lib (e.g. redefinition of structure or typedef).
I've tried a simple dumb compilation an linkage to see if I was messing up something in the cpplfags, libs and so on...and noticed that it works.
For this example I did the following:
C source:
#include "lwip/netdb.h"
int main(){
char* name="www.google.it";
gethostbyname(name);
return 0;
}
compiler directives:
export PATH=/usr/local/mcuxpressoide-10.0.2_411/ide/tools/bin:$PATH
PATH=/home/user/Documents/MCUXpresso_10.0.2_411/workspace/libProject_prova1/Release:$PATH
export PROJDIR=/home/user/Documents/MCUXpresso_10.0.2_411/workspace/libProject_prova1
export CPPFLAGS="-DUSE_LWIPSOCK -D__REDLIB__ -DLWIP_DNS=1 -DUSE_RTOS=1 -DCR_INTEGER_PRINTF -DSDK_DEBUGCONSOLE=0 -D__MCUXPRESSO -D__USE_CMSIS -DNDEBUG -DFSL_RTOS_FREE_RTOS -DSDK_OS_FREE_RTOS -DCPU_LPC54608J512ET180 -DCPU_LPC54608J512ET180_cm4 -I${PROJDIR}/lwip/src/include/lwip -I${PROJDIR}/lwip/src/include/lwip/priv -I${PROJDIR}/lwip/src/include/lwip/prot -I${PROJDIR}/lwip/src/include/netif -I${PROJDIR}/lwip/src/include/netif/ppp -I${PROJDIR}/lwip/src/include/netif/ppp/polarssl -I${PROJDIR}/lwip/src/include/posix -I${PROJDIR}/lwip/src/include/posix/sys -I${PROJDIR}/lwip/port -I${PROJDIR}/lwip/port/arch -I${PROJDIR}/lwip/src -I${PROJDIR}/lwip/src/include -I${PROJDIR}/lwip/src/netif -I${PROJDIR} -I${PROJDIR}/drivers -I${PROJDIR}/utilities -I${PROJDIR}/freertos -I${PROJDIR}/CMSIS -I${PROJDIR}/startup"
arm-none-eabi-gcc -O0 -fno-common -g3 -Wall -c -fmessage-length=0 -fno-builtin -ffunction-sections -fdata-sections -mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -mfloat-abi=hard -mthumb -D__REDLIB__ -specs=redlib.specs main.c ${CPPFLAGS} -L${PROJDIR}/Release -lProject_prova1 -o main
I will kindly appreciate any help you may give me.

Related

Linker accuses "undefined reference" for a single function in file

I have a header file that declares two functions:
// ff.h
FRESULT f_mount (FATFS* fs, const TCHAR* path, BYTE opt);
FRESULT f_mkfs (const TCHAR* path, const MKFS_PARM* opt, void* work, UINT len);
And a source file that defines both functions:
// ff.c
#include "ff.h"
FRESULT f_mount (FATFS* fs, const TCHAR* path, BYTE opt) {...}
FRESULT f_mkfs (const TCHAR* path, const MKFS_PARM* opt, void* work, UINT len) {...}
When I call them from my main file, however, one of the functions works perfectly and the other raises undefined reference, even though they are in the same file:
#include "ff.h"
[...]
fresult = f_mount(&fs, "0:", 1);
[...]
fresult = f_mkfs("0:", &fmt_opt, work, sizeof work);
>> output:
11:24:45 **** Incremental Build of configuration Debug for project laser_manual ****
make -j8 all
arm-none-eabi-gcc -o "laser_manual.elf" #"objects.list" -mcpu=cortex-m4 -T"C:\Users\Pesquisa2\Documents\stm32\LM_STM32\STM32F407ZGTX_FLASH.ld" --specs=nosys.specs -Wl,-Map="laser_manual.map" -Wl,--gc-sections -static --specs=nano.specs -mfpu=fpv4-sp-d16 -mfloat-abi=hard -mthumb -u _printf_float -u _scanf_float -Wl,--start-group -lc -lm -Wl,--end-group
c:\st\stm32cubeide_1.9.0\stm32cubeide\plugins\com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.10.3-2021.10.win32_1.0.0.202111181127\tools\arm-none-eabi\bin\ld.exe: ./Src/main.o: in function `main':
C:/Users/Pesquisa2/Documents/stm32/LM_STM32/Debug/../Src/main.c:55: undefined reference to `f_mkfs'
collect2.exe: error: ld returned 1 exit status
make: *** [makefile:68: laser_manual.elf] Error 1
"make -j8 all" terminated with exit code 2. Build might be incomplete.
How is this possible?
(Obs.: this are standard Elm Chan library)
Paths
I'm using STM32CubeMX for compilation and debugging. On properties, I set my C/C++ General/Paths and Symbols as following:
Includes: /laser_manual/FATFS/inc
Source Location: /laser_manual/FATFS
Tool Settings
MCU GCC Assembler:
-mcpu=cortex-m4 -g3 -DDEBUG -c -I"C:\Users\Pesquisa2\Documents\stm32\LM_STM32\FATFS\src" -x assembler-with-cpp --specs=nano.specs -mfpu=fpv4-sp-d16 -mfloat-abi=hard -mthumb
MCU GCC Compiler:
-mcpu=cortex-m4 -std=gnu11 -g3 -DDEBUG -DSTM32 -DSTM32F4 -DSTM32F407ZGTx -c -I"C:\Users\Pesquisa2\STM32Cube\Repository\STM32Cube_FW_F4_V1.27.0\Drivers\CMSIS\Include" -I"C:\Users\Pesquisa2\STM32Cube\Repository\STM32Cube_FW_F4_V1.27.0\Drivers\CMSIS\Device\ST\STM32F4xx\Include" -I"C:\Users\Pesquisa2\Documents\stm32\LM_STM32\Inc\App" -I"C:\Users\Pesquisa2\Documents\stm32\LM_STM32\Inc\HAL" -I"C:\Users\Pesquisa2\Documents\stm32\LM_STM32\Inc" -I"C:\Users\Pesquisa2\Documents\stm32\LM_STM32\Src\Midware" -I"C:\Users\Pesquisa2\Documents\stm32\LM_STM32\Src\HAL" -I"C:\Users\Pesquisa2\Documents\stm32\LM_STM32\Src\App" -I"C:\Users\Pesquisa2\Documents\stm32\LM_STM32\Inc\Midware" -I"C:\Users\Pesquisa2\Documents\stm32\LM_STM32\FATFS\inc" -O0 -ffunction-sections -fdata-sections -Wall -fstack-usage --specs=nano.specs -mfpu=fpv4-sp-d16 -mfloat-abi=hard -mthumb
MCU GCC Linker:
-mcpu=cortex-m4 -T"C:\Users\Pesquisa2\Documents\stm32\LM_STM32\STM32F407ZGTX_FLASH.ld" --specs=nosys.specs -Wl,-Map="${BuildArtifactFileBaseName}.map" -Wl,--gc-sections -static --specs=nano.specs -mfpu=fpv4-sp-d16 -mfloat-abi=hard -mthumb -u _printf_float -u _scanf_float -Wl,--start-group -lc -lm -Wl,--end-group
you need to make sure that two defines are:
FF_FS_READOLNY == 0
FF_USE_MKFS == 1
Some older versions use names without the FF
edit ffconf.h

Compiling gcc fails while trying to link libgcc

I am trying to build gcc for my linux. I'm cross compiling since I don't have a preexisting gcc.
I'm using musl as libc.
I configured gcc like this:
export CFLAGS="-pipe -march=native -fstack-protector-strong -fno-plt -pie -fpie"
../gcc-10.1.0/configure --target=x86_64-unknown-linux-musl \
--host=x86_64-unknown-linux-musl --build=x86_64-pc-linux-gnu \
--enable-lto --prefix=/usr --disable-nls --disable-multilib \
--enable-languages=c --without-isl --with-newlib --disable-libsanitizer \
--with-sysroot=/root/mnt
When I run make gcc compiles for a few minutes. After a while the build tries to execute the following
x86_64-unknown-linux-musl-gcc -O2 -g -O2 -pipe -march=native -fstack-protector-strong -fno-plt -pie -fpie -DIN_GCC -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fpic -mlong-double-80 -DUSE_ELF_SYMVER -DGTHREAD_USE_WEAK=0 -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc -shared -nodefaultlibs -Wl,--soname=libgcc_s.so.1 -Wl,--version-script=libgcc.map -o ./libgcc_s.so.1.tmp -g -O2 -pipe -march=native -fstack-protector-strong -fno-plt -pie -fpie -B./ _muldi3_s.o _negdi2_s.o _lshrdi3_s.o _ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o _clear_cache_s.o _trampoline_s.o __main_s.o _absvsi2_s.o _absvdi2_s.o _addvsi3_s.o _addvdi3_s.o _subvsi3_s.o _subvdi3_s.o _mulvsi3_s.o _mulvdi3_s.o _negvsi2_s.o _negvdi2_s.o _ctors_s.o _ffssi2_s.o _ffsdi2_s.o _clz_s.o _clzsi2_s.o _clzdi2_s.o _ctzsi2_s.o _ctzdi2_s.o _popcount_tab_s.o _popcountsi2_s.o _popcountdi2_s.o _paritysi2_s.o _paritydi2_s.o _powisf2_s.o _powidf2_s.o _powixf2_s.o _mulhc3_s.o _mulsc3_s.o _muldc3_s.o _mulxc3_s.o _divhc3_s.o _divsc3_s.o _divdc3_s.o _divxc3_s.o _bswapsi2_s.o _bswapdi2_s.o _clrsbsi2_s.o _clrsbdi2_s.o _fixunssfsi_s.o _fixunsdfsi_s.o _fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o _fixxfdi_s.o _fixunssfdi_s.o _fixunsdfdi_s.o _fixunsxfdi_s.o _floatdisf_s.o _floatdidf_s.o _floatdixf_s.o _floatundisf_s.o _floatundidf_s.o _floatundixf_s.o _divdi3_s.o _moddi3_s.o _divmoddi4_s.o _udivdi3_s.o _umoddi3_s.o _udivmoddi4_s.o _udiv_w_sdiv_s.o sfp-exceptions_s.o addtf3_s.o divtf3_s.o multf3_s.o negtf2_s.o subtf3_s.o unordtf2_s.o fixtfsi_s.o fixunstfsi_s.o floatsitf_s.o floatunsitf_s.o fixtfdi_s.o fixunstfdi_s.o floatditf_s.o floatunditf_s.o fixtfti_s.o fixunstfti_s.o floattitf_s.o floatuntitf_s.o extendsftf2_s.o extenddftf2_s.o extendxftf2_s.o trunctfsf2_s.o trunctfdf2_s.o trunctfxf2_s.o getf2_s.o letf2_s.o eqtf2_s.o _divtc3_s.o _multc3_s.o _powitf2_s.o enable-execute-stack_s.o unwind-dw2_s.o unwind-dw2-fde-dip_s.o unwind-sjlj_s.o unwind-c_s.o emutls_s.o libgcc.a -lc
in my build directory under x86_64-unknown-linux-musl/libgcc which fails with:
/root/mnt/tools/lib/gcc/x86_64-unknown-linux-musl/10.1.0/../../../../x86_64-unknown-linux-musl/bin/ld: /root/mnt/tools/lib/gcc/x86_64-unknown-linux-musl/10.1.0/../../../../x86_64-unknown-linux-musl/lib/Scrt1.o: in function `_start_c':
Scrt1.c:(.text._start_c+0x1b): undefined reference to `main'
collect2: error: ld returned 1 exit status
I verified with objdump -t crt1.o and objdump -t Scrt1.o that these object files define main, which they do.
Im pretty confused by now because the name libgcc suggests that it's a library, which of course does not have a main method. Why is ld expecting one? What is the build trying to do here?

autoconf ignoring CFLAGS?

I'm building a package (vice 3.4) that uses GNU autoconf. Running ./configure fails with the following message:
checking size of time_t... 0
configure: error: can not figure type of time_t
error: Bad exit status from /var/tmp/rpm-tmp.wIgnPw (%build)
Examining config.log, this appears to be failing due to the following error:
/usr/bin/ld: /tmp/ccMTSdtB.o: relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: final link failed: nonrepresentable section on output
collect2: error: ld returned 1 exit status
I tried resolving this by adding -fPIC to the CFLAGS environment variable:
CFLAGS=-fPIC ./configure
But while this is clearly being used during other stages of ./configure...
configure:3657: checking whether the C compiler works
configure:3679: gcc -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -D_GNU_SOURCE=1 -fPIC -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld conftest.c >&5
It doesn't seem to be used in the feature tests related to time_t:
configure:9684: checking for time_t in time.h
configure:9700: gcc -c -g -O3 -Wall -Wformat -Wformat-signedness -Wshadow -Wpointer-arith -Wstrict-prototypes -Wuninitialized -Wunreachable-code -Wno-unused-parameter -Werror=implicit-function-declaration -Wfatal-errors conftest.c >&5
[...]
configure:9753: checking size of time_t
configure:9758: gcc -o conftest -g -O3 -Wall -Wformat -Wformat-signedness -Wshadow -Wpointer-arith -Wstrict-prototypes -Wuninitialized -Wunreachable-code -Wno-unused-parameter -Werror=implicit-function-declaration -Wfatal-errors -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld conftest.c >&5
Looking at configure.ac, the above code is generated from:
if test $bu_cv_decl_time_t_time_h = yes; then
AC_CHECK_SIZEOF([time_t],[],[#include <time.h>])
else
AC_CHECK_SIZEOF([time_t],[],[#include <sys/types.h>])
fi
I've been able to work around the problem by redefining CC instead:
CC="gcc -fPIC" ./configure
This works, but it's ugly (what if something wants to call gcc without -fPIC?). Is there a reason that AC_CHECK_SIZEOF is ignoring CFLAGS?
It looks like the suspicion I expressed in comments is confirmed. The VICE configure program intentionally substitutes its own choice of CFLAGS for the user's specified ones when it performs some of its checks, including the ones related to time_t. Thus, this is not a question of Autoconf ignoring your flags, but rather of VICE doing so.
I reiterate that I think it's a more significant issue that configuration doesn't work out of the box for you in the first place. I suggest raising that as an issue against the project. Although I don't like that VICE is so cavalier about ignoring the user's CFLAGS, that's a separate matter, and one that I suspect wouldn't get much traction with the devs.
John correctly identified the issue, and based on that information I did a little digging and I've figure out what's going on.
I'm building this under the control of rpm, which calls configure like this:
%configure --enable-native-gtk3ui $COMMON_FLAGS
That %configure expands into a chunk of shell code that looks like this:
CFLAGS="${CFLAGS:--O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection}" ; export CFLAGS ;
CXXFLAGS="${CXXFLAGS:--O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection}" ; export CXXFLAGS ;
FFLAGS="${FFLAGS:--O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -I/usr/lib64/gfortran/modules}" ; export FFLAGS ;
FCFLAGS="${FCFLAGS:--O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -I/usr/lib64/gfortran/modules}" ; export FCFLAGS ;
LDFLAGS="${LDFLAGS:--Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld}" ; export LDFLAGS;
[ "1" = 1 ] && for i in $(find $(dirname ./configure) -name config.guess -o -name config.sub) ; do
[ -f /usr/lib/rpm/redhat/$(basename $i) ] && /usr/bin/rm -f $i && /usr/bin/cp -fv /usr/lib/rpm/redhat/$(basename $i) $i ;
done ;
[ "1" = 1 ] && [ x != "x-Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld" ] &&
for i in $(find . -name ltmain.sh) ; do
/usr/bin/sed -i.backup -e 's~compiler_flags=$~compiler_flags="-Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld"~' $i
done ;
./configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu \
--program-prefix= \
--disable-dependency-tracking \
\
--prefix=/usr \
--exec-prefix=/usr \
--bindir=/usr/bin \
--sbindir=/usr/sbin \
--sysconfdir=/etc \
--datadir=/usr/share \
--includedir=/usr/include \
--libdir=/usr/lib64 \
--libexecdir=/usr/libexec \
--localstatedir=/var \
--sharedstatedir=/var/lib \
--mandir=/usr/share/man \
--infodir=/usr/share/info
Of particular interest is the fact that this is setting LDFLAGS. The failing config test is:
gcc -o conftest -g -O3 -Wall -Wformat -Wformat-signedness -Wshadow \
-Wpointer-arith -Wstrict-prototypes -Wuninitialized -Wunreachable-code \
-Wno-unused-parameter -Werror=implicit-function-declaration \
-Wfatal-errors -Wl,-z,relro -Wl,--as-needed -Wl,-z,now \
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld conftest.c
That -specs line points to a gcc spec file that looks like this:
*self_spec:
+ %{!static:%{!shared:%{!r:-pie}}}
That effectively adds the -pie option to the command line. We can reproduce the failure with a simple hello.c program:
#include <stdio.h>
#include <unistd.h>
int main(int argc, char **argv) {
printf("hello world\n");
return(0);
}
Like this:
$ gcc -o hello -pie hello.c
/usr/bin/ld: /tmp/ccXRAu6r.o: relocation R_X86_64_32 against `.rodata' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/ld: final link failed: nonrepresentable section on output
collect2: error: ld returned 1 exit status
But here's the thing:
A successful gcc invocation looks like this:
gcc -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 \
-Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong \
-grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 \
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic \
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection \
-D_GNU_SOURCE=1 -fPIC -Wl,-z,relro -Wl,--as-needed -Wl,-z,now \
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld conftest.c
Note that there is a second -specs option there, that points to /usr/lib/rpm/redhat/redhat-hardened-cc1, which looks like:
*cc1_options:
+ %{!r:%{!fpie:%{!fPIE:%{!fpic:%{!fPIC:%{!fno-pic:-fPIE}}}}}}
This takes care of adding -fPIE to the command line, which results in a successful compile:
$ gcc -o hello -pie -fPIE hello.c
$
We're hitting this failure because the configure script is replacing CFLAGS during the tests, but preserving LDFLAGS. This results in a faulty command line.
For my own purposes, I'm just patching the configure script to not replace CFLAGS during the time_t related tests. This seems both expedient (it's a one-character diff if I just comment out the appropriate line) and effective (it results in a successful build).
I will probably report this upstream as a bug.

compling glibc: /glibc-2.7/w/elf/ld.so: No such file or directory

I have to install a software in the directory of the supercomputer center, but I cannot use sudo, root, even apt-get, yum... The software requires glibc2.7, so I have to manually install both gcc and glibc (since I cannot change the path for built-in gcc to find the glibc).
The gcc seems to be installed successfully:
[geosign#node117 ~/binutils/bin]$ gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: /public/home/geosign/software/gcc/configure -prefix=/public/home/geosign/gcc --with-gmp=/public/home/geosign/Gcc --with- mpfr=/public/home/geosign/Gcc --with-mpc=/public/home/geosign/Gcc --with-ppl=/public/home/geosign/ppl --with-cloog=/public/home/geosign/ppl --enable-threads=posix CFLAGS=-I/public/home/geosign/ppl/lib:/public/home/geosign/Gcc/lib CPPFLAGS=-I/public/home/geosign/ppl/lib:/public/home/geosign/Gcc/lib CXXFLAGS=-I/public/home/geosign/ppl/lib:/public/home/geosign/Gcc/lib --enable-languages=c,c++,fortran --disable-multilib
Thread model: posix
gcc version 4.4.7 (GCC)
However, when I use "make" to compile the glibc, it shows:
make[3]: Leaving directory `/public/home/geosign/software/glibc/elf'
gcc -B/public/home/geosign/binutils/ -nostdlib -nostartfiles -r -o /public/home/geosign/software/build/glibc/elf/librtld.os '-Wl,-(' /public/home/geosign/software/build/glibc/elf/dl-allobjs.os /public/home/geosign/software/build/glibc/elf/rtld-libc.a -lgcc '-Wl,-)' \
-Wl,-Map,/public/home/geosign/software/build/glibc/elf/librtld.os.map
gcc -B/public/home/geosign/binutils/ -nostdlib -nostartfiles -shared \
-Wl,-z,combreloc -Wl,-z,relro -Wl,--hash-style=both -Wl,-z,defs -Wl,--verbose 2>&1 | \
LC_ALL=C \
sed -e '/^=========/,/^=========/!d;/^=========/d' \
-e 's/\. = 0 + SIZEOF_HEADERS;/& _begin = . - SIZEOF_HEADERS;/' \
> /public/home/geosign/software/build/glibc/elf/ld.so.lds
gcc -B/public/home/geosign/binutils/ -nostdlib -nostartfiles -shared -o /public/home/geosign/software/build/glibc/elf/ld.so \
-Wl,-z,combreloc -Wl,-z,relro -Wl,--hash-style=both -Wl,-z,defs \
/public/home/geosign/software/build/glibc/elf/librtld.os -Wl,--version-script=/public/home/geosign/software/build/glibc/ld.map \
-Wl,-soname=ld-linux-x86-64.so.2 -T /public/home/geosign/software/build/glibc/elf/ld.so.lds
/public/home/geosign/software/build/glibc/elf/librtld.os: In function `_dl_start_final':
/public/home/geosign/software/glibc/elf/rtld.c:290: undefined reference to `_begin'
/public/home/geosign/binutils/bin/ld: /public/home/geosign/software/build/glibc/elf/librtld.os: relocation R_X86_64_PC32 against undefined hidden symbol `_begin' can not be used when making a shared object
/public/home/geosign/binutils/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status
make[2]: *** [/public/home/geosign/software/build/glibc/elf/ld.so] Error 1
make[2]: Leaving directory `/public/home/geosign/software/glibc/elf'
make[1]: *** [elf/subdir_lib] Error 2
make[1]: Leaving directory `/public/home/geosign/software/glibc'
make: *** [all] Error 2
These sentences in Makefile of elf are:
$(objpfx)ld.so: $(objpfx)librtld.os $(ld-map)
#rm -f $#.lds
$(LINK.o) -nostdlib -nostartfiles -shared $(z-now-$(bind-now)) \
$(LDFLAGS-rtld) -Wl,-z,defs -Wl,--verbose 2>&1 | \
LC_ALL=C \
sed -e '/^=========/,/^=========/!d;/^=========/d' \
-e 's/\. = 0 + SIZEOF_HEADERS;/& _begin = . - SIZEOF_HEADERS;/' \
> $#.lds
$(LINK.o) -nostdlib -nostartfiles -shared -o $# \
$(LDFLAGS-rtld) -Wl,-z,defs $(z-now-$(bind-now)) \
$(filter-out $(map-file),$^) $(load-map-file) \
-Wl,-soname=$(rtld-installed-name) -T $#.lds
rm -f $#.lds
readelf -s $# \
| awk '($$7 ~ /^UND(|EF)$$/ && $$1 != "0:" && $$4 != "REGISTER") { print; p=1 } END { exit p != 0 }'
This is how I configure glibc:
/public/home/geosign/software/glibc/configure --prefix=/public/home/geosign/glibc --with-binutils=/public/home/geosign/binutils/ --enable-shared --disable-multilib
ldd ld shows:
[geosign#node117 ~/binutils/bin]$ ldd ld
linux-vdso.so.1 => (0x00007fff163be000)
libz.so.1 => /lib64/libz.so.1 (0x0000003fd1400000)
libc.so.6 => /lib64/libc.so.6 (0x0000003fd0400000)
/lib64/ld-linux-x86-64.so.2 (0x0000003fd0000000)
Thank you very much. There is really limited time for me, and I have spent a lot of days on it.
Your immediate problem is this:
gcc -nostdlib -nostartfiles -shared -o -mcmodel=large \
/public/home/geosign/software/glibc-2.7/w/elf/ld.so ...
This tells GCC to create an output file named -mcmodel=large, instead of intended output file /public/home/geosign/software/glibc-2.7/w/elf/ld.so.
You didn't tell us how you've configured this GLIBC build, but I suspect you've used -mcmodel=large somewhere in ./configure invocation. Don't do that, there is no reason to use -mcmodel=large when building glibc.

gcc-arm linking error: attempted static link of dynamic object

I am trying to compile a program with arm-linux-gnueabi-gcc containing neon instructions and executing it over Qemu. The code is,
#include <arm_neon.h>
void NeonTest(short int * __restrict a, short int * __restrict b, short int * __restrict z)
{
int i;
for (i = 0; i < 200; i++) {
z[i] = a[i] * b[i];
}
}
I successfully do it without using -static flag. But Qemu does not execute/recognize an executable if -static flag is not used. So when I use -static to compile and link, I get the following error,
junaid#junaid755:~/code/c$ arm-linux-gnueabi-gcc -static -march=armv7-a -mtune=cortex-a9 -ftree-vectorize -mhard-float -mfloat-abi=softfp -mfpu=neon -ffast-math -mvectorize-with-neon-quad -S neon_test.c
junaid#junaid755:~/code/c$ arm-linux-gnueabi-gcc -static -march=armv7-a -mtune=cortex-a9 -ftree-vectorize -mhard-float -mfloat-abi=softfp -mfpu=neon -ffast-math -mvectorize-with-neon-quad -c neon_test.s -o neon_test.o
junaid#junaid755:~/code/c$ arm-linux-gnueabi-gcc -static -march=armv7-a -mtune=cortex-a9 -ftree-vectorize -mhard-float -mfloat-abi=softfp -mfpu=neon -ffast-math -mvectorize-with-neon-quad neon_test.o -o neon_test
/usr/lib/gcc-cross/arm-linux-gnueabi/4.7/../../../../arm-linux-gnueabi/bin/ld: attempted static link of dynamic object `/lib/ld-linux.so.3'
collect2: error: ld returned 1 exit status
I have tried the ermine, statifier and other softwares for portable linux applications. But the issue is they work on executables, while in my case the executable generation is causing error.
The problem is solved when i installed arm-linux-gnueabihf-gcc on my system. Maybe additional packages installed may have resloved the problem. Now I use arm-linux-gnueabihf-gcc command instead of arm-linux-gnueabi-gcc. Now the exe file is statically linked. But the problem is not totally solved. On qemu it give segmentation fault now.

Resources