invalid LOC header block project compilation - kotlin

I'm writing a simple Kotlin project as example of a my library's usage. The code is available on github. When I try to compile it, the compiler show me the following error:
I deleted build folders and .gradle directories, but nothing changes. Any ideas?

Related

Dependencies between Android native modules (prefab) fail to build

Our Android application consists of 40-some Android Library Modules (ALMs), each of which also builds a C++ shared library with externalNativeBuild and CMake. So far we had the dependencies between these libs set up like this:
The dependent ALM references the dependency ALM with api project(':lib')
The dependent CMake script references the dependency .so with add_library(SHARED IMPORTED lib) and set_target_properties(lib PROPERTIES IMPORTED_LOCATION ...) and a relative path.
Recently we had to upgrade to the latest Android API version. This started off a cascade because now we were getting deprecated warnings in code generated by the navigation-ktx library, but upgrading that requires upgrading Gradle and the Android Gradle plugin. After that I started getting errors like liblib.so, needed by 'project', missing and no known rule to make it.
It looks like the latest Gradle parallelizes build tasks more heavily, and this means the dependent CMake/Ninja builds are being started concurrently with their dependencies, resulting in this error because the dependency is not yet built. I figured out that what we were doing was not entirely supported, but there is a "supported" way to do that now, so I refactored our entire build to use Prefab.
Now I started getting other errors, alternating between:
1.
C++ build system [prefab] failed while executing ...
Usage: prefab [OPTIONS] PACKAGE_PATH...
Error: Invalid value for "PACKAGE_PATH": Directory ... is not readable.
ld: error: undefined symbol ...
I looked into build/intermediates and found that in the 2nd case, the cmake config script was generated incorrectly: instead of add_library(lib::lib SHARED IMPORTED ) it had add_library(lib::lib INTERFACE IMPORTED) like it it was a header only library, and there was no IMPORTED_LOCATION set in the file.
What am I doing wrong and what should I do to unbreak our build?
It looks like the toolchain support for prefab interdependencies within a project is not quite finished. Others are reporting the same kind of errors at https://issuetracker.google.com/issues/265544858:
This appears to be a race condition with generating prefab cmake files.
It says in https://issuetracker.google.com/issues/221231432 that the header-only cmake config is generated to satisfy Android Studio's IDE features (completion, etc.) before the library is actually built.
Treat as-yet-unconfigured modules as if they are Header-only libraries for Android Studio purposes. This works because Android Studio doesn't care about linker flags for the purposes of providing language services.

CMake linking error at runtime from other lib in subdirectory

I am trying to get a project running that is using dynamic openCASCADE libraries.
So first i set up a minimal test project using the following CMake file:
...
include_directories(/home/user/occt/build_r/include/opencascade/)
add_executable(testOCCT
main.cpp
step2stl.cpp
)
find_package(OpenCASCADE REQUIRED NO_DEFAULT_PATH)
set(OCCT_LIBS TKMesh; TKSTEP; TKSTL; TKXSBase; TKernel)
target_link_libraries(testOCCT ${OCCT_LIBS})
This is working as it should.
Now i want to link the same libraries to another library that is used in a larger project.
For the project there are 3 CMake files, one for the project and two subdirectory, one for the executable one for the myLib, which are added by add_subdirectory().
In the CMake file for myLib which is inside one of the subdirectories I've added:
...
include_directories(/home/user/occt/build_r/include/opencascade/)
...
add_library(${MY_LIB_NAME} SHARED ${my_sources})
find_package(OpenCASCADE REQUIRED NO_DEFAULT_PATH)
set(OCCT_LIBS TKMesh; TKSTEP; TKSTL; TKXSBase; TKernel)
target_link_libraries(${MY_LIB_NAME} ${OCCT_LIBS})
so basically the same as in the test project.
However now I get an error (at runtime):
symbol lookup error: myLib.so: undefined symbol: _ZN24BRepMesh_IncrementalMeshC1ERK12TopoDS_Shapedbdb
Ok, so i found the problem myself. The reason it did not work was not because of CMake, but that there was some other version of the libraries installed over the packet manager, which then got loaded instead of the right one.
purging those libs solved the problem.
However what I still don't get is why it loaded the correct library version on the test project and the wrong on the other (both tested on the same machine)

Link errors when building shared library even though source files are included

