I am trying to check what zlib version is used for an specific version of openjdk 11 but I can't find it anywhere.
I was googling it but can't find it anywhere. I can just find some tickets in which it's informed that it has been updated.
The code is here:
https://github.com/openjdk/jdk11u/tree/master/src/java.base/share/native/libzip
and current version should be 1.2.11
Related
Following this post, where I have used these instructions to install NVIDIA's OpenCL SDK. The clinfo tool detects a 1.2 OpenCL version correctly. However, The below CMakeLists.txt file:
cmake_minimum_required(VERSION 3.1)
project(OpenCL_Example)
find_package(OpenCL REQUIRED)
include_directories(${OpenCL_INCLUDE_DIRS})
link_directories(${OpenCL_LIBRARY})
add_executable(main main.c)
target_include_directories(main PUBLIC ${CMAKE_CURRENT_SOURCE_DIR})
target_link_libraries(main ${OpenCL_LIBRARY})
copied from here, detects the wrong version of OpenCL 1.1 :
-- Looking for CL_VERSION_1_1 - found
-- Found OpenCL: C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v3.2/lib/Win32/OpenCL.lib (found version "1.1")
I would appreciate it if you could help me know what is the problem and how I can resolve it.
P.S.1. you may use the below dummy main.c C code just for testing
#include <CL/cl.h>
#include <stdio.h>
int main() {
printf("Hello, World! \n");
return 0;
}
P.S.2. Following this Tweet, I ran the cmake .. --debug-find command and got this log. But still not sure what is the problem.
P.S.3. Following this Tweet, it turns out that I had installed a very outdated CUDA toolkit. Uninstalling that, now I get
-- Found OpenCL: C:/Program Files (x86)/IntelSWTools/system_studio_2020/OpenCL/sdk/lib/x86/OpenCL.lib (found version "2.2")
which is Intel's SDK. It was basically the second result on Google search " NVIDIA OpenCL SDK download", firstly being completely confusing. So I had to uninstall it and install the latest version from here. NVIDIA could at least mention that one has to install CUDA toolkit to get the OpenCL SDK!
NVidia Cuda v3.2 was released according to this on Nov 2010 and OpenCL 1.2 spec was released one year later on November 15, 2011. So I suspect cmake is detecting OpenCL 1.1 correctly.
If you have another SDK installed and you want cmake to detect OpenCL 1.2 despite having another SDKs supporting older version you need to specify that information in cmake. Otherwise it will find the first OpenCL on the search path and stop. So it should be specified find_package(OpenCL 1.2 REQUIRED) or as #squareskittles pointed find_package(OpenCL 1.2 EXACT REQUIRED) if you want exact version.
However you may need to add other SDKs paths to PATH or specify them in cmake so that it has a chance to examine other OpenCL versions. If you have a look at find cmake macros content they contain some typical search paths specified and if you have SDK installed in other not standard path you have to tell that cmake yourself. That is especially the case on Windows where you don't have standard more specific install paths for includes or libraries like for example on Linux. On Windows there is really Program Files but that is too generic and cmake would have to search through it recursively and I'm not sure if that is even supported.
I suspect you may have nvidia cuda 3.2 toolkit path added to PATH only or you specified that path in cmake only. So here would the problem lie. Adding other SDKs paths may resolve the issue.
Also I think clinfo checks runtime OpenCL installations meaning it can be any vendor OpenCL.dll which supports OpenCL 1.2 on your NVidia GPU and cmake checks in SDK's header which OpenCL version your installed SDK supports. So here can be the discrepancy. In this case you may need to install newer cuda toolkit.
I am using 32Bit Ubuntu 14.04, where newest version of libc6 is already installed. When I run 'poky-qemu qemuppc zImage-2.6.37-qemuppc-1.0.bin yocto-image-lsb-sdk-qemuppc-1.0.rootfs.ext3', I am getting following error:
/opt/poky/1.0/sysroots/i686-pokysdk-linux/usr/bin/qemu-system-ppc: /opt/poky/1.0/sysroots/i686-pokysdk-linux/lib/libc.so.6: version `GLIBC_2.17' not found (required by /usr/lib/i386-linux-gnu/libdrm.so.2)
Is this problem in toolchain or my host machine? How to solve this error?
Thanks for your time!
Unknowingly, I had used wrong/old version of kernel image and filesystem image. Using latest version which is 1.8, solved the problem.
I need to use the GCC compiler version 4.1.1 on Windows, from a MingGW distribution if possible.
I've been looking for a way to install an older version with the mingw-get installer but I don't find any option to select a specific version. Nevertheless, the official Sourceforge repository doesn't seem to contain the files for this version (http://sourceforge.net/projects/mingw/files/MinGW/Base/gcc/Version4/)
After searching in alternative distributions like Nuwen or TDM-GCC I haven't found a release including GCC 4.1.1.
My question is, is there any place to obtain a MinGW with GCC 4.1.1, or is there another way to obtain this toolchain?
Thanks.
I've compiled a C program under Ubuntu 12.04, built a Debian package out of it, and want to install it on a server running Debian Lenny.
Last time I did that (about two months ago) it worked: I could install the package and run the binary. But now I get the following error message:
(binary's name): /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by (binary's name))
Other than upgrading my machine to Ubuntu 12.4, the only significant change we've brought to the code is a call to strdup(), for which I had to enable the _POSIX_C_SOURCE=200809L feature test macro.
Upgrading the server to the latest Debian version is not my preferred option as it is not under my direct control.
How do I fix this problem?
I think the critical bit of info here is 'upgrading my machine'. So when this worked before, you were building and packaging on something earlier than 12.04? If so, then the issue is that 12.04 now ships with a newer version of libc (apparently 2.14), and your binary now records a dependency on that version of libc. When you try to run on Lenny, which likely uses an older version of libc, the linker detects that the Lenny version does not support the 2.14 API, and fails.
I think the best way forward is probably to do your development and testing on 12.04, and then when you want to create packages for a specific Debian release, use pbuilder or similar to create debs. This will ensure that the libraries used for the packaging build match the target platform.
This is kind of an ugly one, but I am stuck so here it goes:
I am writing a dynamic library (henceforth 'mylib.dylib') that uses opencv (highgui and other parts) and is ultimately loaded by ffmpeg (libavfilter). The library compiles just fine. But when I try to dlopen() the dylib from within ffmpeg, I get the following error:
mylib.dylib: dlopen(mylib.dylib, 2): Library not loaded: /usr/local/lib/libpng15.15.dylib
Referenced from: /usr/local/lib/libopencv_highgui.2.3.dylib
Reason: Incompatible library version: libopencv_highgui.2.3.dylib requires version 17.0.0 or later, but libpng15.15.dylib provides version 16.0.0
However, when I run otool -L /usr/local/lib/libpng15.15.dylib I get the following:
/usr/local/lib/libpng15.15.dylib:
/usr/local/lib/libpng15.15.dylib (compatibility version 20.0.0, current version 20.0.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.0.0)
Last time I checked, 20.0.0 is later than 17.0.0, which is what highgui said it requires.
I thought maybe it was an architecture problem (I am on a Mac running Lion, so I've encountered a lot of problems with i386/x86_64), but running 'file' on all of the libraries revealed that everything (highgui, libpng, mylib) is Mach-O 64-bit dynamically linked shared library x86_64
I thought perhaps there was some other version of libpng hiding on my system somewhere, but the dlopen error specifically points to /usr/local/lib/libpng15.15.dylib
There is obviously something that I am missing here -- admittedly I am no expert on how these dynamic libraries link. So if I forgot to include some pertinent info, please excuse me.
UPDATE
I forgot to mention -- the lib works fine when I run ffmpeg through XCode (no dlopen error) which leads me to believe that it might have something to do with a environment variable that XCode is setting that I am not.
Thanks!
SOLUTION
1. Don't be dumb
I was using MAMP and since I was calling ffmpeg through a php script, it was using its own set of dylibs, which (surprise surprise) included libpng 16.0.0
I had something similar recently after I uninstalled all my MacPorts and installed updated versions. The problem was the version of libpng (1.2 vs 1.4 vs 1.5), not just the compatibility version. I had built OpenCV against libpng 1.4 (which is libpng14). I thought I could just use install_name_tool to make it look at libpng 1.5 (libpng15) instead but that didn't work. I ended up rebuilding OpenCV against the current versions of the library. That worked fine (after I remembered sudo cmake install).
(Some version numbers above might be incorrect but the gist is accurate.)
So either you don't have the version of libpng you originally had when you built OpenCV or it built against a libpng other than the one in /usr/local/lib (like maybe the one in /opt/local/lib). If that's the case you'll need to make sure you're building against the version you want to use. How to do that depends on your build method (MacPorts or cmake). I use cmake for OpenCV and MacPorts for other libraries which is why the two got out of sync on my system.
Just for those who need the code:
cd /Applications/MAMP/Library/lib
mv libpng15.15.dylib libpng15.15.dylib_old
ln -s /usr/X11/lib/libpng15.15.dylib .