0

I'm trying to move my Makefile to cmake. The problem is that when it comes to linking stage, it cannot find the shared library.

My cmake is:

set(PROJECT_LINK_LIBS libsr_tps.so)
link_directories(absolute/path/to/the/library)

I also tried:

find_library(PROJECT_LINK_LIBS NAMES sr_tps PATHS "${PROJECT_SOURCE_DIR}/lib")

and then:

add_executable(project ${SOURCE})
target_link_libraries(project ${PROJECT_LINK_LIBS})

The sources can be cross-compiled successfully. But after compiling, it always says:

/absolute/path/to/ld: cannot find -lsr_tps
collect2: ld returned 1 exit status

given that libsr_tps.so has already been pre-cross-compiled.

Makefile works fine for both compiling and generating the final executable.

I have been looking for the potential issue for many hours. The solutions just don't work.

What could be wrong?

Thanks.


Update:

The way for build with make:

  1. Set some environment parameters, i.e. some export.
  2. Makefile:

    LDFLAGS += -L./lib
    CFLAGS += -Wall -Wno-pointer-sign
    LDLIBS = -lsr_tps
    all: $(TARGET)
    $(TARGET): $(OBJS) $(OBJS_ROS) 
         $(CC) $(LDFLAGS) $(OBJS) $(OBJS_ROS) $(LDLIBS) -o $(TARGET) 
         cp $^ ./$(BINARY)/$(OBJ_DIR) 
         mv $@ ./$(BINARY) 
    
    .c.o: $(CC) $(CFLAGS) -o $@ -c $<
    

Update 2:

Here is my Makefile:

TARGET = ros
LDFLAGS += -L./lib
CFLAGS += -Wall -Wno-pointer-sign -DWSU_5001 -I./include -I./include/WSU-5001_include -I./include/J2735 -I./ -pthread -O
LDLIBS = -lsr_tps -lrisapi -lrt -lipc -lm -ldot2 -ldot3 -lcrypto -lgps -ltpsapi
SHARED_FLAGS = -fPIC -shared

BINARY= bin
SRC_DIR = ./src
J2735_DIR = ./src/J2735
#OBJ_DIR = ./binary/obj
OBJ_DIR = obj

OBJS_TEST=${ASN_MODULE_SOURCES:.c=.o} ${ASN_CONVERTER_SOURCES:.c=.o}
OBJS=${ASN_MODULE_SOURCES:.c=.o}
OBJS_ROS = ros.o tx.o rx.o util.o config.o

all: $(TARGET)
    mkdir -p $(BINARY)
    mkdir -p $(BINARY)/$(OBJ_DIR)

$(TARGET): $(OBJS) $(OBJS_ROS)
    $(CC) $(LDFLAGS) $(OBJS) $(OBJS_ROS) $(LDLIBS) -o $(TARGET) 
    cp $^ ./$(BINARY)/$(OBJ_DIR)
    mv $@ ./$(BINARY)

# $(TARGET): $(OBJS)
#   $(CC) $(OBJS) $(CFLAGS) -o $@

.SUFFIXES:
.SUFFIXES: .c .o

.c.o:
    $(CC) $(CFLAGS) -o $@ -c $<

Command line after executing make:

path/to/powerpc-e300c3-linux-gnu-gcc -L./lib <all .o files> -lsr_tps -lrisapi -lrt -lipc -lm -ldot2 -ldot3 -lcrypto -lgps -ltpsapi -o ros

And below is my CMakeList:

cmake_minimum_required(VERSION 3.5.1)
project(Denso-ROS)

set(CMAKE_SYSTEM_NAME Denso-linux)
set(CMAKE_SYSTEM_PROCESSOR "^(powerpc|ppc)")

set(GCC_COVERAGE_COMPILE_FLAGS "-static -Wall -Wno-pointer-sign -DWSU_5001 -pthread -O")

#################
#problem

#set(GCC_COVERAGE_LINK_FLAGS "libsr_tps.so -lrisapi -lrt -lipc -lm -ldot2 -ldot3 -lcrypto -lgps -ltpsapi")
#set(GCC_COVERAGE_LINK_FLAGS "-L./lib")

#set(CMAKE_LINK_LIBRARY_FLAG "-lsr_tps -lrisapi -lrt -lipc -lm -ldot2 -ldot3 -lcrypto -lgps -ltpsapi")

#set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} ${GCC_COVERAGE_LINK_FLAGS}" )

set(PROJECT_LINK_LIBS libsr_tps.so)
link_directories(home/yufeiyan/DENSO-WSU5K1-SDK_VM_Ubuntu_Peloton/Denso/lib)

#################
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} ${GCC_COVERAGE_COMPILE_FLAGS}" )

set(tools ${PROJECT_SOURCE_DIR}/toolchain/bin)
set(CMAKE_C_COMPILER ${tools}/powerpc-e300c3-linux-gnu-gcc)
set(CMAKE_CXX_COMPILER ${tools}/powerpc-e300c3-linux-gnu-g++)

find_library(DENSO_LIB NAMES sr_tps PATHS "${PROJECT_SOURCE_DIR}/lib")  
message(STATUS "${DENSO_LIB}")

include_directories(
    ${PROJECT_SOURCE_DIR}
    include
    include/J2735
    include/WSU-5001_include)


