I am trying to use the Command Transmission Interface from the Trusted Software Stack for the TPM 2.0 and I cannot seem to get this library loaded. Any use gives an "undefined reference" error.
Had the same problem when using the ESAPI from TSS as well and fixed it with the following flag in my Makefile: TPMFLAGS =-L=/usr/local/lib/ -ltss2-esys.
Following is my Makefile in its current implementation:
CC = gcc
CFLAGS = -std=c99 -Wall -I$(IDIR)
TPMFLAGS =-L=/usr/local/lib/ -ltss2-esys -ltss2-tcti-device
IDIR = ./includes/
SRCDIR = ./src/
BINDIR = ./bin/
SOURCES = $(SRCDIR)*.c
all: $(BINDIR)antiEvilMaid
$(BINDIR)antiEvilMaid: $(BINDIR)main.o $(BINDIR)errors.o
$(CC) $(BINDIR)main.o $(BINDIR)errors.o $(TPMFLAGS) -o $#
$(BINDIR)main.o: $(SRCDIR)main.c $(IDIR)main.h
$(CC)$(CFLAGS) -c $(SRCDIR)main.c -o $#
$(BINDIR)errors.o: $(SRCDIR)errors.c $(IDIR)main.h
$(CC)$(CFLAGS) -c $(SRCDIR)errors.c -o $#
run:
$(BINDIR)antiEvilMaid init
clean:
rm $(BINDIR)*.o $(BINDIR)antiEvilMaid
memtest:
valgrind --leak-check=full $(BINDIR)antiEvilMaid init
Related
I'm trying to compile a C program on Windows for use on a linux dev board.
When I try to compile using a makefile I get this output:
$ make
arm-linux-gnueabihf-gcc -g -Wall main.c -o filetest
process_begin: CreateProcess(NULL, arm-linux-gnueabihf-gcc -g -Wall main.c -o filetest, ...) failed.
make (e=2): The system cannot find the file specified.
make: *** [filetest] Error 2
This happens whether or not a blank file called filetest is present or not in the same directory. If it is present, I can run make clean and it will remove the file.
Here is the makefile I'm using:
#
TARGET = filetest
ALT_DEVICE_FAMILY ?= soc_cv_av
SOCEDS_ROOT ?= $(SOCEDS_DEST_ROOT)
HWLIBS_ROOT = $(SOCEDS_ROOT)/ip/altera/hps/altera_hps/hwlib
CROSS_COMPILE = arm-linux-gnueabihf-
CFLAGS = -g -Wall -D$(ALT_DEVICE_FAMILY) -I$(HWLIBS_ROOT)/include/$(ALT_DEVICE_FAMILY) -I$(HWLIBS_ROOT)/include/
LDFLAGS = -g -Wall
CC = $(CROSS_COMPILE)gcc
ARCH= arm
build: $(TARGET)
#
$(TARGET):main.c
$(CC) $(LDFLAGS) $^ -o $#
%.o : %.c
$(CC) $(CFLAGS) -c $< -o $#
.PHONY: clean
clean:
rm -f $(TARGET) *.a *.o *~
I used tabs in my actual makefile instead of spaces for the code block above ^^
Also, I'm working within Intel's FPGA SoC EDS for a Cyclone V board.
I am trying to successful execute a make file that comes from a new crytpo-coin called Sia Coin. It can be found here Sia Coin GPU Miner. It's relatively new and so some stuff requires more manual installation. I was getting the following error on Ubuntu 16.04 when using the make file. CL/cl.h was missing, and I was able to install and it is located at /usr/include/nvidia-361/CL/cl.h. However, when I ran the make file I still get errors so I think I need to include this path someone in the Make file, the problem is I am not familiar with make files at all. Below is the Make file I need to edit to include the path for compilation:
ifeq ($(shell uname -s),Darwin)
CC ?= clang
LDLIBS += -lcurl -framework OpenCL
else
CC ?= gcc
LDLIBS += -lOpenCL -lcurl
endif
CFLAGS += -c -std=c11 -Wall -pedantic -O2
TARGET = sia-gpu-miner
SOURCES = sia-gpu-miner.c network.c
OBJECTS = $(patsubst %.c,%.o,$(SOURCES))
all: $(TARGET)
%.o: %.c
$(CC) $(CFLAGS) -o $# $<
$(TARGET): $(OBJECTS)
$(CC) -o $# $^ $(LDLIBS)
clean:
rm -f $(TARGET) $(OBJECTS)
.PHONY: all clean
Any help toward solving this problem is greatly appreciated.
Edit:
A new message I am getting now adding
CFLAGS += -c -std=c11 -Wall -pedantic -O2 -I /usr/include/nvidia-361
is now:
-lOpenCL -lcurl /usr/bin/ld: cannot find -lOpenCL collect2: error: ld returned 1 exit status
Two files did compile:
sia-gpu-miner.c
network.c
But I don't know enough to know why the -lOpenCL is not found. No ld directory exists in that directory location in the error if that helps.
Try changing
CFLAGS += -c -std=c11 -Wall -pedantic -O2
to
CFLAGS += -c -std=c11 -Wall -pedantic -O2 -I /usr/include/nvidia-361
I am trying to compile a C language library as a shared object on my new install of Fedora 22. The project compiled fine on my old install of Fedora 20. But now, when I run my makefile:
CC=gcc
vpath %.c src
vpath %.h inc
CFLAGS = -fPIC
INCLUDE = -Iinc -I/usr/include -I/usr/local/include
LIBPATH = -L/usr/lib -L/lib64
LIBS = -lportaudio -lm -lpthread -ldl
OBJ_PATH = ./objs
SRCS = my_code1.c my_code2.c # etc.
OBJS = $(SRCS:.c=.o)
.PHONY: libmylib.so
all: libmylib.so
debug: $(CFLAGS) += -DDEBUG -O0 -g3 -DPD
debug: all
release: $(CFLAGS) += -DTESTING -O2 -DPD -funroll-loops -fomit-frame-pointer
release: all
%.o: %.c
$(CC) $(CFLAGS) $(INCLUDE) $(LIBPATH) $(LIBS) -c -o $# $^
libmylib.so: $(OBJS)
$(CC) -shared -Wl,-soname,libmylib.so \
-Wl,--no-undefined $(OBJS) -lc -lportaudio -ldl -lm -lpthread
mv libmylib.so ./bin
mv *.o $(OBJ_PATH)
clean:
rm $(OBJ_PATH)/*.o
rm bin/libmylib.so
I get very many undefined reference errors:
my_code1.o: In function `func_in_my_code1':
my_code1.c:(.text+0x1b8): undefined reference to `func_from_my_code2'
my_code2.o: In function `func_in_my_code2':
my_code2.c:(.text+0x310): undefined reference to `func_from_my_func1'
The functions in question are most certainly defined in the code. Presumably these are compiled into .o files in the compile stage.
The exact same build environment worked on my previous fedora installation. I am at a loss as to why I should get these errors.
Also, if I compile without the -Wl,--no-undefined flag, it compiles fine, but when I try to load the library from another application, it tosses the same set of undefined errors.
This may have nothing to do with the new version of Fedora. It is possible that there are some environment variables or something that didn't make through to my new install, but I have no idea what they could be.
Apparently I now need to insert the extern keyword into these functions. The code compiled and ran perfectly well before... I would like to reiterate, for posterity's sake, that I did post the entire makefile in my question.
Hello I need to compute logarithms on my stm32. I use arm-none-eabi-gcc. When I add -L/opt/tools/Sourcery_G++_Lite/arm-none-eabi/lib/ in my Makefile microcontroller stop to work. Unfortunately I can't debug my program because there is no debag pins on my device and I load program to flash via bootloader. I not use any math functioins from libraries - i just add library path to Makefile.
Here is my full makefile:
OUTPUTDIR = $(BUILDDIR)/../../output
DEPDIR = $(BUILDDIR)/.dep
PWD = $(shell pwd)
COMMONFLAGS = -mcpu=cortex-m3 -mthumb -ggdb3
CFLAGS += $(COMMONFLAGS) -Os $(INCLUDES) -I.
CFLAGS += -std=c99 -Wall -Wextra -static -fdata-sections -ffunction-sections -fno-hosted -fno-builtin
CFLAGS += -nostdlib -nodefaultlibs
CFLAGS += -mapcs-frame -msoft-float
CFLAGS += -MD -MP -MF $(DEPDIR)/$(#F).d
LDFLAGS = $(COMMONFLAGS) -static
LDFLAGS += -fno-exceptions -ffunction-sections -fdata-sections
LDFLAGS += -static -Xlinker --gc-sections
#LDFLAGS += -L/opt/tools/dima/Sourcery_G++_Lite/arm-none-eabi/lib/
ASFLAGS = $(COMMONFLAGS)
CFLAGS += -DUSE_STDPERIPH_DRIVER
CROSS = /opt/tools/Sourcery_G++_Lite/bin/arm-none-eabi
GCC = $(CROSS)-gcc
AS = $(CROSS)-as
SIZE = $(CROSS)-size
OBJCOPY = $(CROSS)-objcopy
OBJDUMP = $(CROSS)-objdump
NM = $(CROSS)-nm
COBJ = $(addprefix $(BUILDDIR)/, $(CSRC:.c=.c.o))
ASMOBJ = $(addprefix $(BUILDDIR)/, $(ASMSRC:.s=.s.o))
OBJ = $(COBJ) $(ASMOBJ)
V = $(if $(VERBOSE), , #)
all: prebuild $(BUILDDIR)/$(TARGET).elf $(LDSCRIPT)
#$(SIZE) $(BUILDDIR)/$(TARGET).elf
#$(OBJCOPY) -O binary $(BUILDDIR)/$(TARGET).elf $(BUILDDIR)/$(TARGET).bin
#$(OBJCOPY) -O ihex $(BUILDDIR)/$(TARGET).elf $(BUILDDIR)/$(TARGET).hex
#$(OBJDUMP) -h -S -z $(BUILDDIR)/$(TARGET).elf > $(BUILDDIR)/$(TARGET).lss
#$(NM) -n $(BUILDDIR)/$(TARGET).elf > $(BUILDDIR)/$(TARGET).sym
#mkdir -p $(OUTPUTDIR)
#cp $(BUILDDIR)/$(TARGET).bin $(OUTPUTDIR)
#echo =======================================================================
$(BUILDDIR)/$(TARGET).elf: $(OBJ)
#echo Linking $#
$(GCC) $(LDFLAGS) -T $(PWD)/$(LDSCRIPT) -o $# $(OBJ) -lm
$(COBJ): $(BUILDDIR)/%.c.o : %.c
#echo Compiling $<
#-mkdir -p $(#D)
$(GCC) $(CFLAGS) -c $< -o $#
$(ASMOBJ): $(BUILDDIR)/%.s.o : %.s
#echo Assembling $<
#-mkdir -p $(#D)
$(V)$(AS) $(ASFLAGS) -c ./$< -o $#
-include $(shell mkdir -p $(DEPDIR) 2>/dev/null) $(wildcard $(DEPDIR)/*)
.PHONY: clean output
clean:
rm -rf $(BUILDDIR)
What i do wrong? Thanks.
Whith this library dir you will simply link against the wrong set of files in multilib, and end up linking with ARM code while your MCU can only execute THUMB code. The correct set of files should be in the thumb2 subdirectory for Cortex M3 µC.
Note that Sourcery G++ lite will auto-magically add the correct library dir when using arm-none-eabi-gcc to link, which your Makefile seems to do already.
You really shouldn't link libm.a manually and you really shouldn't hardcode library path manually... This all gets done automatically (and correctly) if you use arm-none-eabi-gcc (or -g++) to link and give proper flags (-mcpu and -mthumb). So just drop all these paths and "-lm" and it must work. You could try one of my example project for ARM microcontrollers - the settings in the makefiles (and linker scripts) make all of this work just fine - with no user intervention. http://www.freddiechopin.info/en/download/category/6-examples
Also - I think part of the problem may be in these flags you use: -fno-hosted -fno-builtin -nostdlib -nodefaultlibs - the last one especially prevents this automatic linking of libm.a.
I want my makefile to build the same binary 2 times, first compiling with gcc and then with mingw. So, I've written this, but it does not work:
OBJ_DIR = obj
SRC_DIR = src
BIN_DIR = bin
INCLUDE = -I./$(SRC_DIR)
LIBS =
_SRCS = print_current_dir.c test_main.c
_OBJS = print_current_dir.o test_main.o
SRCS = $(addprefix $(SRC_DIR)/,$(_SRCS))
OBJS = $(addprefix $(OBJ_DIR)/,$(_OBJS))
all: $(BIN_DIR)/pps-linux $(BIN_DIR)/pps-win32
$(OBJ_DIR)/%.o: $(SRC_DIR)/%.c
$(CC) -c -o $# $< $(CFLAGS)
$(BIN_DIR)/pps-linux: CC = cc
$(BIN_DIR)/pps-linux: CFLAGS = -g -Wall $(INCLUDE) $(LIBS)
$(BIN_DIR)/pps-linux: $(OBJS)
$(CC) $(CFLAGS) $(OBJS) -o $#
$(BIN_DIR)/pps-win32: CC = i586-mingw32msvc-cc
$(BIN_DIR)/pps-win32: CFLAGS = -g -Wall $(INCLUDE) $(LIBS)
$(BIN_DIR)/pps-win32: $(OBJS)
$(CC) $(CFLAGS) $(OBJS) -o $#
Once it compiles the objects file in $(OBJS) with gcc for the target pps-linux, it tries to build pps-win32 with the very same objects file, obviously failing, and despite the fact that I redefined CC and CFLAGS for the target pps-win32.
Here is the output:
$ make
cc -c -o obj/print_current_dir.o src/print_current_dir.c -g -Wall -I./src
cc -c -o obj/test_main.o src/test_main.c -g -Wall -I./src
cc -g -Wall -I./src obj/print_current_dir.o obj/test_main.o -o bin/pps-linux
i586-mingw32msvc-cc -g -Wall -I./src obj/print_current_dir.o obj/test_main.o -o bin/pps-win32
obj/print_current_dir.o: In function `print_dir':
/home/matteo/Desktop/pps/src/print_dir.c:23: undefined reference to `get_current_dir_name'
/home/matteo/Desktop/pps/src/print_dir.c:25: undefined reference to `puts'
/home/matteo/Desktop/pps/src/print_dir.c:27: undefined reference to `free'
/usr/lib/gcc/i586-mingw32msvc/4.4.4/../../../../i586-mingw32msvc/lib/libmingw32.a(main.o):(.text+0x85): undefined reference to `_WinMain#16'
collect2: ld returned 1 exit status
make: *** [bin/pps-win32] Error 1
How do I force the recompilation of the objects file just compiled with a different compiler?
Thank you.
By making the object files compiler-dependent too, rather than trying to overwrite the same .o file in place with different contents, eg.
LINUX_OBJS = $(addprefix $(LINUX_OBJ_DIR)/,$(_OBJS))
...
$(BIN_DIR)/pps-linux: $(LINUX_OBJS)
NB. you may be able to do it more tidily by just using a target-dependent definition of OBJ_DIR, ie,
$(BIN_DIR)/pps-linux: OBJ_DIR = linux-obj
but I'd have to try it to be sure.
I would suggest using separate OBJ_DIR and BIN_DIR directories to accomplish this, with the names being constructed in part from the compiler vendor:
OBJ_DIR = obj-$(CC)
BIN_DIR = bin-$(CC)
I use a similar approach that has completely separate build directories, and installation directories, with the names constructed from:
compiler vendor
compiler version
architecture
libc version (if linux)
which results in directories named (for example):
gcc_3.4.6-x86-libc_2.3.4
forte_5.10-x64
gcc_4.2.3-x86