nongeneric / lsd2dsl

Lingvo dictionaries decompiler
MIT License
84 stars 19 forks source link

Building on MacOS #10

Closed lxnk closed 5 years ago

lxnk commented 5 years ago

I tried to build it on MacOS 10.14 Mojave. Cmake went well, got problems with make. Compiling went well, but linking failed.

[ 73%] Linking CXX static library libdictlsd.a
[ 73%] Built target dictlsd
Scanning dependencies of target tests
[ 78%] Building CXX object CMakeFiles/tests.dir/tests.cpp.o
[ 82%] Linking CXX executable tests
ld: library not found for -lgtest
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [tests] Error 1
make[1]: *** [CMakeFiles/tests.dir/all] Error 2
make: *** [all] Error 2

All libs lie in /usr/local/lib (I'm using Homebrew). Googletest was installed as

brew install --HEAD https://gist.githubusercontent.com/Kronuz/96ac10fbd8472eb1e7566d740c4034f8/raw/gtest.rb

This install static library only. The problem, however, is with all external libs - even if dynamic version .dylib is there. Any ideas where I could screw up the building?

Thank you in advance, Alex

nongeneric commented 5 years ago

Sorry, I'm not familiar with MacOS. Looks like the linker doesn't search the right directories, or you indeed don't have the libraries installed. In any case I'm afraid I won't be of much help here. I'd start with compiling a hello world to make sure the problem isn't limited to lsd2dsl

clang++ main.cpp -lgtest

And looking at the linker search directories with

ld --verbose | grep SEARCH_DIR

From there you could probably deduce the real issue.

(Also, you can skip the gtest dependency by passing -DCMAKE_RELEASE=TRUE to cmake)

lxnk commented 5 years ago

Hi! Thats the thing: clang++ (it's MacOS native, lies in /usr/bin ) coupled and linkes main.cpp with hello world code with no problem. Linker runs with -lgtest -L/usr/local/lib, and it is indeed where the HomeBrew installed googletest is. I attached the log.

It's something with the Cmake configuration that does not let clang++ to look for libs automatically.... Unfortunately all I know about Cmake is the I need to type cmake . :)

P.S. running make with -DCMAKE_RELEASE=TRUE gives the same problem, but now with next linked lib, namely minizip. It's not a compiler, it's cmake, I'd say...

lxnk commented 5 years ago

Update.

It seems this is some general MacOS+Homebrew's Cmake problem. The hello world project get's compiled as

clang++ main.cpp -lgtest

with no problem. But if I write the simplest CMakeList.txt like this:

cmake_minimum_required (VERSION 2.6)
project (HelloWorld)
add_executable(helloworld main.cpp)
target_link_libraries (helloworld gtest)

CMake process it ok, but when I do make linking does not work. Forcing the paths

cmake -DCMAKE_INCLUDE_PATH=/usr/local/include/ -DCMAKE_LIBRARY_PATH=/usr/local/lib/ .

does not work, Cmake tells me

CMake Warning:
  Manually-specified variables were not used by the project:

    CMAKE_INCLUDE_PATH
    CMAKE_LIBRARY_PATH

The only workaround I found is to change CMakeList.txt into

cmake_minimum_required (VERSION 2.6)
project (HelloWorld)
add_executable(helloworld main.cpp)
find_library(GTEST gtest)
target_link_libraries (helloworld ${GTEST})

but this is ugly. I'm trying to minimize the changes in the project's CMakeList.txts to make it work on MacOS... I'll write you back when I'll find out an elegant fix.

nongeneric commented 5 years ago

Thank you for looking into this. I think your workaround with find_library is exactly the right thing to do. I should've used it in the first place. I've just committed the changes and everything seems to work on Linux and when cross-compiling for Windows.

lxnk commented 5 years ago

I noticed that find_library checks /usr/local/lib but if one does pure target_link_libraries (helloworld gtest) cmake adds -lgtest flag to linker only, no -L/usr/local/lib. The linker itself automatically looks into /usr/lib but not into /usr/local/lib. Can you confirm that your previous CMakeList.txt runs ok if libgtest is in /usr/lib but fails if it is in /usr/local/lib? If my suggestion correct we can simply fix with single line link_directories(/usr/local/lib)

lxnk commented 5 years ago

I read the manuals again and they discourage to use the direct naming of the paths. The recommended way is as you did

find_library(GTEST gtest)
target_link_libraries (helloworld ${GTEST})

or, if we want to control whether it linked statically or dynamically

find_library(GTEST gtest)
add_library(gtest STATIC IMPORTED)
set_target_properties(gtest PROPERTIES IMPORTED_LOCATION ${GTEST})
target_link_libraries(helloworld gtest)

In any case your fix worked by me, program is build and functions. Hence, let's close the issue.