I'm trying to build cpp-netlib 0.12.0 stable in Ubuntu 18.04, but when I get to running
$ make -j4
I get a lot of errors, such as:
error: ‘SSL_R_SHORT_READ’ was not declared in this scope
ERR_PACK(ERR_LIB_SSL, 0, SSL_R_SHORT_READ)
Google told me this was because the make variables -DOPENSSL_INCLUDE_DIR and -DOPENSSL_SSL_LIBRARY need to be defined. However, I can't find the directories/libraries I need to set them to. Examples give /usr/lib/openssl-1.0 and /usr/include/openssl-1.0, but I can't find anything like those, even though I have the latest version of openssl installed through apt-get.
My /usr/include directory contains the folder 'openssl', but usr/lib doesn't have even that, only 'openssh', which doesn't appear to contain anything relevant.
How can I fix this?
Fixed by cloning latest version from git repository and building from that.
Related
I have a project that uses arrow and parquet. I downloaded and built the required libraries, and then successfully built my library. Now I want to migrate it to use conan, to simplify the build process.
The problem I'm facing is that most if not all the prebuilt binaries of arrow don't include parquet, at least for Windows.
This probably means that conan would download the recipe and build it. However, once I add parquet to my conanfile.txt, I get errors
Here's my conanfile.txt
[requires]
arrow/2.0.0
rapidjson/cci.20200410
catch2/2.13.6
[generators]
cmake
[options]
arrow:shared=False
arrow:parquet=True
These are the errors I get when I use conan install
>conan install ..
Configuration:
[settings]
arch=x86_64
arch_build=x86_64
build_type=Release
compiler=Visual Studio
compiler.runtime=MD
compiler.version=14
os=Windows
os_build=Windows
[options]
[build_requires]
[env]
WARN: thrift/0.13.0: requirement boost/1.76.0 overridden by arrow/2.0.0 to boost/1.74.0
WARN: libevent/2.1.12: requirement openssl/1.1.1j overridden by thrift/0.13.0 to openssl/1.1.1k
ERROR: Permission denied for user: 'None'. [Remote: bincrafters:]
From the error, I'm assuming that the recipe has some version conflicts and can't continue, and that I need to do something like Using override, but I don't know how to effectively do this.
Other answers, including one in a very similar question assume that updating conan to the latest would fix this, but I already updated to version 1.38, to no avail.
Any hints?
EDIT 1:
First thing I found is that my remotes.json is outdated, pointing to bincrafters. This may indeed be the thing that is breaking my build. I'll post what I found later
First thing I found is that my remotes.json is outdated, pointing to bincrafters. This may indeed be the thing that is breaking my build. I'll post what I found later
Yes, you are right. This information and action was shared here: https://bincrafters.github.io/2020/04/19/infrastructure-changes-and-required-actions/
From the error, I'm assuming that the recipe has some version conflicts and can't continue, and that I need to do something like Using override, but I don't know how to effectively do this.
As all recipes are updated manually, so version conflicts occur from time to time. The correct fix for your problem is documented here: https://docs.conan.io/en/latest/faq/troubleshooting.html#error-incompatible-requirements-obtained-in-different-evaluations-of-requirements
Besides that, you can open an issue requesting for version update here: https://github.com/conan-io/conan-center-index/issues
I thought I'd document my findings since the information was not easy to come by:
First,
ERROR: Permission denied for user: 'None'. [Remote: bincrafters:]
This signaled that the remotes.json has a bad configuration. bincrafters is no longer around, but conan does a full stop if can't reach one of the remotes (the configuration was created by someone else a few years ago, and it is custom because it points also to company repositories).
Second:
Once the first error was cleared, the second answer was somewhat obvious:
I updated my conanfile.txt to force my recipe to use the latest boost and openssl (and therefore bypass the version conflict)
[requires]
arrow/2.0.0
rapidjson/cci.20200410
catch2/2.13.6
boost/1.76.0
openssl/1.1.1k
[generators]
cmake
[options]
arrow:shared=False
arrow:parquet=True
arrow:with_snappy=True
and then proceeded to install the conan dependencies, building the missing one:
conan install .. --build=arrow
I have been trying to build the desktop client for about a week now so that I can dig in and try to mess with some theming and turn off some features I wont be needing. In the process I have run into numerous issues and have managed to resolve them in one way or another. I have a VM running openSUSE and I have downloaded the source file ownCloudClient-2.3.2.tar.xz file and unzipped it all into my home/jwarren/client folder. I then ran:
cd admin/win/docker
docker build . -t owncloud-client-win32:
Which I was able to get through. Now I am on the second command:
docker run -v "$PWD:/home/user/client" owncloud-client-win32: \
/home/user/client/admin/win/docker/build.sh client/ $(id -u)
Here I am getting almost to the end and then I receive this error message which I cant figure out how to resolve.
CPack Error: Problem running NSIS command "user/bin/makensis"
CPack Error: Problem Compressing Directory
Can anyone help me out with this? Or maybe point me in the direction of better instructions for the ownCloud Desktop Client theming. I noticed that once you get it installed properly there is no instructions explaining where anything is to edit.
I wrote a comprehensive guide to build the Windows client using the cross-compilation toolchain in the Dockerfile some time ago in ownCloud's central: https://central.owncloud.org/t/error-using-docker-to-build-the-windows-client/5107/5
What you're probably missing out is the git-submodule initialization; i.e. running git submodule update --init on your unzipped repository. You need these to bundle on the installer some pre-compiled binaries used by the shell integrations.
Also, on a side note, there was some problems last month with mingw toolchain compiler (gcc7) - in case you get some dll error after installing the client with your self-generated installer, refer to https://central.owncloud.org/t/building-the-windows-installer/8403/4 for an snapshot of a fully working Docker image to use instead of your self-built.
About the docs to build your own theme: those can be found in https://doc.owncloud.org/branded_clients/branded_desktop_client/index.html (for enterprise installations of ownCloud) - and for an unsupported version, you can also check the source in
https://github.com/owncloud/client/blob/master/src/libsync/theme.cpp for some hints about what settings can be overwritten from there.
I'm trying to compile caffe using cmake on a Linux machine. I get this complaint when running cmake:
Could NOT find PythonLibs (missing: PYTHON_LIBRARIES PYTHON_INCLUDE_DIRS) (Required is at least version "2.7")
I later get this error
CMake Error at CMakeLists.txt:85 (add_dependencies):
The dependency target "pycaffe" of target "pytest" does not exist.
What am I doing wrong? I tried setting an environment variable for PYTHON_LIBRARIES but that didn't help. I'm using my locally installed version of python (2.7.13), so I think that might be causing the problem, but I don't know how to get past this.
I was able to "fix it" by editing the file build/CMakeCache.txt and manually setting these
PYTHON_INCLUDE_DIR
PYTHON_LIBRARY
I don't know if that's the correct way to resolve this. If not, what is the right way to resolve this?
I had the same error while installing caffe on Ubuntu 14.04; I solved this by installing boost-python:
sudo apt-get install libboost-python-dev
Check carefully through the installation instructions. There's a variety of dependencies to install (python-devel, glog-devel, ...) and some environment variables to set. Using a local Python installation isn't a problem, as long as you have that properly in your paths. Remember to check your PATH and LD_LIBRARY_PATH variables as well.
You might check with
env | egrep -i "py"
to see what variables do have Python references. If you suspect a version problem with an executable, use
ldd <executable>
To see what objects and versions get loaded. Among other things, it's vaguely possible that something got compiled against an older Python in the system directories.
You need to install numpy
Try pip install numpy
I've now been trying to get MinGW-w64 to work on my system for several days, mainly because it has a more recent GCC version, but I either set things up wrong or there's some strange problem with MinGW-w64 itself.
I've now downloaded i686-w64-mingw32-gcc-4.7.2-release-win32_rubenvb, unpacked it to C:/Dev/mingw-ruben and added the path C:/Dev/mingw-ruben/bin to the $PATH environment variable.
What I'm trying to build is SFML 2 which comes with a CMake file. Running CMake will work just fine, the compiler gets recognized and passes all test. CMake also finds the ar.exe in the C:/Dev/mingw-ruben/binfolder. After generating the MinGW Makefile I switch to the windows command line and run mingw32-make install.
There's where the problem happens, I get the error:
mingw-ruben\bin\ar.exe: mingw-ruben/lib/libopengl32.a: No such file or directory
Or for the network library
mingw-ruben\bin\ar.exe: mingw-ruben/lib/libws2_32.a: No such file or directory
The error seems quite obvious and on check there really is no libopengl32.a or libws2_32.a in mingw-ruben/lib/, but the files is actually located in C:/Dev/mingw-ruben/i686-w64-mingw32/lib.
Now How can I tell ar/make/cmake to not only search in the mingw-ruben/lib directory but also in the mingw-ruben/i686-w64-mingw32/lib?
Would it be a good idea to copy all the content from the i686-w64-mingw32 subfolder to the mingw-ruben root folder?
As a side note: I can call mingw32-make install again and the procedure will continue but up on trying to link my application against SFML, I run into many unresolved symbol errors for the glXYZ functions from within SFML.
Further information: I'm on Windows 8 x64, but I think that doesn't really matter and yes I've tried MSYS but it doesn't resolve any of my issues.
Am I doing something wrong? Do I have to configure things specially?
January 2015 Edit
Now that SFML 2.2 has been released, this is no longer an issue and you have to link SFML's dependencies yourself when linking static.
January 2014 Edit
As of commit 165f2b1888 and f784fe4c07, which is included in the stable version SFML 2.1, MinGW-w64 compilers are supported.
However while discussing further with different parties it came to light, that the sfml_static_add_libraries marco a rather ugly hack was. In short it unpacked the static dependencies and included their obj files into the SFML library itself. This was most noticeable an issue, when trying to use your own version of GLEW, which failed since SFML was using its internal one already. The issue was brought to the forum and was pushed around for quite a bit, until Laurent finally gave in and went with the proper way of linking dependencies, which means you have to link them now on your own.
As of commit dbf01a775b, which is not included in the stable version of SFML 2.1, one has to link the SFML dependencies in the finally application, when linking statically against SFML.
Original
After some chat on the IRC we've figured it out.
It has nothing to do with MinGW but it's all SFML's fault. To reduce the dependencies list for SFML while linking statically the developer decided to manually extract the symbols from each library (opengl32, ws2_32, ...) which obviously isn't how one does things and violates some ODR rules. The actual error then occurs because the developer assumed that the library will be in the folder mingw/libbut with MinGW w64 it's located in a seperate directory mingw/version/lib and so ar.exe didn't find the library.
Solution
Removing the call to the sfml_static_add_libraries macro and then recompile. Afterwards you'll have to link all the dependencies for static linkages, like it should be.
I think it may be well a problem of the gcc distribution you downloaded.
A bit of light into the problem gives ruben's question here:
https://unix.stackexchange.com/questions/45277/executing-binary-file-file-not-found
that seems to me related to that (although it is about linux and not win)
I was having a similar problem (the name of the missing file was different) few months ago with gcc 4.7.0 linux->win crosscompiler. So until now I lived with the standard ubuntu mingw-w64 package and only yesterday I gave another try to i686-w64-mingw32-gcc-4.7.2-release-linux64_rubenvb.tar.xz and it works without issues in otherwise same environment where the previous version was failing with "..ar.exe: ... no such file". Sometimes I develop also in windows, then I use http://www.mingw.org/ that was for me much easier to setup in Win. It supports only 32bit target but for my project it is sufficient.
Well I've recently come out of the dark ages and upgraded my GCC from 3.4.4 to 4.5.0 with Cygwin (I use Netbeans 6.8 on Windows for future reference). I tried testing the new compiler by attempting to run a simple program through it. The run failed however, citing that NetBeans "cannot find -lstdc++".
Interesting.
I look in ...
C:\cygwin\lib\gcc\i686-pc-cygwin\4.5.0
...where libstdc++.a, libstdc++.dll.a, libstdc++.la, libsupc++.a, and libsupc++.la are supposed to be (they're in that spot in the 3.4.4 folder), and they're not there. I also notice something else: there's a 4.3.4 folder in...
C:\cygwin\lib\gcc\i686-pc-cygwin
which contains these exact files! Good. So I copy them in to the 4.5.0 folder and try to run the program again. This time i'm getting two other errors:
build/Debug/Cygwin-Windows/extract_fail_operations.o:/usr/lib/gcc/i686-pc-cygwin/4.5.0/include/c++/bits/stl_list.h:1435: undefined reference to `std::_List_node_base::_M_hook(std::_List_node_base*)'
and:
build/Debug/Cygwin-Windows/extract_fail_operations.o:/usr/lib/gcc/i686-pc-cygwin/4.5.0/include/c++/bits/stl_list.h:1451: undefined reference to `std::_List_node_base::_M_unhook()'
At this point I figured that I was way over my head and decided to come for help before copying and pasting any more files. If anyone could tell me how to get this working, i'd be really appreciative.
(If any solutions involve the command line, please be warned that i'm not well versed in it... you may have to provide extra details that you wouldn't need to to other SO users!)
EDIT: The PATH variables are as follows:
C:\Program Files\SSH Communications Security\SSH Secure Shell;C:\Program Files\CVSNT\;C:\cygwin\bin
And yes, the Cygwin installed is the latest from the site.
You need to install version 4.5.0 of libstdc++6-devel.