I'm trying to use NS2 but when I try to use nam.exe it'd not work! So is there other way to use nam.exe whitout using startX in CygWin?
thank you
Regards
``nam´´ is a GUI application (for X), and as such it requires X.
``nam´´ is using some X libraries:
$ ldd /usr/local/bin/nam
libXext.so.6 => /usr/lib/libXext.so.6 (0xb76b2000)
libX11.so.6 => /usr/lib/libX11.so.6 (0xb7564000)
libnsl.so.1 => /lib/libnsl.so.1 (0xb7548000)
libdl.so.2 => /lib/libdl.so.2 (0xb7543000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb744f000)
libm.so.6 => /lib/i686/libm.so.6 (0xb7402000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb73e4000)
libc.so.6 => /lib/i686/libc.so.6 (0xb721a000)
libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb71f7000)
/lib/ld-linux.so.2 (0xb76ec000)
libXau.so.6 => /usr/lib/libXau.so.6 (0xb71f3000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb71ec000)
Related
I have a problem with shared libraries, Command show warning each time when it run's,
PHP Warning: PHP Startup: Unable to load dynamic library 'xxxx.so'
whereas it run fine with not issues, i want to remove libcrypto.so.1.0.0 => not found this line from list so that it will not look for this shared library.
ldd ...php/ext/curl.so
linux-vdso.so.1 => (0x00007ffe1a65f000)
libcurl.so.4 => /lib/libcurl.so.4 (0x00007fb9fdd8f000)
libssl.so.1.0.0 => /lib/libssl.so.1.0.0 (0x00007fb9fdb1f000)
libcrypto.so.1.0.0 => not found
libc.so.6 => /lib64/libc.so.6 (0x00007fb9fd751000)
libssl.so.1.1 => /lib/libssl.so.1.1 (0x00007fb9fd4c0000)
libcrypto.so.1.1 => /lib/libcrypto.so.1.1 (0x00007fb9fcff7000)
libldap-2.4.so.2 => /lib/libldap-2.4.so.2 (0x00007fb9fcdb5000)
liblber-2.4.so.2 => /lib/liblber-2.4.so.2 (0x00007fb9fcba8000)
libz.so.1 => /lib/libz.so.1 (0x00007fb9fc990000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fb9fc774000)
libcrypto.so.1.0.0 => not found
libdl.so.2 => /lib64/libdl.so.2 (0x00007fb9fc570000)
/lib64/ld-linux-x86-64.so.2 (0x00007fb9fe22e000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x00007fb9fc356000)
libcrypto.so.1.0.0 => not found
what to do ?
I'm having problems with a library, which cannot be found, despite being there in proper version.
ldd /lib/libQt5Core.so
linux-gate.so.1 (0xb77ac000)
libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xb71d4000)
libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xb71b9000)
libicui18n.so.57 => /lib/i386-linux-gnu/libicui18n.so.57 (0xb6f20000)
libicuuc.so.57 => /lib/i386-linux-gnu/libicuuc.so.57 (0xb6d74000)
libicudata.so.57 => /lib/i386-linux-gnu/libicudata.so.57 (0xb54f6000)
libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xb54f1000)
libgthread-2.0.so.0 => /lib/i386-linux-gnu/libgthread-2.0.so.0 (0xb54ee000)
libglib-2.0.so.0 => /lib/i386-linux-gnu/libglib-2.0.so.0 (0xb53c0000)
libstdc++.so.6 => /lib/i386-linux-gnu/libstdc++.so.6 (0xb5242000)
libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xb5140000)
libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xb5120000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb4f47000)
/lib/ld-linux.so.2 (0xb77af000)
libpcre.so.3 => /lib/i386-linux-gnu/libpcre.so.3 (0xb4ed0000)
The libQt5Core library is in /lib and has all dependencies met. But if something wishes to use it:
ldd /lib/libQt5Concurrent.so
linux-gate.so.1 (0xb7735000)
libQt5Core.so.5 => not found
libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xb76f1000)
libstdc++.so.6 => /lib/i386-linux-gnu/libstdc++.so.6 (0xb7573000)
libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xb7471000)
libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xb7453000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb727a000)
/lib/ld-linux.so.2 (0xb7738000)
libQt5Core is no longer found. Both libs have the same architecture. Does anyone have any ideas?
Turns out it's an issue with kernel being too old. On newer ones it works fine.
[UPDATE] Upgrading to python 2.7.6 and Qt 4.8.7 appears to make this problem go away and JPEG support is provided. Whereas before creating a QPixmap object using a path to a .jpeg/.jpg file would produce an object for which isNull() was always True, now I get a valid QPixmap object.
The platform in question is a CentOS 7.2 system with KDE4 as the default desktop environment. Qt 4.8.5 is installed along with PySide 1.2.2. JPEG support seems to be missing for some reason.
>>> from PySide import QtGui
>>> pprint(QtGui.QImageReader.supportedImageForamts())
[PySide.QtCore.QByteArray('BW'),
PySide.QtCore.QByteArray('EPS'),
PySide.QtCore.QByteArray('EPSF'),
PySide.QtCore.QByteArray('EPSI'),
PySide.QtCore.QByteArray('EXR'),
PySide.QtCore.QByteArray('PCX'),
PySide.QtCore.QByteArray('PSD'),
PySide.QtCore.QByteArray('RAS'),
PySide.QtCore.QByteArray('RGB'),
PySide.QtCore.QByteArray('RGBA'),
PySide.QtCore.QByteArray('SGI'),
PySide.QtCore.QByteArray('TGA'),
PySide.QtCore.QByteArray('XCF'),
PySide.QtCore.QByteArray('bmp'),
PySide.QtCore.QByteArray('bw'),
PySide.QtCore.QByteArray('dds'),
PySide.QtCore.QByteArray('eps'),
PySide.QtCore.QByteArray('epsf'),
PySide.QtCore.QByteArray('epsi'),
PySide.QtCore.QByteArray('exr'),
PySide.QtCore.QByteArray('jp2'),
PySide.QtCore.QByteArray('pbm'),
PySide.QtCore.QByteArray('pcx'),
PySide.QtCore.QByteArray('pgm'),
PySide.QtCore.QByteArray('pic'),
PySide.QtCore.QByteArray('png'),
PySide.QtCore.QByteArray('ppm'),
PySide.QtCore.QByteArray('psd'),
PySide.QtCore.QByteArray('ras'),
PySide.QtCore.QByteArray('rgb'),
PySide.QtCore.QByteArray('rgba'),
PySide.QtCore.QByteArray('sgi'),
PySide.QtCore.QByteArray('tga'),
PySide.QtCore.QByteArray('xbm'),
PySide.QtCore.QByteArray('xcf'),
PySide.QtCore.QByteArray('xpm'),
PySide.QtCore.QByteArray('xv')]
As you can see there is no JPEG support listed. The Qt imageformats contains:
libqgif.so
libqico.so
libqjpeg.so
libqmng.so
libqsvg.so
libqtga.so
libqtiff.so
Doing an ldd on libqjpeg.so yields:
linux-vdso.so.1 => (0x00007ffc43530000)
libQtGui.so.4 => /lib64/libQtGui.so.4 (0x00007f2c11977000)
libQtCore.so.4 => /lib64/libQtCore.so.4 (0x00007f2c1148c000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f2c1126f000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f2c10f67000)
libm.so.6 => /lib64/libm.so.6 (0x00007f2c10c65000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f2c10a4e000)
libc.so.6 => /lib64/libc.so.6 (0x00007f2c1068d000)
libgthread-2.0.so.0 => /lib64/libgthread-2.0.so.0 (0x00007f2c1048b000)
libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x00007f2c10153000)
libpng15.so.15 => /lib64/libpng15.so.15 (0x00007f2c0ff28000)
libz.so.1 => /lib64/libz.so.1 (0x00007f2c0fd12000)
libfreetype.so.6 => /lib64/libfreetype.so.6 (0x00007f2c0fa6b000)
libgobject-2.0.so.0 => /lib64/libgobject-2.0.so.0 (0x00007f2c0f81b000)
libSM.so.6 => /lib64/libSM.so.6 (0x00007f2c0f613000)
libICE.so.6 => /lib64/libICE.so.6 (0x00007f2c0f3f6000)
libXi.so.6 => /lib64/libXi.so.6 (0x00007f2c0f1e6000)
libXrender.so.1 => /lib64/libXrender.so.1 (0x00007f2c0efdc000)
libXrandr.so.2 => /lib64/libXrandr.so.2 (0x00007f2c0edd1000)
libXfixes.so.3 => /lib64/libXfixes.so.3 (0x00007f2c0ebcb000)
libXcursor.so.1 => /lib64/libXcursor.so.1 (0x00007f2c0e9c0000)
libXinerama.so.1 => /lib64/libXinerama.so.1 (0x00007f2c0e7bc000)
libfontconfig.so.1 => /lib64/libfontconfig.so.1 (0x00007f2c0e580000)
libXext.so.6 => /lib64/libXext.so.6 (0x00007f2c0e36e000)
libX11.so.6 => /lib64/libX11.so.6 (0x00007f2c0e02f000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f2c0de2b000)
librt.so.1 => /lib64/librt.so.1 (0x00007f2c0dc23000)
/lib64/ld-linux-x86-64.so.2 (0x00007f2c128b9000)
libffi.so.6 => /lib64/libffi.so.6 (0x00007f2c0da1a000)
libuuid.so.1 => /lib64/libuuid.so.1 (0x00007f2c0d815000)
libexpat.so.1 => /lib64/libexpat.so.1 (0x00007f2c0d5ea000)
libxcb.so.1 => /lib64/libxcb.so.1 (0x00007f2c0d3c8000)
libXau.so.6 => /lib64/libXau.so.6 (0x00007f2c0d1c3000)
I see no missing shared libraries, but also nothing that looks like a JPEG library. QT_PLUGIN_PATH points to /usr/lib64/kde4/plugins, and /usr/lib64/kde4/plugins/imageformats contains these files:
kimg_dds.so
kimg_eps.so
kimg_exr.so
kimg_jp2.so
kimg_pcs.so
kimg_pic.so
kimg_psd.so
kimg_ras.so
kimg_rgb.so
kimg_tga.so
kimg_xcf.so
kimg_xview.so
So no kimg_jpeg.so (if there even is such a thing), and clearly kimg_jp2.so isn't providing JPEG support. So what am I missing?
I'm compiling 2 shared libraries ("A", "B") under Linux (Ubuntu 11)
The lib "B" is using exported function from lib "A" (linked statically with -lA)
But when I'm running ldd on "B" I just have*
linux-gate.so.1 => (0x004c0000) libc.so.6
/lib/i386-linux-gnu/libc.so.6 (0x00abf000)
/lib/ld-linux.so.2 (0x00679000)
I cannot see my "A" dependency !?
Strange, I was (almost) pretty sure ldd used to display ALL static dependencies !?
From man ldd
ldd - print shared library dependencies
There is no run-time dependencies for static libraries, since they were linked statically,
You need to link dynamically libA.so into libB.so, that is to build libB.so with something like
gcc -shared -o libB.so B*.pic.o -lA
(assuming no libA.a exist, only a libA.so)
And then you could use ldd libB.so to check that it does link libA.so
Look for example into most GUI libraries like /usr/lib/libQtGui.so.4 or /usr/lib/libgtk-3.so, e.g.
% ldd /usr/lib/libgtk-3.so
linux-vdso.so.1 => (0x00007fffe4cef000)
libgdk-3.so.0 => /usr/lib/libgdk-3.so.0 (0x00007f5a69c3b000)
libpangocairo-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libpangocairo-1.0.so.0 (0x00007f5a69a00000)
libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f5a696c0000)
libXcomposite.so.1 => /usr/lib/x86_64-linux-gnu/libXcomposite.so.1 (0x00007f5a694be000)
libXdamage.so.1 => /usr/lib/x86_64-linux-gnu/libXdamage.so.1 (0x00007f5a692bc000)
libXfixes.so.3 => /usr/lib/x86_64-linux-gnu/libXfixes.so.3 (0x00007f5a690b5000)
libatk-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libatk-1.0.so.0 (0x00007f5a68e92000)
libcairo-gobject.so.2 => /usr/lib/libcairo-gobject.so.2 (0x00007f5a68c8a000)
libcairo.so.2 => /usr/lib/libcairo.so.2 (0x00007f5a689c9000)
libgdk_pixbuf-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0 (0x00007f5a687aa000)
libgio-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0 (0x00007f5a68465000)
libpangoft2-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libpangoft2-1.0.so.0 (0x00007f5a68238000)
libpango-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0 (0x00007f5a67feb000)
libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007f5a67d4d000)
libfontconfig.so.1 => /usr/lib/x86_64-linux-gnu/libfontconfig.so.1 (0x00007f5a67b17000)
libgobject-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 (0x00007f5a678c6000)
libgmodule-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0 (0x00007f5a676c3000)
libgthread-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgthread-2.0.so.0 (0x00007f5a674bd000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f5a672b5000)
libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007f5a66fbe000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f5a66d3b000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f5a66b1f000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f5a6679b000)
libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007f5a66587000)
libXinerama.so.1 => /usr/lib/x86_64-linux-gnu/libXinerama.so.1 (0x00007f5a66385000)
libXi.so.6 => /usr/lib/x86_64-linux-gnu/libXi.so.6 (0x00007f5a66176000)
libXrandr.so.2 => /usr/lib/x86_64-linux-gnu/libXrandr.so.2 (0x00007f5a65f6d000)
libXcursor.so.1 => /usr/lib/x86_64-linux-gnu/libXcursor.so.1 (0x00007f5a65d63000)
libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f5a65b46000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f5a65942000)
libpixman-1.so.0 => /usr/lib/x86_64-linux-gnu/libpixman-1.so.0 (0x00007f5a656ba000)
libpng12.so.0 => /lib/x86_64-linux-gnu/libpng12.so.0 (0x00007f5a65494000)
libxcb-shm.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-shm.so.0 (0x00007f5a65291000)
libxcb-render.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-render.so.0 (0x00007f5a65087000)
libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1 (0x00007f5a64e7d000)
libz.so.1 => /usr/lib/libz.so.1 (0x00007f5a64c65000)
libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f5a64a44000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f5a6482e000)
libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007f5a64604000)
libffi.so.5 => /usr/lib/x86_64-linux-gnu/libffi.so.5 (0x00007f5a643f7000)
/lib64/ld-linux-x86-64.so.2 (0x00007f5a6a50e000)
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f5a641ba000)
libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f5a63fb7000)
libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f5a63db1000)
I am using ldd to show the dynamic library on Fedora/x86, and it shows different results each time it is used.
Is that expected? Or is there an explanation?
I remember it shows a fixed result on PPC/Linux.
`ldd /bin/ls
linux-gate.so.1 => (0x00e5b000)
librt.so.1 => /lib/librt.so.1 (0x00c0c000)
libselinux.so.1 => /lib/libselinux.so.1 (0x0095d000)
libcap.so.2 => /lib/libcap.so.2 (0x00110000)
libacl.so.1 => /lib/libacl.so.1 (0x00331000)
libc.so.6 => /lib/libc.so.6 (0x00115000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00bc9000)
/lib/ld-linux.so.2 (0x009d2000)
libdl.so.2 => /lib/libdl.so.2 (0x00680000)
libattr.so.1 => /lib/libattr.so.1 (0x00447000)
ldd /bin/ls
linux-gate.so.1 => (0x00f76000)
librt.so.1 => /lib/librt.so.1 (0x00494000)
libselinux.so.1 => /lib/libselinux.so.1 (0x0095d000)
libcap.so.2 => /lib/libcap.so.2 (0x009e9000)
libacl.so.1 => /lib/libacl.so.1 (0x00365000)
libc.so.6 => /lib/libc.so.6 (0x00732000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00b61000)
/lib/ld-linux.so.2 (0x002a7000)
libdl.so.2 => /lib/libdl.so.2 (0x002f0000)
libattr.so.1 => /lib/libattr.so.1 (0x00447000)`
Fedora uses address space randomization as part of its various security measures. ldd works by actually loading the shared objects and showing where they end up. Putting the two together results in the given observations.