1

I've a C++ library which depends on libusb-1.0. This library is used in another program which works fine on arm32. Now I'm trying to the same with an arm64 device.

In the library I modified the -L path where to find the libusb-1.0.so to account for the different arch and the library built successfully.

When I try build a program on arm64 that uses this library, I get undefined reference to all the libusb methods used in the library. I made sure to have libusb-1.0-0-dev installed in the arm64 system and everything else seems in order. The program is the same that used the arm32 library on arm32 and worked fine. The program itself should work just fine with the arm64 lib on arm64.

Error:

/usr/bin/ld: ./libExample.so: undefined reference to `libusb_get_config_descriptor'
/usr/bin/ld: ./libExample.so: undefined reference to `libusb_open'
/usr/bin/ld: ./libExample.so: undefined reference to `libusb_get_device_list'
/usr/bin/ld: ./libExample.so: undefined reference to `libusb_clear_halt'
/usr/bin/ld: ./libExample.so: undefined reference to `libusb_exit'
/usr/bin/ld: ./libExample.so: undefined reference to `libusb_free_device_list'
/usr/bin/ld: ./libExample.so: undefined reference to `libusb_get_device'

The library makefile with LDFLAGS updated:

CC  = g++
RM      = rm -r
CFLAGS  = -fPIC -g -Wall
LIBS    = -lusb-1.0
LDFLAGS = -L/usr/lib/aarch64-linux-gnu
INCLUDE =
TRG_DIR = ./out
TARGET  = libExample.so
SRC_DIR = ./
SOURCES = $(shell ls $(SRC_DIR)/*.cpp)
OBJ_DIR = ./obj
OBJECTS = $(subst $(SRC_DIR),$(OBJ_DIR), $(SOURCES:.cpp=.o))
VSCRIPT =

$(TARGET): $(OBJECTS)
    @if [ ! -d $(TRG_DIR) ]; \
        then echo "mkdir -p $(TRG_DIR)"; mkdir -p $(TRG_DIR); \
    fi
    $(CC) -fPIC -shared $(LDFLAGS) $(LIBS) -o $(TRG_DIR)/$@ $^ $(VSCRIPT)

$(OBJ_DIR)/%.o: $(SRC_DIR)/%.cpp
    @if [ ! -d $(OBJ_DIR) ]; \
        then echo "mkdir -p $(OBJ_DIR)"; mkdir -p $(OBJ_DIR); \
    fi
    $(CC) -c $(CFLAGS) -o $@ $^

The program makefile is similar but with the reference to the lib:

LIBS = -lExample
LDFLAGS = -L.

Am I missing something?

erik7854
  • 150
  • 1
  • 16
  • Possibly [link order](https://stackoverflow.com/questions/45135/why-does-the-order-in-which-libraries-are-linked-sometimes-cause-errors-in-gcc)? It looks like your libraries may be appearing on the link command line before the object files or other libraries that reference them, which would cause this. Perhaps you could post the actual linker command line that gets executed by make. – Nate Eldredge Mar 03 '23 at 15:18
  • Regarding `pthread_mutexattr_destroy`, you also seem to be missing a `-pthread` option when compiling and linking. – Nate Eldredge Mar 03 '23 at 15:19
  • I removed the -lpthread flag to make the question more simple as they seems to share the issue regarding the order...it was indeed that, thank you. but why on arm32 it was working fine anyway? Moving the flags at the end worked, thaks again – erik7854 Mar 03 '23 at 15:30

0 Answers0