Perforce sync clobber writable error


I was trying to sync a Perforce client and got this error:

$ p4 sync
Can't clobber writable file: /home/joe/p4_workspace/foobar.txt


Perforce keeps its files read-only until they are opened for editing. I had for some reason made this file writeable and Perforce was complaining about that with this error message.

The error was fixed and the sync worked once I made the file read-only:

$ chmod -w /home/joe/p4_workspace/foobar.txt

Perforce sync write permission error


I tried to sync a Perforce client and got this error:

$ p4 sync
open for write: /home/joe/p4_workspace/foobar/tmp.30935.46: Permission denied

The strange thing is that there is no tmp.30935.46 in this repository!


Turns out that Perforce writes some temporary files to subdirectories during the sync operation. This error indicates that it is failing in this write because the directory does not have write permissions.

The error went away and the sync worked once I added write permissions to that directory:

$ chmod +w /home/joe/p4_workspace/foobar

OpenCV CMake package version error


I was compiling OpenCV using CMake and it threw up this error:

CMake Warning at cmake/OpenCVPackaging.cmake:23 (message):
  CPACK_PACKAGE_VERSION does not match version provided by version.hpp
Call Stack (most recent call first):
  CMakeLists.txt:1105 (include)


Open cmake/OpenCVPackaging.cmake file and add the version of OpenCV using a line set(OPENCV_VCSVERSION "2.4.13"). Place the line anywhere above the first use of OPENCV_VCSVERSION.

OpenCV CUDA CMake error


I was building OpenCV using CMake and got this error:

CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:


The error was related to CUDA and probably some dependency on the NVIDIA Performance Primitives (NPP) library. Since, I needed neither, I rebuilt OpenCV without CUDA support as described here by setting WITH_CUDA=OFF.

OpenCV IlmImf linker error


I had compiled OpenCV and when I linked my application with OpenCV libraries, I got this error:

undefined reference to `Imf_2_2::globalThreadCount()'


The Imf in the symbol above seems to be from the IlmImf library that is used to read and write OpenEXR images. Since I had no need for OpenEXR, I recompiled OpenCV with the setting WITH_OPENEXR=OFF. Linking with the resulting OpenCV libraries worked fine.

Current working directory Poco error


I was trying to build the Poco library when I got this error:

/home/blah/someplace/poco-poco-1.4.6p4-release/build/rules/global:62: *** Current working directory not under $PROJECT_BASE.  Stop.
make[1]: Leaving directory

The same code had built successfully on another computer, so I knew there was nothing wrong.


Turns out that this error is actually caused if the path where you have unzipped Poco has a symlink in it. The someplace directory above was actually a symbolic link. Once I copied Poco to a path which had no symlink, it compiled fine.

Unrecognized relocation error


Building a large project that involved linking with many libraries, I got this linking error:

Linking CXX shared library ../../lib/
/usr/bin/ld: /somepath/opencv-2.4/lib/libopencv_imgproc.a(clahe.cpp.o): unrecognized relocation (0x2a) in section `.text._ZN12_GLOBAL__N_1L15CLAHE_Impl_infoEv'
/usr/bin/ld: final link failed: Bad value


At first I suspected some problem with the symbol that you see the linker complaining about above. But using nm I found that the symbol was present and was defined in the archive library file.

Only after eliminating all other possibilities did I discover that the problem was the compiler version. The archive library file had been compiled using GCC 4.8. The linking was being done on a different computer where the compiler was GCC 5.x. The C++ ABI had changed along with the major version difference between the two compilers and this was causing the problem.

Once I rebuilt OpenCV with GCC 5.x and used its archive library file, the linking proceeded smoothly.

NVCC argument redefinition error


I was trying to build a CUDA project that worked on one computer on a second computer. Though this project built without problems on the first computer, nvcc gave an argument redefinition error on the second computer:

nvcc fatal   : redefinition of argument 'std'


At first, I thought that the compilation error was arising from the source code. Actually, the error is being reported about a compilation argument to nvcc. It is saying that a std argument has been provided more than once.

This project was using CMake, so the actual compilation commands invoked by make are hidden. I used the VERBOSE trick, described here, to view the actual commands issued to the C++ and CUDA compilers. Not surprisingly, I found that the -std=c++11 argument was being passed twice. But why?

I checked the CMakeLists.txt file and found that indeed the C++11 argument was being passed to the compiler twice by setting it in both CMAKE_CXX_FLAGS and CUDA_NVCC_FLAGS. How and why was this working fine on the first computer? Turns out that the older CMake used on the first computer would not pass the C++ flag to NVCC, so it had to be specifically redefined for CUDA compiler flags.

The second computer was using a newer version of Ubuntu, with newer version of CMake. This was intelligent enough to pass a C++ flag to the CUDA NVCC compiler too. But since the NVCC flag of the same name also existed, it was causing the argument redefinition error. Removing the flag from the CUDA flags made the problem go away.

urlopen got multiple values error


I tried to run a Python script given by a friend. It ended with this error:

  File "/usr/lib/python2.7/dist-packages/urllib3/", line 79, in request
  File "/usr/lib/python2.7/dist-packages/urllib3/", line 142, in request_encode_body
TypeError: urlopen() got multiple values for keyword argument 'body'


The script used a Python package, which in turn used urllib3. This strange error has nothing to do with my code, but with the urllib3 package. The urllib3 package installed by Ubuntu was pretty old: 1.7.1. Updating to a more recent version of the package will fix the error. Either upgrade using sudo pip install urllib3 for system-wide update or update inside your virtualenv.