so the short version first: If I link some programs via ld with ld -someflag .. how can I find out which library -someflag belongs to?
Long Version:
I need to compile a rather complex FOTRAN library. On machine1 the compilation works without errors (Fedora). On my second machine, machine2 (Debian) I get the following two linker errors:
ld: cannot find -lmkl_intel
ld: cannot find -lguide
Since I couldn't find any information on where those two files belong to, I thought about using machine1, but I got no idea how to find that out.
From my perspective I installed the exact same libraries on machine1 and machine2, but apperently something is missing or different in those two operating systems.
Thanks for your help
I already tried to search through all libraries contanined in the lb path on machine 1, but that didn't return any matching the names lmk_intel or guide
Related
I recently took over some RPM work while one of our colleagues is away. During the post installation step, the RPM installs some libraries in a particular location, writes a file to /etc/ld.conf.so.d/ containing the path to these files, and then runs "ldconfig". But when the call is made, there are quite few messages stating that: "libXYZ.so* is not a symbolic link".
I looked at the files and the sym links are not set up correctly. E.g., libA.so.1 and libA.so.1.1 are identical files, instead of libA.so.1->libA.so.1.1. Whenever ldconfig is run on a system with the RPM installed, these messages are shown.
Now for no particular reason, I tried replicating this by creating a shared library called libmylib.so.1.1. Then I created another file called libmylib.so.1 which was identical to the previous file. I added a test.conf file to /etc/ld.conf.so.d which contains the path to these shared libraries, and then ran ldconfig. But I didn't see any of these "not a symlink" messages. Instead ldconfig set up two symlinks to both these files. Is that message displayed only under particular circumstances?
Also, when I'm installing shared libraries, do I need to setup the links such as:
linker name -> so name -> real name
manually? And then run ldconfig?
This is my first time working with RPM and installing shared libraries, so any input would be appreciated.
Thanks
Common practice is to make symbolic links to relate the library version and soname to the name used when building/linking a program. Here are a few comments on that:
Program Library HOWTO: 3. Shared Libraries
“soname” option for building shared library
ldconfig expects that there is only one actual file. Here are a few places where this question has been asked:
Always getting “not a symbolic link” message, while installing any package
ldconfig : /usr/lib/libstdc++.so.6 is not a symbolic link + mysql
Usually, problems in this area are due to improper updating of the symbolic links. But an incorrect build-script can be the problem as well.
I get this message when I try to run a Perl script used in a bioinformatic package named DISOPRED3:
/usr/bin/perl: symbol lookup error: /software6/bioinfo/apps/mugqic_space/software/
perl/perl-5.18.2/lib/5.18.2/x86_64-linux-thread-multi/auto/Cwd/Cwd.so:
undefined symbol: Perl_xs_apiversion_bootcheck
I used the exact same script on my local computer and it works. Now I have to work on a super-computer from a distance and that's where I get this message. I checked, and the Perl versions are the same on both computers.
Sounds like you have two installs of Perl, the system one (/usr/bin/perl), and one in /software6/bioinfo/apps/mugqic_space/software/perl, and the former is using files installed by the latter. The former should not have been told to even look at the files installed by the latter.
I'm having trouble cross compiling PostgreSQL for my TI Sitara AM335x EVM SK. My host system is an i386 machine running Ubuntu 12.04.
My application is written in C++ using Qt. When I try and compile, I get the error that libpq.so is incompatible. I believe this is because the cross compiler is trying to use the host libpq.so instead of one for the target system (which as I have found out, doesn't exist).
I've downloaded the source for PostgreSQL with the intention of cross compiling that in order to give me the libpq.so library that will be compatible with my target system, however there is virtually no information on how to do this.
I have tried using the CC argument with the configure file to change my compiler to the following: CC=/home/tim/ti-sdk-am335x-evm-06.00.00.00/linux-devkit/sysroots/i686-arago-linux/usr/bin/arm-linux-gnueabihf-gcc but the configure script gives me this error: configure: error: cannot run C compiled programs. If you meant to cross compile, use --host.
The configure file makes a small reference to the --host option, but the only information in the file that I could find is in reference to mingw and windows, which isn't what I want.
I've done some quick searching through the configure file, and it references the --host option, but with no explanation of what is a valid host. I'm assuming that with --host option there will be an associated --target.
What arguments can I give the configure script so that it will cross compile with the correct compiler to generate a library that my target device can use? Are there any resources out there that I haven't found in regards to how the --host/--target works or how to use them?
OK, so after fiddling around for a little while, I think I was actually able to cross compile PostgreSQL and answer my own question.
Before I went any further, I had realized I had forgotten to add the path to my cross compiler to the PATH environment variable. I used the command export PATH=/path/to/cross/compiler:$PATH to insert the compiler path to the PATH environment variable.
Next, I did some experimenting with the --host option. To start off with I tried using ./configure --host=arm-linux-gnueabihf and running the configure script. The configure script seemed to accept this as the host argument. I then went to the next step of running the makefile. Running this makefile resulted in errors being generated. The errors were selected processor does not support Thumb mode. I did a quick search to see what information I could find about this error and came to this webpage: http://www.postgresql.org/message-id/E1Ra1sk-0000Pq-EL#wrigleys.postgresql.org.
This webpage gave me a bit more information since it seemed like the person was trying to do something very similar to me. One of the responders to the post mentioned that --disable-spinlocks is intended for processors that aren't supported by default by PostgreSQL. I emulated the arguments that were used in the website listed above and used the command: ./configure --host=arm-linux CC=arm-linux-gnueabihf-gcc AR=arm-linux-gnueabihf-ar CPP=arm-linux-gnueabihf-cpp --without-readline --without-zlib --disable-spinlocks to generate my makefile. This makefile actually generated all of the files, including the libpq.so library file I was needing.
Hope this helps somebody else in the future!
I want to use the export_fig package for Matlab. At one point this worked, but now it's broken. The error occurs here:
>> system('pdftops -h')
dyld: Library not loaded: /opt/local/lib/libtiff.5.dylib
Referenced from: /opt/local/bin/pdftops
Reason: Incompatible library version: pdftops requires version 8.0.0 or later, but libtiff.5.dylib provides version 6.0.0
pdftops -h: Trace/breakpoint trap
But when I call pdftops from my own bash terminal everything works fine. I suppose it must be because Matlab has some bad library paths or something, but I don't know where to go from here?
Some relevant environmental vars used by matlab:
>> system('env')
SHELL=/bin/bash
OSG_LD_LIBRARY_PATH=/Applications/MATLAB_R2013b.app/sys/openscenegraph/lib/maci64
PATH=/usr/bin:/bin:/usr/sbin:/sbin:/opt/local/bin:/opt/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/opt/X11/bin:/usr/texbin
__CHECKFIX1436934=1
XFILESEARCHPATH=/Applications/MATLAB_R2013b.app/sys/java/jre/maci64/jre/lib/locale/%L/%T/%N%S:
DYLD_FRAMEWORK_PATH=/Applications/MATLAB_R2013b.app/sys/os/maci64:/Applications/MATLAB_R2013b.app/bin/maci64/../../Contents/MacOS:/Applications/MATLAB_R2013b.app/bin/maci64:/Applications/MATLAB_R2013b.app/extern/lib/maci64:/Applications/MATLAB_R2013b.app/sys/java/jre/maci64/jre/lib/./native_threads:/Applications/MATLAB_R2013b.app/sys/java/jre/maci64/jre/lib/./server:/Applications/MATLAB_R2013b.app/sys/java/jre/maci64/jre/lib/./lib/jli
SHLVL=1
__KMP_REGISTERED_LIB_33586=0x124404710-cafeb339-libiomp5.dylib
DYLD_LIBRARY_PATH=/Applications/MATLAB_R2013b.app/sys/os/maci64:/Applications/MATLAB_R2013b.app/bin/maci64/../../Contents/MacOS:/Applications/MATLAB_R2013b.app/bin/maci64:/Applications/MATLAB_R2013b.app/extern/lib/maci64:/Applications/MATLAB_R2013b.app/sys/java/jre/maci64/jre/lib/./native_threads:/Applications/MATLAB_R2013b.app/sys/java/jre/maci64/jre/lib/./server:/Applications/MATLAB_R2013b.app/sys/java/jre/maci64/jre/lib/./lib/jli
If you take a look at the error message, MATLAB uses libtiff to call pdftops, but only has version 6.0.0. It says it needs version 8.0.0 or later. There has been a case where this happened before here on StackOverflow. Someone was trying to install mexopencv and has encountered the same error that you're talking about: Compiling mexopencv in OS X 10.9 with Xcode 5 and Matlab R2013b
Though this is unrelated to what you're doing, they encountered the libtiff error that you speak of. They provide two solutions how to fix this error:
Go into MATLAB's root directory, then go bin/os directory where os is the directory of the operating system you are using (in my case, it's maci64). To get into the root directory, in the command prompt do this: cd/(matlabroot). Once you're here, locate the libtiff.5.dylib file and rename it to something like libtiff.5.dylib.bak so that the libtiff libraries that are used are the ones that are default to your system rather than what MATLAB is using internally in the program.
Force MATLAB to point to the library that is part of the system rather than using the one built into MATLAB. As such, in MATLAB's command prompt, run this command:
setenv('DYLD_INSERT_LIBRARIES','/opt/local/lib/libtiff.5.dylib');
Once you do this, you may get further errors that are similar but are with other libraries. As such, you need to keep appending these libraries in the second parameter of setenv and colon-delimiting them until you resolve the issues. You need to make sure that you're pointing to the ones on your system rather than the ones installed with MATLAB. In your case, you have to do:
setenv('DYLD_INSERT_LIBRARIES', ...
'/opt/local/lib/libtiff.5.dylib:/opt/local/lib/libcurl.4.dylib');
Glad this helped!
0:025> !pe
Failed to load data access DLL, 0x80004005
Verify that 1) you have a recent build of the debugger (6.2.14 or newer)
2) the file mscordacwks.dll that matches your version of mscorwks.dll is
in the version directory
3) or, if you are debugging a dump file, verify that the file
mscordacwks_<arch>_<arch>_<version>.dll is on your symbol path.
4) you are debugging on the same architecture as the dump file.
For example, an IA64 dump file must be debugged on an IA64
machine.
You can also run the debugger command .cordll to control the debugger's
load of mscordacwks.dll. .cordll -ve -u -l will do a verbose reload.
If that succeeds, the SOS command should work on retry.
If you are debugging a minidump, you need to make sure that your executable
path is pointing to mscorwks.dll as well.
After corflags.exe /32bit+ xxxx.exe to run on a 64bit server 2003, the xxxx.exe usually crash. I got this dump, on the same machine, install windbg(x86), but I can't use SOS. I googled this issue, but can't find work answer. I use the same machine, why windbg can't find what it need?
The problem is that the correct version of mscordacwks.dll can't be located. The DLL acts as an abstraction layer between the runtime and SOS and thus it must correspond to the version of the runtime. There's an excellent write up of the problem and its solution here http://blogs.msdn.com/dougste/archive/2009/02/18/failed-to-load-data-access-dll-0x80004005-or-what-is-mscordacwks-dll.aspx
Make sure to follow the advice on renaming the DLL very carefully, cause if you get it wrong it doesn't work and the error messages are not very helpful imo.