I'm trying to cross compile busy box V 1.27.2 for my embedded Linux device. I set share library build and cross compiler prefix and Sysroot to my compiler destinations. Compiler after trying to compile most library files is unable to link them.I received this:
Trying libraries: crypt m
Failed: -Wl,--start-group -lcrypt -lm -Wl,--end-group
Output of:
/home/bluebird/brcm-armtools-64bit/tools/le_arm11_external_20090306/bin/arm-brcm-linux-gnueabi-gcc -Wall -Wshadow -Wwrite-strings -Wundef -Wstrict-prototypes -Wunused -Wunused-parameter -Wunused-function -Wunused-value -Wmissing-prototypes -Wmissing-declarations -Wno-format-security -Wdeclaration-after-statement -Wold-style-definition -fno-builtin-strlen -finline-limit=0 -fomit-frame-pointer -ffunction-sections -fdata-sections -fno-guess-branch-probability -funsigned-char -static-libgcc -falign-functions=1 -falign-jumps=1 -falign-labels=1 -falign-loops=1 -fno-unwind-tables -fno-asynchronous-unwind-tables -fno-builtin-printf -Os -fpic -fvisibility=hidden --sysroot=/home/bluebird/brcm-armtools-64bit/tools/le_arm11_external_20090306/sysroot -o busybox_unstripped -Wl,--sort-common -Wl,--sort-section,alignment -Wl,--gc-sections -Wl,--start-group applets/built-in.o archival/lib.a archival/libarchive/lib.a console-tools/lib.a coreutils/lib.a coreutils/libcoreutils/lib.a debianutils/lib.a e2fsprogs/lib.a editors/lib.a findutils/lib.a init/lib.a libbb/lib.a libpwdgrp/lib.a loginutils/lib.a mailutils/lib.a miscutils/lib.a modutils/lib.a networking/lib.a networking/libiproute/lib.a networking/udhcp/lib.a printutils/lib.a procps/lib.a runit/lib.a selinux/lib.a shell/lib.a sysklogd/lib.a util-linux/lib.a util-linux/volume_id/lib.a archival/built-in.o archival/libarchive/built-in.o console-tools/built-in.o coreutils/built-in.o coreutils/libcoreutils/built-in.o debianutils/built-in.o e2fsprogs/built-in.o editors/built-in.o findutils/built-in.o init/built-in.o libbb/built-in.o libpwdgrp/built-in.o loginutils/built-in.o mailutils/built-in.o miscutils/built-in.o modutils/built-in.o networking/built-in.o networking/libiproute/built-in.o networking/udhcp/built-in.o printutils/built-in.o procps/built-in.o runit/built-in.o selinux/built-in.o shell/built-in.o sysklogd/built-in.o util-linux/built-in.o util-linux/volume_id/built-in.o -Wl,--end-group -Wl,--start-group -lcrypt -lm -Wl,--end-group
==========
coreutils/lib.a(mktemp.o): In function `mktemp_main':
mktemp.c:(.text.mktemp_main+0xbc): warning: the use of `mktemp' is dangerous, better use `mkstemp'
coreutils/lib.a(touch.o): In function `touch_main':
touch.c:(.text.touch_main+0x1f4): warning: warning: lutimes is not implemented and will always fail
util-linux/lib.a(nsenter.o): In function `nsenter_main':
nsenter.c:(.text.nsenter_main+0x1b4): undefined reference to `setns'
coreutils/lib.a(sync.o): In function `sync_main':
sync.c:(.text.sync_main+0x9c): undefined reference to `syncfs'
collect2: ld returned 1 exit status
Note: if build needs additional libraries, put them in CONFIG_EXTRA_LDLIBS.
Example: CONFIG_EXTRA_LDLIBS="pthread dl tirpc audit pam"
make: *** [busybox_unstripped] Error 1
Also I have libm.so in my sysroot dir.
EDIT:
I also try buildroot,but it needs some information about processor(e.g. endian, detailed version,etc.) which I am not aware,this is a black box device and I only develope app on it, total information I have is it run on the BCM5892 ,an ARM11 secure processor from broadcom.it runs on kenel V 2.6 and arm-brcm-linux-gnueabi V4.4.2 compiler, I also correctly set sysroot and cross compiler prefix,but how could I know which version of libc I'm using ?
Open busybox menuconfig and disable "Enable -d and -f flags"
[*] sync (3.8 kb)
[ ] Enable -d and -f flags (requires syncfs(2) in libc)
Uning a more recent verisons of uclibc (> 0.9.33) can allow to enable the option.
You can detect your glibc Version by inspecting the names of this link targets:
root#debianxc:/usr/src/busybox# file /opt/STM/STLinux-2.4/devkit/sh4/target/lib/libc.so.6
/opt/STM/STLinux-2.4/devkit/sh4/target/lib/libc.so.6: symbolic link to libc-2.10.2.so
root#debianxc:/usr/src/busybox# file /opt/STM/STLinux-2.4/devkit/sh4/target/lib/ld-linux.so.2
/opt/STM/STLinux-2.4/devkit/sh4/target/lib/ld-linux.so.2: symbolic link to ld-2.10.2.so
This indicates a glibc Version of 2.10.2.
But to get sure you can also do:
root#debianxc:/usr/src/busybox# strings /opt/STM/STLinux-2.4/devkit/sh4/target/lib/libc.so.6 | grep '^GLIBC_' | sort | uniq
GLIBC_2.10
GLIBC_2.2
GLIBC_2.2.1
GLIBC_2.2.2
GLIBC_2.2.3
GLIBC_2.2.4
GLIBC_2.2.6
GLIBC_2.3
GLIBC_2.3.2
GLIBC_2.3.3
GLIBC_2.3.4
GLIBC_2.4
GLIBC_2.5
GLIBC_2.6
GLIBC_2.7
GLIBC_2.8
GLIBC_2.9
GLIBC_PRIVATE
root#debianxc:/usr/src/busybox# strings /opt/STM/STLinux-2.4/devkit/sh4/target/lib/ld-linux.so.2 | grep '^GLIBC_' | sort | uniq
GLIBC_2.2
GLIBC_2.3
GLIBC_2.4
GLIBC_PRIVATE
As I experienced a similar issue when compiling busybox-1.30.1 for SH4 Kernel 2.6.32.59, I had had to prevent nsenter.c and sync.c from becoming compiled by the Makefile.
So in your case, you could try to change your .config file.
root#debianxc:/usr/src/busybox# diff -d .config_from_defconfig .config
4c4
< # Wed Apr 3 20:04:24 2019
---
> # Wed Apr 3 20:09:45 2019
273c273
< CONFIG_MKTEMP=y
---
> # CONFIG_MKTEMP is not set
304,305c304,305
< CONFIG_SYNC=y
< CONFIG_FEATURE_SYNC_FANCY=y
---
> # CONFIG_SYNC is not set
> # CONFIG_FEATURE_SYNC_FANCY is not set
316,318c316,318
< CONFIG_TOUCH=y
< CONFIG_FEATURE_TOUCH_NODEREF=y
< CONFIG_FEATURE_TOUCH_SUSV3=y
---
> # CONFIG_TOUCH is not set
> # CONFIG_FEATURE_TOUCH_NODEREF is not set
> # CONFIG_FEATURE_TOUCH_SUSV3 is not set
667c667
< CONFIG_NSENTER=y
---
> # CONFIG_NSENTER is not set
These are the steps you could follow:
#Backup your .config
cp .config .config.backup
#Create a new config with this sed command. You will see its effect by the follow-up diff command below...
sed -e '/^\(CONFIG_\)\(\(MKTEMP\)\|\(TOUCH\)\|\(NSENTER\)\|\(SYNC\)\)=.*$/s/^\([^=]*\)=.*$/# \1 is not set/' .config >.newconfig
#With this diff output you will see its effect
diff -d .config .newconfig
#Overwrite current .config with .newconfig
cp .newconfig .config
#Now run make oldconfig, because some disablings need auto-disablings of other depending configs, too...
make oldconfig
#See the effect ...
diff -d .config.old .config
#make clean before re-compiling
make clean
#make busybox with cross-compiler
make CROSS_COMPILE=sh4-linux-
#Your new busybox is located in your working direktory
#Optionally invoke make install to create dir tree with symlinks
make CROSS_COMPILE=sh4-linux- install
#Tree's name is _install
Hope this helps.
Related
I generated a project by the STMCubeMX and wanted to import this project into Clion.
Here's the CmakeList.txt:
project(ClionTest)
cmake_minimum_required(VERSION 3.8)
add_definitions(-DSTM32F4xx)
file(GLOB_RECURSE USER_SOURCES "Src/*.c")
file(GLOB_RECURSE HAL_SOURCES "Drivers/STM32F4xx_HAL_Driver/Src/*.c")
add_library(CMSIS
startup/startup_stm32f407xx.s)
include_directories(Drivers/CMSIS/Device)
include_directories(Drivers/CMSIS/Device/ST/STM32F4xx/Include)
include_directories(Drivers/CMSIS/Include)
include_directories(Drivers/STM32F4xx_HAL_Driver)
include_directories(Drivers/STM32F4xx_HAL_Driver/Inc)
include_directories(Inc)
include_directories(Middlewares/Third_Party/LwIP/src/include)
add_executable(${PROJECT_NAME}.elf ${USER_SOURCES} ${HAL_SOURCES} ${LINKER_SCRIPT})
target_link_libraries(${PROJECT_NAME}.elf CMSIS)
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -Wl,-Map=${PROJECT_SOURCE_DIR}/build/${PROJECT_NAME}.map")
set(HEX_FILE ${PROJECT_SOURCE_DIR}/build/${PROJECT_NAME}.hex)
set(BIN_FILE ${PROJECT_SOURCE_DIR}/build/${PROJECT_NAME}.bin)
add_custom_command(TARGET ${PROJECT_NAME}.elf POST_BUILD
COMMAND ${CMAKE_OBJCOPY} -Oihex $<TARGET_FILE:${PROJECT_NAME}.elf> ${HEX_FILE}
COMMAND ${CMAKE_OBJCOPY} -Obinary $<TARGET_FILE:${PROJECT_NAME}.elf> ${BIN_FILE}
COMMENT "Building ${HEX_FILE} \nBuilding ${BIN_FILE}")
And a STM32F4xx.cmake file:
INCLUDE(CMakeForceCompiler)
SET(CMAKE_SYSTEM_NAME Generic)
SET(CMAKE_SYSTEM_VERSION 1)
# specify the cross compiler
#CMAKE_FORCE_C_COMPILER(C:/Program Files (x86)/GNU Tools ARM Embedded/6 2017-q2-update/bin/arm-none-eabi-gcc.exe GNU)
#CMAKE_FORCE_CXX_COMPILER(D:/Lib/arm/bin/arm-none-eabi-g++.exe GNU)
SET(CMAKE_C_COMPILER "C:/Program Files (x86)/GNU Tools ARM Embedded/6 2017-q2-update/bin/arm-none-eabi-gcc.exe")
SET(CMAKE_CXX_COMPILER "C:/Program Files (x86)/GNU Tools ARM Embedded/6 2017-q2-update/bin/arm-none-eabi-g++.exe")
SET(LINKER_SCRIPT ${PROJECT_SOURCE_DIR}/STM32F407VETx_FLASH.ld)
#Uncomment for software floating point
#SET(COMMON_FLAGS "-mcpu=cortex-m4 -mthumb -mthumb-interwork -mfloat-abi=soft -ffunction-sections -fdata-sections -g -fno-common -fmessage-length=0")
SET(COMMON_FLAGS "-mcpu=cortex-m4 -mthumb -mthumb-interwork -mfloat-abi=hard -mfpu=fpv4-sp-d16 -ffunction-sections -fdata-sections -g -fno-common -fmessage-length=0")
SET(CMAKE_CXX_FLAGS_INIT "${COMMON_FLAGS} -std=c++11")
SET(CMAKE_C_FLAGS_INIT "${COMMON_FLAGS} -std=gnu99")
SET(CMAKE_EXE_LINKER_FLAGS_INIT "-Wl,-gc-sections,-M=binary.map -T ${LINKER_SCRIPT}")
I set LINKER_SCRIPT ${PROJECT_SOURCE_DIR}/STM32F407VETx_FLASH.ld
File structure
And the Cmake options is:
Cmake options
When I reload this project, it's not go on well.
c:/progra~2/gnutoo~1/62017-~1/bin/../lib/gcc/arm-none-eabi/6.3.1/../../../../arm-none-eabi/bin/ld.exe: cannot open linker script file
D:/Project/ClionTest/cmake-build-default/CMakeFiles/CMakeTmp/STM32F407VETx_FLASH.ld:
Invalid argument
collect2.exe: error: ld returned 1 exit status
CMakeFiles\cmTC_bf7b4.dir\build.make:96: recipe for target 'cmTC_bf7b4' failed
mingw32-make.exe[1]: *** [cmTC_bf7b4] Error 1
mingw32-make.exe[1]: Leaving directory
'D:/Project/ClionTest/cmake-build-default/CMakeFiles/CMakeTmp'
Makefile:125: recipe for target 'cmTC_bf7b4/fast' failed
mingw32-make.exe: *** [cmTC_bf7b4/fast] Error 2
It seems like the path of ld.exe is not correct,how shoulld I set its path?
And why the path of STM32F407VETx_FLASH.ld it searched is not the path I set?
I'm using Linux, but I've had the a similar issue in regards to being unable to open the linker script.
cannot open linker script file D:/Project/ClionTest/cmake-build-default/CMakeFiles/CMakeTmp/STM32F407VETx_FLASH.ld
After looking for a while at the documentation for target_link_option (which does approximately the same kind of thing as setting a variable directly), I took note of the SHELL: directive, that's stated to:
The set of options is de-duplicated to avoid repetition. While beneficial for individual options, the de-duplication step can break up option groups. For example, -D A -D B becomes -D A B. One may specify a group of options using shell-like quoting along with a SHELL: prefix. The SHELL: prefix is dropped and the rest of the option string is parsed using the separate_arguments() UNIX_COMMAND mode.
By adding it to my command, I managed to get compilation working normally. The result was the following:
set(LINKER_SCRIPT "${CMAKE_SOURCE_DIR}/STM32F303CCTX_FLASH.ld")
set(LINKER_FLAGS "SHELL:-T${LINKER_SCRIPT} -Wl,--gc-sections --specs=nano.specs --specs=nosys.specs")
target_link_options(${PROJECT_BINARY} PRIVATE ${LINKER_FLAGS})
Change this:
SET(CMAKE_EXE_LINKER_FLAGS_INIT "-Wl,-gc-sections,-M=binary.map -T ${LINKER_SCRIPT}")
To:
SET(CMAKE_EXE_LINKER_FLAGS "-Wl,-gc-sections,-M=binary.map -T${LINKER_SCRIPT}")
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.
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.
I'm trying to cross compile OpenSSL for PowerPC with the FIPS module. My build host's architecture is not PowerPC. I was able to cross compile the FIPS module just fine. However, when I run make on openssl, during the linking phase, it tries to execute certain binaries to run tests. The issue is that those binaries are produced for the target architecture and, as a result, I get the error "cannot execute binary file". Is there a way to produce executables of these tests on the host architecture rather than the target architecture? Should I be handling this process differently? Here are the following commands I used to build openssl. I replaced certain directories with DIR_HIDDEN.
export FIPS_DIRECTORY="$PWD/../../openssl-fips/tgt/linux-ppc603e/"
export cross="DIR_HIDDEN/powerpc-linux-gnu-"
make clean || exit 1
make dclean || exit 1
./Configure --prefix=$PWD/../tgt/linux-ppc603e linux-ppc fips --with-fipsdir=${FIPS_DIRECTORY}
make depend || exit 1
make CC="$FIPS_DIRECTORY/bin/fipsld" RANLIB="${cross}ranlib" AR="${cross}ar r" LD="$FIPS_DIRECTORY/bin/fipsld" FIPSLD_CC="${cross}gcc" HOSTCC="/usr/bin/gcc" || exit 1
make install || exit 1
I get the following error during the make command:
shlib_target=; if [ -n "" ]; then \
shlib_target="linux-shared"; \
elif [ -n "libcrypto" ]; then \
FIPSLD_CC="/DIR_HIDDEN/openssl/openssl-1.0.1i/../../openssl-fips/tgt/linux-ppc603e//bin/fipsld"; CC=/DIR_HIDDEN/openssl/openssl-1.0.1i/../../openssl-fips/tgt/linux-ppc603e//bin/fipsld; export CC FIPSLD_CC; \
fi; \
LIBRARIES="-L.. -lssl -L.. -lcrypto" ; \
make -f ../Makefile.shared -e \
APPNAME=openssl OBJECTS="openssl.o verify.o asn1pars.o req.o dgst.o dh.o dhparam.o enc.o passwd.o gendh.o errstr.o ca.o pkcs7.o crl2p7.o crl.o rsa.o rsautl.o dsa.o dsaparam.o ec.o ecparam.o x509.o genrsa.o gendsa.o genpkey.o s_server.o s_client.o speed.o s_time.o apps.o s_cb.o s_socket.o app_rand.o version.o sess_id.o ciphers.o nseq.o pkcs12.o pkcs8.o pkey.o pkeyparam.o pkeyutl.o spkac.o smime.o cms.o rand.o engine.o ocsp.o prime.o ts.o srp.o" \
LIBDEPS=" $LIBRARIES -ldl" \
link_app.${shlib_target}
make[2]: Entering directory `/DIR_HIDDEN/openssl/openssl-1.0.1i/apps'
( :; LIBDEPS="${LIBDEPS:--L.. -lssl -L.. -lcrypto -ldl}"; LDCMD="${LDCMD:-/DIR_HIDDEN/openssl/openssl-1.0.1i/../../openssl-fips/tgt/linux-ppc603e//bin/fipsld}"; LDFLAGS="${LDFLAGS:--DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DB_ENDIAN -DTERMIO -O3 -Wall -DOPENSSL_BN_ASM_MONT -I/DIR_HIDDEN/openssl/openssl-1.0.1i/../../openssl-fips/tgt/linux-ppc603e//include -DSHA1_ASM -DSHA256_ASM -DAES_ASM}"; LIBPATH=`for x in $LIBDEPS; do echo $x; done | sed -e 's/^ *-L//;t' -e d | uniq`; LIBPATH=`echo $LIBPATH | sed -e 's/ /:/g'`; LD_LIBRARY_PATH=$LIBPATH:$LD_LIBRARY_PATH ${LDCMD} ${LDFLAGS} -o ${APPNAME:=openssl} openssl.o verify.o asn1pars.o req.o dgst.o dh.o dhparam.o enc.o passwd.o gendh.o errstr.o ca.o pkcs7.o crl2p7.o crl.o rsa.o rsautl.o dsa.o dsaparam.o ec.o ecparam.o x509.o genrsa.o gendsa.o genpkey.o s_server.o s_client.o speed.o s_time.o apps.o s_cb.o s_socket.o app_rand.o version.o sess_id.o ciphers.o nseq.o pkcs12.o pkcs8.o pkey.o pkeyparam.o pkeyutl.o spkac.o smime.o cms.o rand.o engine.o ocsp.o prime.o ts.o srp.o ${LIBDEPS} )
/DIR_HIDDEN/openssl/openssl-1.0.1i/../../openssl-fips/tgt/linux-ppc603e//bin/fipsld: line 185: ./openssl: cannot execute binary file
make[2]: *** [link_app.] Error 126
When invoking the make command again and again, I get the same error but for all the applications located in the /test directory of the openssl tarball. Examples include bntest, ectest, and ecdhtest.
I received a similar error when I was cross compiling the FIPS module, but I was able to resolve that by including the host compiler in the HOSTCC variable. A similar trick did not work for the openssl compilation.
Any guidance would be appreciated. Thanks!
I was able to modify the make command to get the process to complete. I was missing the FIPS_SIG environment variable, which points to the incore script. The make command is now:
make FIPS_SIG=$PWD/`find ../../openssl-fips/ -iname incore` CC="$FIPS_DIRECTORY/bin/fipsld" RANLIB="${cross}ranlib" AR="${cross}ar r" LD="$FIPS_DIRECTORY/bin/fipsld" FIPSLD_CC="${cross}gcc"
I still see prints to console that indicate that openssl cannot be executed, but these are warnings and don't halt the makefile. Not really sure why or how this fixed the problem, but I'll take it.
What's the best way to tell CMake to use the LLVM linker llvm-link instead of GNU ld as linker? When configuring a project with
CXX=clang++ cmake <args>
the default linker appears to be untouched, remaining usr/bin/ld (on Linux).
Is this possible without using a separate toolchain file?
This turns out to be unrelated to CMake: clang++ uses the system linker by default. For example,
echo "#include <atomic>\n int main() { return 0; }" \
| clang++ -x c++ -std=c++11 -stdlib=libc++ -
uses /usr/bin/ld to link the application. To change the linker to llvm-link, one needs to first emit LLVM byte code, and then call the linker, e.g.:
echo "#include <atomic>\n int main() { return 0; }" \
| clang++ -x c++ -std=c++11 -stdlib=libc++ -S -emit-llvm -o - - \
| llvm-link -o binary -
This bypasses /usr/bin/ld.
As of 3.4, clang looks for the linker (ld) at GCCInstallation.getParentLibPath() + "/../" + GCCInstallation.getTriple().str() + "/bin" before it looks for ld on the path. You should be able to put your linker in /usr/lib/gcc/<arch><sub>-<vendor>-<sys>-<abi>/<version>/ld and have it called by clang in 1 step. To specify this location manually, use the undocumented -B flag. Unfortunately, I don't believe there is a way to alter the name of the linker that is searched for so using ld.gold or lld is going to require a symlink at the aforementioned location.