file(GLOB SOURCE ${PROJECT_SOURCE_DIR}/*.c src/*.c src/J2735/*.c)
list(REMOVE_ITEM SOURCE ${PROJECT_SOURCE_DIR}/src/J2735/converter-example.c)
list(REMOVE_ITEM SOURCE ${PROJECT_SOURCE_DIR}/src/J2735/test.c)

#add_executable(ros ${SOURCE1} ${SOURCE2} ${SOURCE3})

add_executable(ros ${SOURCE})
target_link_libraries(ros ${PROJECT_LINK_LIBS})

Command line after executing make:

path/to/powerpc-e300c3-linux-gnu-gcc   -static -Wall -Wno-pointer-sign -DWSU_5001 -pthread -O <all .o files> -L/path/to/project/lib -lsr_tps -Wl,-rpath, path/to/project/lib path/tp/powerpc-e300c3-linux-gnu/bin/ld: cannot find -lsr_tps
AU_yzy0050
  • 33
  • 7
  • 1
    so, this is a cross-compile with something like this ? `cmake -DCMAKE_TOOLCHAIN_FILE=~/toolchain.cmake` – Wei Guo Jun 22 '18 at 05:33
  • Please, show `make` command line which works. Also, you may check command line executed by `cmake` with `make VERBOSE=1`. – Tsyvarev Jun 22 '18 at 07:56
  • @WeiGuo I don't have cmake for toolchain. In the CMakeList.txt, I set the cross-compiler environment variable: `set(CMAKE_C_COMPILER path/to/compiler)` and `set(CMAKE_CXX_COMPILER path/to/compiler)` – AU_yzy0050 Jun 25 '18 at 03:59
  • @Tsyvarev 1. in Makefile, set some environment parameters, i.e. some `export`. 2. `LDFLAGS += -L./lib` `CFLAGS += -Wall -Wno-pointer-sign` `LDLIBS = -lsr_tps` `all: $(TARGET)` `$(TARGET): $(OBJS) $(OBJS_ROS) $(CC) $(LDFLAGS) $(OBJS) $(OBJS_ROS) $(LDLIBS) -o $(TARGET) cp $^ ./$(BINARY)/$(OBJ_DIR) mv $@ ./$(BINARY)` `.c.o: $(CC) $(CFLAGS) -o $@ -c $<` – AU_yzy0050 Jun 25 '18 at 04:01
  • @AU_yzy0050 Can you try a clean build? rm the entire build directory or the cache file CMakeCache.txt, and build again. – Wei Guo Jun 25 '18 at 05:21
  • @AU_yzy0050: Do not use comments for multiline code. Instead, [edit] the question add the code into it. – Tsyvarev Jun 25 '18 at 07:46
  • @WeiGuo Yes, I did. It did not work anyway. – AU_yzy0050 Jun 25 '18 at 19:38
  • @Tsyvarev sorry for the inconvenience. Please see the update in the question. – AU_yzy0050 Jun 25 '18 at 19:49
  • Have you tried `make VERBOSE=1` for check which command line CMake creates for you? – Tsyvarev Jun 25 '18 at 20:09
  • @Tsyvarev yes, I did. It looks like the command is quite similar with the command from Makefile. But it still returned `path/to/toolchain/bin/ld/: cannot find -lsr_tps`. – AU_yzy0050 Jun 26 '18 at 03:27
  • The error means that some commands in Makefile and ones generated by CMake are not quite similar. It could be that in case of CMake some environment variable are not set, or `-L` option to the linker is wrong. It is difficult to say more concrete without viewing **exact command lines**, or **exact code**. – Tsyvarev Jun 26 '18 at 07:54
  • @Tsyvarev Please see my update 2. I've attached my Makefile, CMakeLists and command line after execution. Thanks a lot. – AU_yzy0050 Jun 26 '18 at 21:58
  • Possible duplicate of [-static option for gcc?](https://stackoverflow.com/questions/8692128/static-option-for-gcc) – Tsyvarev Jun 26 '18 at 23:13
  • In short, because CMake generates `-static` option for the linker, only static libraries (`.a` or `.la`are searched), and `.so` is not usable in that case. – Tsyvarev Jun 26 '18 at 23:15
  • Why people tend to replace absolute paths in logs with some shortcuts, like `path/to/toolchain/bin/ld/`? Do you think that a person intended to help wants to skip everything unrelated to the problem? - But it is very possible, that exactly hidden paths are the reason. Do you want to hide personal information, like a user name? - But such information is rarely secure or have a real meaning. When I see error logs with replaced path, I always thought: it is **possible** that some **meaningful information is replaced by accident**. BTW, you reveal actual path in `link_directories` call. – Tsyvarev Jun 26 '18 at 23:22
  • Hey, @Tsyvarev, thank you. You are **right**. It is the path which causes the error. I didn't carefully check the path in command line. It is very long in terminal, so I simply replace it with `path/to/` to not make things messed up. So the solution is substituting `link_directories(home/yufeiyan/DENSO-WSU5K1-SDK_VM_Ubuntu_Peloton/Denso/lib)` with `link_directories(${PROJECT_SOURCE_DIR}/lib)`. I don't know why giving absolute path in `link_directories` call causes duplicate path to the library path. – AU_yzy0050 Jun 27 '18 at 00:38
  • I also removed `-static` option. This could be another issue in the CMakeList.txt. Thank you all. – AU_yzy0050 Jun 27 '18 at 03:08

1 Answers1

1

Many thanks to Tsyvarev.

Let me sum up the issue and solution:

The linker can not find the library due to the incorrect path. I used link_directories(absolute/path/to/lib), and it returned a duplicate path. Instead, using link_directories(${PROJECT_SOURCE_DIR}/lib) solved the problem. The linker has the correct path and find the library.

In the meantime, I remove the -static option for CFLAGS. This option may also cause the linker not finding the library.

AU_yzy0050
  • 33
  • 7