Accidentally an incompatible nvml library was added to the library path in a linux environment. In that setup when I try to query nvidia-smi, it gives out the following error
Failed to initialize NVML: Driver/library version mismatch
And when I remove that incompatible library from the library path and query nvidia-smi again, the query runs successfully and the output is displayed as expected.
Yet, when I look into the dependent libraries by entering ldd for nvidia-smi it does not show that the process depends on the nvml library.
$>ldd /usr/bin/nvidia-smi
linux-vdso.so.1 => (0x00007fffa84db000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f58ba044000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f58b9e3f000)
libc.so.6 => /lib64/libc.so.6 (0x00007f58b9a7e000)
librt.so.1 => /lib64/librt.so.1 (0x00007f58b9876000)
/lib64/ld-linux-x86-64.so.2 (0x00007f58ba27d000)
If it does not depend on the nvml library, why does it give out an error when there is an incompatible nvml library?
ldd provides a list of application dependencies on libraries that are dynamically linked to the application.
Presumably this application uses runtime loading of a (shared) library (for example, strace nvidia-smi 2>&1 |grep ml)
When loading a library at runtime, it is not necessary to explicitly link the application against the library, and the library will not show up as a dependency in ldd output (if it is not explicitly linked at application build time).
Related
The instructions to javapackager just above Example 2-1 in the Java SE Deployment Guide/Self-Contained Application Packaging state that a jar file is required in the -deploy command.
If I use a modular jar, I get this error message:
Exception: java.lang.Exception: Error: Modules are not allowed in srcfiles: [dist\tcdmod.jar].
If I use the equivalent non-modular jar, the resulting package includes the complete runtime. But I want to use the reduced runtime I made with jlink that is in the /dist folder.
Can the javapackager command deploy with a jlink-generated runtime?
How?
The section titled "Customization of the JRE" makes no mention of the javapackager command.
The following section "Packaging for Modular Applications" has a following line:
Use the Java Packager tool to package modular applications as well as non-modular applications.
Is the Java Packager tool distinct from javapackager? There are no examples using javapackager in this section.
Here is the javapacker command that I used:
javapackager -deploy -native -outdir packages -outfile ToneCircleDrone -srcdir dist -srcfiles tcdplain.jar -appclass com.adonax.tanpura.TCDLaunch -name "ToneCircleDrone" -title "ToneCircleDrone test"
The instructions in the javapackager documentation make no mention of the scenario where a jlink runtime is used. There is a Bundler argument -Bruntime but it is only used to point to an installed runtime other than the system default, AFAIK.
The javapackager provided with JDK 9 and up uses jlink to generate the jre image:
For self-contained applications, the Java Packager for JDK 9 packages
applications with a JDK 9 runtime image generated by the jlink tool. To
package a JDK 8 or JDK 7 JRE with your application, use the JDK 8 Java
Packager.
https://docs.oracle.com/javase/9/tools/javapackager.htm#JSWOR719
You can even pass arguments to jlink using -BjlinkOptions=<options>
Additionally, -Bruntime is only valid for packages deployed using -deploy -native jnlp
For compiling a modular application, instead of -srcdir, use --module-path <dir>, and then specify the main module using -m <module name>.
EDIT: While there is no documentation on -BjlinkOptions, it is present in the javapackager source
jdk.packager/jdk.packager.internal.legacy.JLinkBundlerHelper
https://github.com/teamfx/openjfx-10-dev-rt/blob/bf971fe212e9bd14b164e4c1058bc307734e11b1/modules/jdk.packager/src/main/java/jdk/packager/internal/legacy/JLinkBundlerHelper.java#L96
Example Usage: -BjlinkOptions=compress=2 will make javapackager run jlink with the --compress=2 flag, generating the JRE image with Zip Level compression.
Aditionally, running javapackager with the flag -Bverbose=true will show you exactly which arguments are being passed to jlink with a line in the output something like this:
userArguments = {strip-debug=1 compress=2}
I am building a project using Opencv 3.1 and wxwidgets 3.1. The code I use:
[wxOpenCv Demo1]
I try to add a write frame object, using the function cv::imwrite().
(I changed the c calls to c++ eg: cvQueryFrame( m_pCapture ) to m_pCapture >> m_CurFrame;)
I get this error:
Undefined symbols for architecture x86_64:
"cv::imwrite(cv::String const&, cv::_InputArray const&,
std::vector > const&)", referenced from:
CCamera::SaveFrame() in camera.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Without wxwidgets the opencv functions work fine. So its seems that it has to do with the combination of wxwidgets and opencv.
This works fine with wxwidgets and Opencv:
cv::imshow("tmp",m_CurFrame);
cv::waitKey(4);
// cv::imwrite(Tmp , m_CurFrame);
If I uncomment the last line, I get the error.
OS X: 10 Yosemite and I use the default compiler (Apple LLVM 7.0)
I have no idea what to do about this!
solved the problem (and more) by recompiling wxwidgets 3.1.0 and Opencv 3.1. I used these links to get it going.
Small guide to compiling wxWidgets, Opencv against C++ 11:
Compile wxwidgets 3.1.0: I followed the install.txt for OSX. And tweaked the ../configure call with help from this
I added: --enable-debug and changed the macosx version
../configure --disable-shared --enable-debug --enable-unicode --with-cocoa --with-macosx-version-min=10.7 --with-macosx-sdk=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk CXXFLAGS="-std=c++0x -stdlib=libc++" CPPFLAGS="-stdlib=libc++" LIBS=-lc++
Then with the help of this page I build a xcode project. Tweaking a few things:
(wxcocoa.xcodeproj and minimal.xcodeproj, and a all new projects)
Add to the Header Search Path: $(WXROOT)/build/osx (to find wx.xcconfig)
base SDK: latest OS X (10.11)
C language dialect: GNU 11(not sure if this is right)
C++ language dialect: GNU++11 [-std=gnu++11]
C++ Standard Library: libc++ (LLVM C++ standard library with C++ 11 support)
placed the WXROOT under “preference->locations->Source Trees. Not important, but seems to be a better location (restart xcode)
in wxcocoa.xcconfig I changed: MACOSX_DEPLOYMENT_TARGET = 10.10
Somehow I have to change the name of the created library from libwx_osx_cocoa_static.a to: lwx_osx_cocoa_static.a (why, I do not know)
I use GNU++ 11 and thus libc++ to be able to use new functionality like “future"
I then added OpenCV to my newly created wxXcode project:
Compile OpenCV following this: (search the web for: howto-install-build-and-use-opencv-macosx-10-10)
Make sure that the SDK is the right version (here was my biggest problem), matching the build of wxWidgets
The compiler settings same as for wxWidgets (see above)
(added:) To do this I added some lines to the CMakeLists.txt in the (Opencv-master folder). Below the line: # OpenCV compiler and linker options
(I found this trick here: search the web for: OpenCV with C++11 on OS X 10.8
message("Setting up Xcode for C++11 with libc++.")
set(CMAKE_XCODE_ATTRIBUTE_CLANG_CXX_LANGUAGE_STANDARD "c++0x")
set(CMAKE_XCODE_ATTRIBUTE_CLANG_CXX_LIBRARY "libc++")
Then follow this page to update the newly created wxWidgets xcode project (search the web for: howto-setup-xcode-6-1-to-work-with-opencv-libraries)
This should do the trick! I can now combine wxWidgets, OpenCV and the libc++
(multithreading, “future")
I hope this helps.
Please let me know if you found out more!
I have a problem starting Kamailio Version 4.3. I installed Kamailio from source, and the modules are stored in the default directory /usr/local/lib64/kamailio/modules. I am using the json module that Kamailio provides but it fails to load.
Kamailio's documentation on the json module is found here:
http://www.kamailio.org/docs/modules/3.4.x/modules/json.html
The documentation states that before the module is loaded you need the required library libjson, which I installed. When I start kamailio and cat the log file via kamailio start; cat /var/log/kamailio.log | grep error I am getting the following error:
Jan 8 12:43:53 localhost kamailio: ERROR: <core> [sr_module.c:576]: load_module(): could not open module </usr/local/lib64/kamailio/modules/json.so>: /usr/local/lib64/kamailio/modules/json.so: undefined symbol: is_error
Jan 8 12:43:53 localhost kamailio: : <core> [cfg.y:3432]: yyerror_at(): parse error in config file /usr/local/etc/kamailio/kamailio.cfg, line 109, column 12-20: failed to load module
Line 109 is obviously correct:
loadmodule "json.so"
More information:
ldd json.so
linux-vdso.so.1 => (0x00007ffc33e97000)
libjson-c.so.2 => /lib64/libjson-c.so.2 (0x00007f24d8110000)
libc.so.6 => /lib64/libc.so.6 (0x00007f24d7d7c000)
/lib64/ld-linux-x86-64.so.2 (0x00007f24d8527000)
Has anyone else experienced a similar issue, or does anyone know a solution? It is also worth mentioning I am running kamailio on CentOS 6.7.
is_error(p) should be a macro, look inside your json.h file (perhaps at /usr/include/json-c/json.h) and see if it includes "bits.h" from the same folder. Inside bits.h should be defined the macro is_error().
If you don't have that, maybe it is a customized library.
As a side note, an alternative for json operations in kamailio.cfg is using jansson module.
I try to use the MySQL module from QT but without result, the module is present but Qt does not load it. I have this error
QSqlDatabase: QMYSQL driver not loaded
QSqlDatabase: available drivers: QSQLITE QMYSQL QMYSQL3 QPSQL QPSQL7
QSqlError("", "Driver not loaded", "Driver not loaded")
if I make a ldd libqsqlmysql.so I get this result
linux-vdso.so.1 (0x00007ffe89950000)
libmysqlclient_r.so.16 => not found
libQt5Sql.so.5 => /opt/Qt/5.4/gcc_64/plugins/sqldrivers/./../../lib/libQt5Sql.so.5 (0x00007fdc67aaf000)
libQt5Core.so.5 => /opt/Qt/5.4/gcc_64/plugins/sqldrivers/./../../lib/libQt5Core.so.5 (0x00007fdc67372000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fdc6706b000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fdc66cc2000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fdc66aa4000)
libicui18n.so.53 => /opt/Qt/5.4/gcc_64/plugins/sqldrivers/./../../lib/libicui18n.so.53 (0x00007fdc66658000)
libicuuc.so.53 => /opt/Qt/5.4/gcc_64/plugins/sqldrivers/./../../lib/libicuuc.so.53 (0x00007fdc662cd000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fdc660c8000)
libgthread-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgthread-2.0.so.0 (0x00007fdc65ec6000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fdc65cbe000)
libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007fdc659c5000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fdc656c4000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fdc654ae000)
/lib64/ld-linux-x86-64.so.2 (0x00007fdc67f1c000)
libicudata.so.53 => /opt/Qt/5.4/gcc_64/plugins/sqldrivers/./../../lib/libicudata.so.53 (0x00007fdc63e25000)
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007fdc63be8000)
the problem is I think this line libmysqlclient_r.so.16 => not found
If I make a locate mysqlclient I get this reuslt
/usr/lib/x86_64-linux-gnu/libmysqlclient.so.18
/usr/lib/x86_64-linux-gnu/libmysqlclient.so.18.0.0
/usr/lib/x86_64-linux-gnu/libmysqlclient_r.so.18
/usr/lib/x86_64-linux-gnu/libmysqlclient_r.so.18.0.0
/usr/share/doc/libmysqlclient18
/usr/share/doc/libmysqlclient18/NEWS.Debian.gz
/usr/share/doc/libmysqlclient18/changelog.Debian.gz
/usr/share/doc/libmysqlclient18/changelog.gz
/usr/share/doc/libmysqlclient18/copyright
/var/cache/apt/archives/libmysqlclient18_5.5.43-0+deb7u1_amd64.deb
/var/cache/apt/archives/libmysqlclient18_5.5.44-0+deb7u1_amd64.deb
/var/lib/dpkg/info/libmysqlclient18:amd64.list
/var/lib/dpkg/info/libmysqlclient18:amd64.md5sums
/var/lib/dpkg/info/libmysqlclient18:amd64.postinst
/var/lib/dpkg/info/libmysqlclient18:amd64.postrm
/var/lib/dpkg/info/libmysqlclient18:amd64.shlibs
I read about some forum, the need to make a symbolic link I tried but I always this error
Assuming that for getting this error you installed Qt from the binary packages downloaded from qt.io:
Install the MySQL client dev packages
Run the MaintenanceTool (somewhere where you installed Qt)
Ask it to install extra packages
Install the "Source Components" for at least the Essential modules
Go to /dir/where/you/installed/Qt/version/Source/
Go into qtbase/src/plugins/sqldrivers/mysql
Run qmake from the very same Qt version (/dir/where/you/installed/Qt/version/arch/bin/qmake or similar)
Run make, if it explodes with headers/libraries not found check that you installed those MySQL client dev packages correctly
That should give you a brand new plugin, and with fingers crossed, it's already put in the right place. Otherwise find the new libqsqlmysql.so, ldd it to be sure it was OK, and overwrite the old plugin with the new one.
I finally found a solution to my problem, so I have download libmysqlclient16 from libmysqlclient16 Debian amd64
After I made dpkg -i libmysqlclient16_5.1.73-1_amd64.deb
I restart and I compile my Qt project and I could not error
I know it is an old question, but I had the same issue with a slightly different solution probably due to Qt updates since then.
I will provide the solution that worked for me running Fedora 26 with kernel 4.13 and Qt 5.9.1
Find your path to Qt installation and let's call it here QTDIR.
In my case it is installed at /home/Qt5. So QTDIR = /home/Qt5/
My version is 5.9.1. Therefore I also have a folder "5.9.1" in QTDIR and I will call it "version" folder as Pepe did above.
The last folder that depends on your installation is the compiler folder. In my case it is gcc_64 inside QTDIR/version/
Now that you located yourself, let's go the procedure to install the drivers for Qt.
1) If your linux distribution doesn't come with SQL headers installed you must install them first. In Fedora I istalled the community-mysql-devel
> sudo dnf install community-mysql-devel
You must search and the install the appropriate SQL package for your distro. Just remember that the main idea is to install some development package in order to access the headers.
2) The second thing you need to do is to make sure you had installed Qt with the sources directory.
Check if you have the foulder $QTDIR/version/Src. If you have not, then run the maintenance tool in QTDIR and add Src foulder by checking the "sources" option under the kit you had installed (or wish to install).
3) Then go to where the sqldrivers should be by typing in your terminal
> cd yourQTDIR/yourVersion/Src/qtbase/src/plugins/sqldrivers
and run on terminal:
> make
> make install
This should create the drivers libqsqlite.so and libqsqlmysql.so in the folder: yourQTDIR/yourVersion/yourCompiler/plugins/sqldrivers
We then move to update a path to the sql headers as described in the official site http://doc.qt.io/qt-5/sql-driver.html, but with a slightly difference in the path to mysql headers (you must verify the proper folders in your OS). In my case MYSQL headers are in /usr/lib64.
Go to
> cd yourQTDIR/yourVersion/Src/qtbase/src/plugins/sqldrivers/mysql
Then run
> yourQTDIR/yourVersion/yourCompilerFolder/bin/qmake "INCLUDEPATH+=/usr/include" "LIBS+=-L/usr/lib64 -lmysqlclient_r" mysql.pro
> make
> make install
This should do the trick.
4) Now go to "yourQTDIR"/"yourVersion"/"yourCompiler"/plugins/sqldrivers
and run
> ldd libqsqlmysql.so
This will allow you to check if there is any missing link and direct you to a more specific solution to your case.
In a couple of Qt versions from now the procedure above may change. However the main points to keep in mind are that 1) you must have the MYSQL headers installed; 2) you must create the plugin by running make and make install in some source folder for MYQSL, and 3) you must update the path to MYSQL headers in order to Qt to find it.
I'm trying to link MySQL with a different glibc that provides e.g. a different pthread implementation and actually thought I got it right a few days ago.
Obviously, I took notes and wanted to reproduce the outcome but I can't get it to link properly, so I must have forgotten a step.
What I did previously was simply to add the flags pointing to my glibc and the default one second to the cmake command.
GLIBC_FLAGS="-Wl,--rpath=/path/to/my/glibc/build/lib:/usr/lib/x86_64-linux-gnu:/lib/x86_64-linux-gnu -Wl,--dynamic-linker=/path/to/my/glibc/build/lib/ld-linux-x86-64.so.2
cmake \
-DCMAKE_INSTALL_PREFIX=../install \
.. \
-DCMAKE_C_FLAGS="$GLIBC_FLAGS" \
-DCMAKE_CXX_FLAGS="$GLIBC_FLAGS"
These flags work when building a simple a test-program but seem not to work with MySQL as ldd reports the default glibc for mysqld.
$ ldd install/bin/mysqld
linux-vdso.so.1 => (0x00007fff14ffe000)
libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007f4f1c9bb000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f4f1c7b7000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f4f1c599000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f4f1c295000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f4f1bf91000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f4f1bd7a000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f4f1b9b2000)
/lib64/ld-linux-x86-64.so.2 (0x00007f4f1cc13000)
I also tried to set the LD_LIBRARY_PATH and changing the linker flags and lib variables in BUILD/scripts/mysql_config but none of these seem to work.
What is necessary to link MySQL against a different glibc?
ldd reports the default glibc for mysqld.
You should not trust ldd -- it uses default loader -- /lib64/ld-linux-x86-64.so.2 which is not the loader you've compiled your musqld to use.
Instead, run your mysqld under GDB and do start followed by info shared. You will likely see that in fact your version of glibc is actually loaded.
After a Kernel-Update, cmake apparently ignored the DCMAKE_CXX_FLAGS and DCMAKE_C_FLAGS if they contained a colon-separated list of paths (the options were used when they contained only a single path).
I worked around this by setting the colon-separated pathlist directly in the CMakeLists.txt in the MySQL root directory.