I have magic error with running fork of Caffe and Protobuf library version of 2.5.0.
[libprotobuf FATAL google/protobuf/stubs/common.cc:72] This program was compiled against version 2.4.1 of the Protocol Buffer runtime library, which is not compatible with the installed version (2.5.0). Contact the program author for an update. If you compiled the program yourself, make sure that your headers are from the same version of Protocol Buffers as your link-time library. (Version verification failed in "/Users/teamcity/buildAgent/work/fb4f05c74a361f59/External/common/ext/mapkit/routing/protobuf/RouterProtoFormat.pb.cc".)
The magic is that is no RouterProtoFormat.pb.cc anywhere on my computer. Google didn't know anything about this file.
Here make file I used for build protobuf library. Any advice?
Edit
I decide include sources directly to project(without precompiled *.a library) and now I have another error:
libprotobuf FATAL /Users/teamcity/buildAgent/work/fb4f05c74a361f59/External/lib/google/protobuf/stubs/common.cc:61] This program requires version 2.5.0 of the Protocol Buffer runtime library, but the installed version is 2.4.1. Please update your library. If you compiled the program yourself, make sure that your headers are from the same version of Protocol Buffers as your link-time library. (Version verification failed in "project_dir/sources/caffe/src/caffe/proto/caffe.pb.cc".)
I setup debug breakpoint and seams that code executes in some hidden library. I can't get location of this library. I delete all libprotobuf.a files from computer and I still do not know witch file is executes..
Edit 2 (Solved)
There is only one solution I found. I rename everywhere google namespace to google2, and now seams all working fine.
Related
I have a project which depends on Triton library which have prebuilt binaries using Protobuf of some version. I also have GRPC dependency which depends on system wide installed Protobuf of more recent version. When I built my program with these 2 dependencies, building system(meson in my case) picks up includes one or the other protobuf version and throws a lot of errors, because they are not compatible :
error: #error This file was generated by an older version of protoc which is incompatible with your Protocol Buffer headers. Please regenerate this file with a newer version of protoc.
and following a lot of API incompatibility errors.
I think I can rebuild either project using one protobuf version and all be ok. But it will require rebuilding either Triton package, or installing specific version of protoc to my system.
Is there a way for building system to handle this case?(Meson or Cmake)
I recently had the need to pull in the Boost Graph Library for one of the native node modules that I work on, along with boost serialization. There is a separate VS project that I do all of my development and testing for this module. The project compiles, links, and works as expected when run from the VS project.
I am having issues when I try to link the static serialization library with my module when building with node-gyp. I have included the full path to the serialization library in the libraries section of the binding.gyp file. In the object file produced from the node-gyp compiled file, the following line is causing a linker failure:
/FAILIFMISMATCH:"_CRT_STDIO_ISO_WIDE_SPECIFIERS=0"^#^Dlibboost_serialization-vc140-mt-s-x64-1_67.lib^#^Dlibboost_serialization-vc140-mt-s-x64-1_67.lib^#^Duuid.lib^#^Duuid.lib^#
The object file is expecting libboost_serialization-vc140-mt-s-x64-1_67.lib. When the build process tries to link the file, the linker spits out an error:
LINK : fatal error LNK1104: cannot open file 'libboost_serialization-vc140-mt-s-x64-1_67.lib'
However, boost built libboost_serialization-vc141-mt-s-x64-1_67.lib which is a different version than what the object file is expecting. I have tried to build the version that the object file is looking for, but I cannot seem to get boost to do so (each time I try, it skips all of the targets, even though I am specifying an alternative toolset).
How can I change the library version that the object file is expecting?
When I tried to build the "right" version of the serialization library, I had been using toolset=msvc-140. It should have been toolset=msvc-14.0. Sometimes I am dumb.
I am trying to write a program that uses armadillo in Visual Studio. I downloaded Prebuilt libraries for lapack and blas from http://icl.cs.utk.edu/lapack-for-windows/lapack/. I also downloaded MinGW and added C:/MinGW/bin to my System PATH. C:/MinGW/bin has libgfortran-3.dll and libgcc_s_dw2-1.dll which are what the lapack documentation states is needed. However, when I attempt to run my program I get a runtime error stating that the program can't run because libgcc_s_sjlj-1.dll is missing. This dll does not come with MinGW and I tried downloading multiple versions. How can I get rid of this error?
The MinGW-w64 project have something called "personal builds". One of them is "sjlj". The library is built using a gcc compiler from this personal build.
Assuming that it was used the current latest version (6.3.0) and win32 threads the you can find the toolchain binaries here. If not, you can check some other versions.
You can either extract the dll you need or extract it and add it to your system path.
I use find_package(HDF5 COMPONENTS CXX REQUIRED) in my CMAKE script to load the include directories and libraries of HDF5. Cmake tells me
Found HDF5: C:/Program Files/HDF_Group/HDF5/1.10.0/bin/hdf5_cpp.dll (found version "1.10.0") found components: CXX
And generates my visual studio solution.
I also use the library stored in ${HDF5_LIBRARIES} ${HDF5_CXX_LIBRARIES} for my target, but when I try to build it, I get a Linker Error LNK1107 saying that for file hdf5_cpp.dll:
invalid or corrupt file: cannot read at 0x380
which I think is due to the fact that visual studio is trying to directly link against the dll file instead of against the lib file which is in another folder, namely in:
C:\Program Files\HDF_Group\HDF5\1.10.0\lib
Question: Is this a bug in FindHDF or did I configure something wrong?
I have not used hdf5 on windows for some time, but I do recall there being a bug that causes it to link against the dll instead of the lib.
you should manually set (either via the command line cmake -D method, or via the cmake gui)
HDF5_hdf5_LIBRARY=C:\Program Files\HDF_Group\HDF5\1.10.0\lib\libhdf5.lib
HDF5_hdf5_cpp_LIBRARY=C:\Program Files\HDF_Group\HDF5\1.10.0\lib\libhdf5_cpp.lib
etc. - or just
HDF5_LIBRARY=C:\Program Files\HDF_Group\HDF5\1.10.0\lib\libhdf5.lib
HDF5_cpp_LIBRARY=C:\Program Files\HDF_Group\HDF5\1.10.0\lib\libhdf5_cpp.lib
depending on whether you have an older or newer version of FindHDF5 (they change the library var names in newer versions - check the ones used to make sure you get them right - I'm doing this from memory so might have made a mistake)
EDIT:
If the option of manaully specifying the libs is a problem, then there is the option of using FindPackage(HDF5 NO_MODULE) if your hdf5 library was compiled using cmake generated makefilesetc.
When using NO_MODULE, the find package scripts will bypass the findhdf5.cmake script and look for the HDF5Config.cmake or hdf5-config.cmake file that is placed in the relevant subdir of the hdf5 build/install folfer.
This is cross platform friendly and is supported by all newer hdf5 versions - provided they were built using cmake and not ./configure ...
I have a project I'm writing that uses LuaJIT. I'm trying to run my project on a computer I have not run it on in a while. It used to run just fine but now when I try to run it it complains.
I have LuaJIT in my source tree, and it builds just fine. I'm using CMake to generate my make files, and as far as I can tell CMake finds the file libluajit.so, but when I run my program, I get the following error:
../build/game/game: error while loading shared libraries: libluajit-5.1.so.2: cannot open shared object file: No such file or directory
I don't know why it's looking for that version of the library instead of libluajit.so. This is Ubuntu linux for what it's worth. I can add more details if necessary, I can add more details if necessary, I'm not sure what info would be helpful to figure out happening.
Edit:
To build and link the program I have these lines in the file CMakeLists.txt (this is abbreviated a bit to just show the relevant bits)
find_package(LuaJIT REQUIRED)
set(Extern_LIBS luajit)
add_executable(proj ${proj_Sources})
target_link_libraries(proj ${Extern_LIBS})
After I run cmake on my source directory, I run make. Then to run it I just run ./proj
When you built it, the ".so" was actually a symlink to the library. Verisioned filenames and SONAMEs are used so that multiple versions of a library can coexist, preventing problems commonly found on... other operating systems whereby older software is incompatible with the newer library, and newer software is incompatible with the older library.