for a research project I need to incorporate different crypto functions (PRNG, SHA1, symmetric encryption/decryption) into the MLO part of u-boot.
My questions:
1.) Has someone achieved this before?
2.) Do you guys know it this is even possible regarding the limited size of the MLO and the size of libtomcrypt?
3.) Does someone know an elegant way of resolving missing *.h file-errors besides the straight forward way of copying them fomr /usr/include/ to {u-boot-src}/include/ ?
Thanks a lot.
make output:
arch/arm/cpu/armv7/omap-common/libomap-common.o: In function selectSecretBytes':
/home/andre/tmp/working/chipsee/u-boot-ics-chipsee-panda-0524/arch/arm/cpu/armv7/omap-common/hwinit-common.c:777: undefined reference toregister_prng'
/home/andre/tmp/working/chipsee/u-boot-ics-chipsee-panda-0524/arch/arm/cpu/armv7/omap-common/hwinit-common.c:778: undefined reference to find_prng'
/home/andre/tmp/working/chipsee/u-boot-ics-chipsee-panda-0524/arch/arm/cpu/armv7/omap-common/hwinit-common.c:778: undefined reference torng_make_prng'
/home/andre/tmp/working/chipsee/u-boot-ics-chipsee-panda-0524/arch/arm/cpu/armv7/omap-common/hwinit-common.c:779: undefined reference to error_to_string'
/home/andre/tmp/working/chipsee/u-boot-ics-chipsee-panda-0524/arch/arm/cpu/armv7/omap-common/hwinit-common.c:783: undefined reference tofortuna_start'
/home/andre/tmp/working/chipsee/u-boot-ics-chipsee-panda-0524/arch/arm/cpu/armv7/omap-common/hwinit-common.c:784: undefined reference to error_to_string'
/home/andre/tmp/working/chipsee/u-boot-ics-chipsee-panda-0524/arch/arm/cpu/armv7/omap-common/hwinit-common.c:788: undefined reference tofortuna_add_entropy'
/home/andre/tmp/working/chipsee/u-boot-ics-chipsee-panda-0524/arch/arm/cpu/armv7/omap-common/hwinit-common.c:789: undefined reference to error_to_string'
/home/andre/tmp/working/chipsee/u-boot-ics-chipsee-panda-0524/arch/arm/cpu/armv7/omap-common/hwinit-common.c:793: undefined reference tofortuna_ready'
/home/andre/tmp/working/chipsee/u-boot-ics-chipsee-panda-0524/arch/arm/cpu/armv7/omap-common/hwinit-common.c:794: undefined reference to error_to_string'
/home/andre/tmp/working/chipsee/u-boot-ics-chipsee-panda-0524/arch/arm/cpu/armv7/omap-common/hwinit-common.c:797: undefined reference tofortuna_read'
/home/andre/tmp/working/chipsee/u-boot-ics-chipsee-panda-0524/arch/arm/cpu/armv7/omap-common/hwinit-common.c:805: undefined reference to fortuna_done'
/home/andre/tmp/working/chipsee/u-boot-ics-chipsee-panda-0524/arch/arm/cpu/armv7/omap-common/hwinit-common.c:806: undefined reference toerror_to_string'
/home/andre/tmp/working/chipsee/u-boot-ics-chipsee-panda-0524/arch/arm/cpu/armv7/omap-common/hwinit-common.c:816: undefined reference to fortuna_desc'
arch/arm/cpu/armv7/omap-common/libomap-common.o: In functioncreateKey':
/home/andre/tmp/working/chipsee/u-boot-ics-chipsee-panda-0524/arch/arm/cpu/armv7/omap-common/hwinit-common.c:1088: undefined reference to register_hash'
/home/andre/tmp/working/chipsee/u-boot-ics-chipsee-panda-0524/arch/arm/cpu/armv7/omap-common/hwinit-common.c:1094: undefined reference tofind_hash'
/home/andre/tmp/working/chipsee/u-boot-ics-chipsee-panda-0524/arch/arm/cpu/armv7/omap-common/hwinit-common.c:1104: undefined reference to sha1_process'
/home/andre/tmp/working/chipsee/u-boot-ics-chipsee-panda-0524/arch/arm/cpu/armv7/omap-common/hwinit-common.c:1114: undefined reference tosha1_desc'
/home/andre/tmp/working/chipsee/u-boot-ics-chipsee-panda-0524/arch/arm/cpu/armv7/omap-common/hwinit-common.c:1114: undefined reference to `hash_descriptor'
arm-none-linux-gnueabi-ld: BFD (Sourcery G++ Lite 2011.03-41) 2.20.51.20100809 assertion fail /scratch/janisjo/arm-linux-lite/obj/binutils-src-2011.03-41-arm-none-linux-gnueabi-i686-pc-linux-gnu/bfd/elf32-arm.c:13036
arm-none-linux-gnueabi-ld: BFD (Sourcery G++ Lite 2011.03-41) 2.20.51.20100809 assertion fail /scratch/janisjo/arm-linux-lite/obj/binutils-src-2011.03-41-arm-none-linux-gnueabi-i686-pc-linux-gnu/bfd/elf32-arm.c:13036
arm-none-linux-gnueabi-ld: BFD (Sourcery G++ Lite 2011.03-41) 2.20.51.20100809 assertion fail /scratch/janisjo/arm-linux-lite/obj/binutils-src-2011.03-41-arm-none-linux-gnueabi-i686-pc-linux-gnu/bfd/elf32-arm.c:13036
arm-none-linux-gnueabi-ld: BFD (Sourcery G++ Lite 2011.03-41) 2.20.51.20100809 assertion fail /scratch/janisjo/arm-linux-lite/obj/binutils-src-2011.03-41-arm-none-linux-gnueabi-i686-pc-linux-gnu/bfd/elf32-arm.c:13036
arm-none-linux-gnueabi-ld: BFD (Sourcery G++ Lite 2011.03-41) 2.20.51.20100809 assertion fail /scratch/janisjo/arm-linux-lite/obj/binutils-src-2011.03-41-arm-none-linux-gnueabi-i686-pc-linux-gnu/bfd/elf32-arm.c:13036
arm-none-linux-gnueabi-ld: BFD (Sourcery G++ Lite 2011.03-41) 2.20.51.20100809 assertion fail /scratch/janisjo/arm-linux-lite/obj/binutils-src-2011.03-41-arm-none-linux-gnueabi-i686-pc-linux-gnu/bfd/elf32-arm.c:13036
arm-none-linux-gnueabi-ld: BFD (Sourcery G++ Lite 2011.03-41) 2.20.51.20100809 assertion fail /scratch/janisjo/arm-linux-lite/obj/binutils-src-2011.03-41-arm-none-linux-gnueabi-i686-pc-linux-gnu/bfd/elf32-arm.c:13036
arm-none-linux-gnueabi-ld: BFD (Sourcery G++ Lite 2011.03-41) 2.20.51.20100809 assertion fail /scratch/janisjo/arm-linux-lite/obj/binutils-src-2011.03-41-arm-none-linux-gnueabi-i686-pc-linux-gnu/bfd/elf32-arm.c:13036
arm-none-linux-gnueabi-ld: BFD (Sourcery G++ Lite 2011.03-41) 2.20.51.20100809 assertion fail /scratch/janisjo/arm-linux-lite/obj/binutils-src-2011.03-41-arm-none-linux-gnueabi-i686-pc-linux-gnu/bfd/elf32-arm.c:13036
arm-none-linux-gnueabi-ld: BFD (Sourcery G++ Lite 2011.03-41) 2.20.51.20100809 assertion fail /scratch/janisjo/arm-linux-lite/obj/binutils-src-2011.03-41-arm-none-linux-gnueabi-i686-pc-linux-gnu/bfd/elf32-arm.c:13036
arm-none-linux-gnueabi-ld: BFD (Sourcery G++ Lite 2011.03-41) 2.20.51.20100809 assertion fail /scratch/janisjo/arm-linux-lite/obj/binutils-src-2011.03-41-arm-none-linux-gnueabi-i686-pc-linux-gnu/bfd/elf32-arm.c:13036
arm-none-linux-gnueabi-ld: BFD (Sourcery G++ Lite 2011.03-41) 2.20.51.20100809 assertion fail /scratch/janisjo/arm-linux-lite/obj/binutils-src-2011.03-41-arm-none-linux-gnueabi-i686-pc-linux-gnu/bfd/elf32-arm.c:13036
arm-none-linux-gnueabi-ld: BFD (Sourcery G++ Lite 2011.03-41) 2.20.51.20100809 assertion fail /scratch/janisjo/arm-linux-lite/obj/binutils-src-2011.03-41-arm-none-linux-gnueabi-i686-pc-linux-gnu/bfd/elf32-arm.c:13291
/bin/sh: Zeile 1: 20550 Speicherzugriffsfehler (Speicherabzug geschrieben) arm-none-linux-gnueabi-ld -pie -T u-boot.lds -Bstatic -Ttext 0x80E80000 $UNDEF_SYM arch/arm/cpu/armv7/start.o --start-group api/libapi.o arch/arm/cpu/armv7/libarmv7.o arch/arm/cpu/armv7/omap-common/libomap-common.o arch/arm/cpu/armv7/omap4/libomap4.o arch/arm/lib/libarm.o common/libcommon.o disk/libdisk.o drivers/bios_emulator/libatibiosemu.o drivers/block/libblock.o drivers/dma/libdma.o drivers/fpga/libfpga.o drivers/gpio/libgpio.o drivers/hwmon/libhwmon.o drivers/i2c/libi2c.o drivers/input/libinput.o drivers/misc/libmisc.o drivers/mmc/libmmc.o drivers/mtd/libmtd.o drivers/mtd/nand/libnand.o drivers/mtd/onenand/libonenand.o drivers/mtd/spi/libspi_flash.o drivers/mtd/ubi/libubi.o drivers/net/libnet.o drivers/net/phy/libphy.o drivers/pci/libpci.o drivers/pcmcia/libpcmcia.o drivers/power/libpower.o drivers/rtc/librtc.o drivers/serial/libserial.o drivers/spi/libspi.o drivers/twserial/libtws.o drivers/usb/eth/libusb_eth.o drivers/usb/gadget/libusb_gadget.o drivers/usb/host/libusb_host.o drivers/usb/musb/libusb_musb.o drivers/usb/phy/libusb_phy.o drivers/usb/ulpi/libusb_ulpi.o drivers/video/libvideo.o drivers/watchdog/libwatchdog.o fs/cramfs/libcramfs.o fs/ext2/libext2fs.o fs/fat/libfat.o fs/fdos/libfdos.o fs/jffs2/libjffs2.o fs/reiserfs/libreiserfs.o fs/ubifs/libubifs.o fs/yaffs2/libyaffs2.o lib/libfdt/libfdt.o lib/libgeneric.o lib/lzma/liblzma.o lib/lzo/liblzo.o lib/zlib/libz.o net/libnet.o post/libpost.o board/ti/panda/libpanda.o --end-group /home/andre/tmp/working/chipsee/u-boot-ics-chipsee-panda-0524/arch/arm/lib/eabi_compat.o -L /opt/CodeSourcery/Sourcery_G++_Lite/bin/../lib/gcc/arm-none-linux-gnueabi/4.5.2/armv4t -lgcc -Map u-boot.map -o u-boot
make[1]: * [u-boot] Fehler 139
make[1]: Verlasse Verzeichnis '/home/andre/tmp/working/chipsee/u-boot-ics-chipsee-panda-0524'
make: * [omap4_panda] Fehler 2
1.) Has someone achieved this before?
I have not.
2.) Do you guys know it this is even possible regarding the limited size of the MLO and the size of libtomcrypt?
libtomcrypt appears to be pretty much abandoned. There are probably better choices. Caveat emptor.
3.) Does someone know an elegant way of resolving missing *.h file-errors besides the straight forward way of copying them fomr /usr/include/ to {u-boot-src}/include/ ?
Use --sysroot to pass the root directory or SYSROOT of the arm headers and libraries. Under SYSROOT, there should be a include/ and lib, and the compiler and linker will find required headers and libraries.
Or, pass the header path using -I and library path using -L.
Related
I am building an executable ("tool") on Linux. Using include $(GNUSTEP_MAKEFILES)/tool.make.
It's linked to a static lib that has also be build with GNUstep. The lib
contains Categories.
The executable builds fine but has errors at runtime not recognizing
methods defined in the static lib's Category:
Uncaught exception NSInvalidArgumentException, reason:
ClassNameOfClassTheCategoryExtends(instance) does not recognize
nameOfMethodInCategory
I am trying to fix that by passing -ObjC to the linker flags (also
tried -all_load) in the executable's GNUmakefile:
ADDITIONAL_LDFLAGS = -ObjC -all_load
But that seems to be ignored by clang. Here is the relevant output of
make install messages=yes debug=yes
clang: warning: argument unused during compilation: '-ObjC'
[-Wunused-command-line-argument]
clang: warning: argument unused during compilation: '-all_load'
[-Wunused-command-line-argument]
It looks like ADDITIONAL_LDFLAGS are used compiling, not linking.
Using this leads to the same result:
LDFLAGS := $(LDFLAGS) -ObjC
The excecutables GNUmakefileincludes the following:
include $(GNUSTEP_MAKEFILES)/common.make
# My make
include $(GNUSTEP_MAKEFILES)/tool.make
The resulting command line output is:
$ make install messages=yes debug=yes
This is gnustep-make 2.9.0. Type 'gmake print-gnustep-make-help' for help.
Running in gnustep-make version 2 strict mode.
Making all for tool NameOfExcecutable...
clang -ObjC -fuse-ld=/usr/bin/ld.gold -pthread -fexceptions -rdynamic -fobjc-runtime=gnustep-2.0 -fblocks -o obj/NameOfExcecutable \
./obj/NameOfExcecutable.obj/main.m.o ./obj/NameOfExcecutable.obj/MyClass.m.o ./obj/NameOfExcecutable.obj/StreamRunLoop.m.o ./obj/NameOfExcecutable.obj/Connector.m.o ./obj/NameOfExcecutable.obj/HTTPClient.m.o \
-L/home/user/GNUstep/Library/Libraries -L/usr/GNUstep/Local/Library/Libraries -L/usr/GNUstep/System/Library/Libraries -lgnustep-base -ldispatch -l/path/to/libOwnLib1.a -l/path/to/libOwnLib2.a -l/path/to/libOwnHavingTheCategories.a -l/path/to/libOwnLib4.a -l/path/to/libOwnLib5.a -luuid -lz -lpthread -ldl -lpthread -lobjc -lm
clang: warning: argument unused during compilation: '-ObjC' [-Wunused-command-line-argument]
Question:
What am I doing wrong
or
How can I work around the issue?
After digging into the issue of the linker not knowing the -ObjC flag (which we are used to use in Xcode) it looks like:
only ld.ld64 is aware of this flag
ld.ld64 is a (too genericly named) "linker for macOS" (from LLDB.org)
thus is not available for Linux linkers
To workaround we first stopped using GNUstep makefiles to
disable all GNUstep magic understand what is going on and wrote our own makefiles.
The actual fix to force link/load all .o files was to explicitly pass --whole-archive to the linker:
-Wl,-whole-archive path/to/static/lib/containing/categories/libOwnLib1.a -Wl,-no-whole-archive
i have installed new glib library version 2.6 , And after creation i am trying to rename some of the symbols in glib library using objcopy command. Renaming symbols is necessary for our project support.
It fails with error below
objcopy --redefine-syms=glibrename libglib-2.0.a
BFD: libglib-2.0.a(deprecated_gcompletion.c.o): invalid relocation type 42
BFD: BFD version 2.20.51.0.2-5.36.el6 20100205 assertion fail elf64-x86-64.c:290
BFD: libglib-2.0.a(deprecated_gthread-deprecated.c.o): invalid relocation type 42
BFD: BFD version 2.20.51.0.2-5.36.el6 20100205 assertion fail elf64-x86-64.c:290
BFD: libglib-2.0.a(deprecated_gthread-deprecated.c.o): invalid relocation type 42
BFD: BFD version 2.20.51.0.2-5.36.el6 20100205 assertion fail elf64-x86-64.c:290
BFD: libglib-2.0.a(deprecated_gthread-deprecated.c.o): invalid relocation type 42
BFD: BFD version 2.20.51.0.2-5.36.el6 20100205 assertion fail elf64-x86-64.c:290
BFD: libglib-2.0.a(deprecated_gthread-deprecated.c.o): invalid relocation type 42
BFD: BFD version 2.20.51.0.2-5.36.el6 20100205 assertion fail elf64-x86-64.c:290
BFD: libglib-2.0.a(deprecated_gthread-deprecated.c.o): invalid relocation type 42
glibrename is a file where it has all glib original symbols defined and renamed symbols that i want to do.
Example file contents will be :
glib_melloc test_glib_melloc
glib_sym test_glib_sym
Here is my objcopy version:
[kltest#il-kltest ~]$ objcopy --version
GNU objcopy version 2.20.51.0.2-5.36.el6 20100205
Copyright 2009 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) any later version.
This program has absolutely no warranty.
Anyone please help why i am hitting this issue, Any idea?
Binutils 2.20 is just too old I'm afraid. (It's 9 years old.) Support for relocation type 42 was introduced about v2.25 /.26.
I am trying to use address sanitizer with g++ and during the build it produces the following linker command, which produces the error g++: error: cannot specify -static with -fsanitize=address
I don't understand what this means, so any help is appreciated. The g++ version is g++ (GCC) 8.3.0 20190222 (Cray Inc.).
g++ -g -fsanitize=address CMakeFiles/pisa.dir/src/Alphabet.cpp.o {more .o files} -o pisa -L/global/homes/e/esaliya/sali/git/bitbucket/combinatorial-blas-2.0/CombBLAS/_install/lib -Wl,-rpath,/global/homes/e/esaliya/sali/git/bitbucket/combinatorial-blas-2.0/CombBLAS/_install/lib -lCombBLAS -lGraphGenlib -lUsortlib
I have been working on porting a project from Visual Studio/VisualGDB running on a Win10 machine to a CMake/GCC build system running on Ubuntu 16.04. The complete build will eventually run on a Cortex-M4.
In this process, I encountered a linker issue where several references within libc are undefined
{...}/arm-none-eabi/lib/thumb/v7e-m/fpv4-sp/hard/libg_nano.a(lib_a-sbrkr.o): In function `_sbrk_r':
sbrkr.c:(.text._sbrk_r+0xc): undefined reference to `_sbrk'
{...}/arm-none-eabi/lib/thumb/v7e-m/fpv4-sp/hard/libg_nano.a(lib_a-writer.o): In function `_write_r':
writer.c:(.text._write_r+0x10): undefined reference to `_write'
{...}/arm-none-eabi/lib/thumb/v7e-m/fpv4-sp/hard/libg_nano.a(lib_a-closer.o): In function `_close_r':
closer.c:(.text._close_r+0xc): undefined reference to `_close'
{...}/arm-none-eabi/lib/thumb/v7e-m/fpv4-sp/hard/libg_nano.a(lib_a-fstatr.o): In function `_fstat_r':
fstatr.c:(.text._fstat_r+0xe): undefined reference to `_fstat'
{...}/arm-none-eabi/lib/thumb/v7e-m/fpv4-sp/hard/libg_nano.a(lib_a-isattyr.o): In function `_isatty_r':
isattyr.c:(.text._isatty_r+0xc): undefined reference to `_isatty'
{...}/arm-none-eabi/lib/thumb/v7e-m/fpv4-sp/hard/libg_nano.a(lib_a-lseekr.o): In function `_lseek_r':
lseekr.c:(.text._lseek_r+0x10): undefined reference to `_lseek'
{...}/arm-none-eabi/lib/thumb/v7e-m/fpv4-sp/hard/libg_nano.a(lib_a-readr.o): In function `_read_r':
readr.c:(.text._read_r+0x10): undefined reference to `_read'
I use the following flags:
CFLAGS:
-fdata-sections -ffunction-sections -std=gnu99 -mabi=aapcs -mcpu=cortex-m4 -mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16
ASM_FLAGS:
-x assembler-with-cpp
LDFLAGS:
-static -Wl,--gc-sections -mabi=aapcs -mcpu=cortex-m4 -mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16 --specs=nano.specs -lc -lnosys
These flags are from the original VisualGDB-build which build without any problems.
I found that when using --specs=nosys.specs instead of nano.specs, the build completes, but when running on target, a hard fault is triggered somewhere inside __libc_init_array().
My suspicions are that this is due to the difference between nano.specs and nosys.specs, however I am unable to verify this due to the linker issues mentioned above. I tried the combination <...> --specs=nono.specs --specs=nosys.specs -lc -lnosys without any luck.
Does anyone know why this works with VisualGDB and not with CMake/GCC? As far as I understand, VisualGDB still use arm-none-eabi? This is of course the same toolchain I am using (tested versions 4.9.3 and 6.3.1)
I'm trying to link a really simple GLES2 & EGL program using g++ 4.9.1, on a Ubuntu Trusty system. I'm using the mesa libraries.
I'm getting linker errors for EGL functions:
test.cpp:(.text+0x342): undefined reference to `eglGetDisplay'
test.cpp:(.text+0x389): undefined reference to `eglInitialize'
test.cpp:(.text+0x40f): undefined reference to `eglCreateContext'
test.cpp:(.text+0x458): undefined reference to `eglCreatePbufferSurface'
test.cpp:(.text+0x49e): undefined reference to `eglMakeCurrent'
I am compiling test.cpp with
g++ -std=c++0x -Wall -Werror -lEGL -lGLESv2 -o test test.cpp
I've tried switching the order of libraries, which sometimes matters, but I get the same problem. Is there a library I'm missing here?
I've run readelf -Ws /usr/lib/x86_64-linux-gnu/mesa-egl/libEGL.so and all of the required functions are defined.
You should put libraries to the end of a command line
g++ -std=c++0x -Wall -Werror -o test test.cpp -lEGL -lGLESv2
I managed to fix this by compiling the C++ file to an object file, and then linking as a separate step. I'm not sure why this works, when the one-line compilation doesn't.
g++ -std=c++0x -Wall -Werror -c -o test.o test.cpp
g++ -o test test.o -lGLESv2 -lEGL
I've put the question to the community to try to figure out why: Single-command compile and link fails, separate steps work