I am specifying a shared library build from source files in my CMakeLists.txt file like so:
# Library setup
file(GLOB_RECURSE SOURCES ${CMAKE_CURRENT_SOURCE_DIR}/Source/*.cpp)
file(GLOB_RECURSE HEADERS ${CMAKE_CURRENT_SOURCE_DIR}/Source/*.h)
Inside the source directories contain all my .h and .cpp files required to build my shared library. So I then do something like this:
add_library(mylibrary SHARED ${SOURCES} ${HEADERS} )
I also link a bunch of other .libs with mylibrary later on as well (Could there be a clashing issue?). The problem arises when I try to build mylibrary. I receive linking errors such as:
Severity Code Description Project File Line Suppression State
Error LNK2001 unresolved external symbol __imp_cosf mylibrary ***.obj 1
even though the symbol is defined in my source files that I have included. I am not exactly sure what to do in order to properly let my project find those symbols. The funny thing is is that when I build as a static library it is fine. However, when I try to build as a dynamic library, these errors appear.
So, I'm not exactly sure why this worked. But there was a conflict warning between linking to MSVRCT and libcmt. It said something like this in the output log:
Resolving LNK4098: defaultlib 'MSVCRT' conflicts with ...
This is because libcmt is a static library for release build and uses \MT flags. MSVRCT is a release DLL version and compiled with \MD flag. Because of this conflict, I had to change my compiler flags to be:
set(CMAKE_CXX_FLAGS_RELEASE "${CMAKE_CXX_FLAGS_RELEASE} /MT")
set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} /MTd")
Then the symbols were able to be found. If anyone has any comments/corrections to why this worked please add.

issue when building module using cmake

i am trying to build box2D using cmake. When i click configure (and selecting my version of visual studio) cmake starts working but it finnishes with the error message:
You have called ADD_LIBRARY for library glfw without any source files.
This typically indicates a problem with your CMakeLists.txt file
Configuring done
What is the issue and how can i solve it? Where is the CMakeLists.txt located and how can i edit it to build without errors?
It is probably an error in this library. Try another version or post a bug.
It means that according to this file, a library should be created without source files (an empty library), which is probably bug.
CMakeLists.txt is located in every cmake source directory, make sure you're choosing the right directory.

error LNK1104 cannot open file 'gtest.lib'

I was trying to install a neural networks toolbox called CarlSim using visual studio 2012, in which they use gtest in their code. I try to install gtest by downloading it online and build using gtest.sln file. It gives me two warnings. I guess these two warnings are the reason for this error. But I don't know how to solve this. The gtest seems only can build gtestd.lib.
Below is the error during install of the neural network toolbox
Error 2 error LNK1104: cannot open file 'gtest.lib' C:\Users\Dukerama\Desktop\CarlSim\carlsim\test\LINK carlsim_tests
Below are the warnings of the gest.
1>------ Rebuild All started: Project: gtest, Configuration: Debug Win32 ------
1> gtest-all.cc
1>C:\Program Files(x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.CppBuild.targets(1299,5): warning MSB8012: TargetPath(C:\Users\Dukerama\Desktop\gtest\gtest- 1.6.0\msvc\gtest/Debug\gtest.lib) does not match the Library's OutputFile property value (C:\Users\Dukerama\Desktop\gtest\gtest-1.6.0\msvc\gtest\Debug\gtestd.lib). This may cause your project to build incorrectly. To correct this, please make sure that $(OutDir), $(TargetName) and $(TargetExt) property values match the value specified in %(Lib.OutputFile).
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.CppBuild.targets(1301,5): warning MSB8012: TargetName(gtest) does not match the Library's OutputFile property value (gtestd). This may cause your project to build incorrectly. To correct this, please make sure that $(OutDir), $(TargetName) and $(TargetExt) property values match the value specified in %(Lib.OutputFile).
1> gtest.vcxproj -> C:\Users\Dukerama\Desktop\gtest\gtest-1.6.0\msvc\gtest/Debug\gtest.lib
========== Rebuild All: 1 succeeded, 0 failed, 0 skipped ==========
Output from build command in VS you have posted suggests that there are inconsistencies between certain values in VS project properties for gtest (located in 'Configuration Properties -> General' and in 'Configuration Properties -> Librarian -> General'). However, output also suggests that the gtest library is built at location:
C:\Users\Dukerama\Desktop\gtest\gtest-1.6.0\msvc\gtest/Debug\gtest.lib
You should take this file and place it in directory where CarlSim toolbox expects to find the gtest library. You can find this out in the VS project properties for CarlSim ('Configuration Properties -> Linker -> General -> AdditionalLibraryDirectories').
P.S.
Make sure that both gtest and CarlSim link to the same runtime library, or you'll get more linker errors. You can inspect the runtime library in their VS project properties at 'Configuration Properties -> C/C++ -> Code Generation -> Runtime Library'.
I had the same problem.
Unfortunately, the proposed solution didn't help me.
In my case, the build worked properly on my PC, but it gave the error on a collegue's PC.
We solved it moving the project in a new location with a shorter path.