Hot answers tagged libraries
15
A .a file is a static library, while a .so file is a shared object (dynamic) library similar to a DLL on Windows. There's some detailed information about the differences between the two on this page.
11
As a follow on, a .a file is an "ar" archive. Not unlike a tar archive, it stores .o or object files, allowing them to be pulled out of the archive, and linked into a program, among other things. You could use ar to store other files if you wanted.
You can get a listing of the members of an ar file with the -t parameter, for instance:
ar -t /usr/lib/libc.a
...
11
Non-executable shared objects work fine, but libraries marked executable may also be runnable as standalone programs.
So, what's the point of setting this x?
None, unless you want them to emit version or other info
Must all library packagers do that?
No
What will happen if I dlopen() a shared library that has 0644
permissions?
You'll get ...
10
Conceptually, a library function is part of your process.
At run-time, your executable code and the code of any libraries (such as libc.so) it depends on, get linked into a single process. So, when you call a function in such a library, it executes as part of your process, with the same resources and privileges. It's conceptually the same as calling a ...
7
There's not really such a thing as a "library call". You can call a function that's linked to a shared library. And that just means that the library path is looked up at runtime to determine the location of the function to call.
System calls are low level kernel calls handled by the kernel.
7
You don't need to. Add the directory to /etc/ld.so.conf or a new file in /etc/ld.so.conf.d/, depending on distro.
After that, you must run (at least on Redhat) ldconfig as root.
As a word of caution, you need to be careful which libraries you add to the system shared library path (via the environment, ld.so.conf, or putting in /usr/local/lib). In ...
7
Boost is a mostly header-only library, so there is no library to link with (most of the time).
As for the headers, Ubuntu place them in /usr/include/, which is one of the include paths GCC use by default. So any #include <boost/foreach.hpp> will work out of the box on Ubuntu.
6
I did this quite frequently in my last job - the solution that seemed to work best was to create a ~/usr directory, and use the --prefix argument to point the ./configure scripts in the right direction. Here's the steps:
Create ~/usr directory, and include, lib and bin directories underneath it.
In your .profile, .bashrc, or other shell init script, add ...
6
You need to install the libX11 package:
$ rpm -qf /usr/lib/libX11.so.6
libX11-1.3.1-3.fc13.i686
Just go
$ yum -y install libX11
One more thing though: if you don't know how to find and install a library package, care to share why you are trying to compile a piece of software that is officially packaged for Fedora 13 in the most recent version?
$ ...
5
You can call ldd on it to see if -fopenmp was used:
$ cat x.c
int foo()
{ return 0 ; }
$ gcc -shared -fopenmp x.c -o x.so
$ ldd x.so
linux-vdso.so.1 => (0x00007fff293d6000)
libgomp.so.1 => /usr/lib/libgomp.so.1 (0x00007fa942998000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00007fa94277b000)
libc.so.6 => /lib/libc.so.6 ...
5
No, it doesn't. It appears to mean that the version of libz you linked against when you compiled your program was built with different tools than the version on the madriva system you're using. The mandriva copy is missing symbol version info which was present in the copy of the libz library your program originally linked against. This has to do with ...
5
If you type man man in your shell, you will see the list of the manual sections
2 System calls (functions provided by
the kernel)
3 Library calls (functions
within program libraries)
For instance, you will find chmod in the section 2 of the manual when typing man chmod. And fprintf in the section 3.
5
Since the source code for this wkhtmltoimage tool is available, I'd
suggest you
recompile it
from source with your system's native glibc. It will likely be even
quicker than recompiling glibc, which is no easy task.
A statically linked executable already includes code for all the C
library calls it needs to make, so you cannot separately compile a new
...
5
As msw says, it appears that your application wants to use the OpenWindows and Xview libraries that were provided in older Sun systems.
I believe they're not even around on newer Solaris installs anymore, but the free software projects OpenWindows Augmented Compatibility Environment and The XView Toolkit may provide compatible-enough implementations of ...
5
Sometimes ltrace works. In general, this calls for a debugger such as GDB. You can get an idea of which functions to put trace points or break points on by looking at the call structure in the disassembly (objdump -d /path/to/executable).
5
Debian and Ubuntu are moving to a new multiarch implementation (spec). Among other things, this involves moving arch-specific libraries into /usr/lib/<triplet>, dropping the limitations of lib32 and lib64 (where will the new x32 ABI go? where do qemulated binaries live? etc.) as well as extending the package manager to handle mixed-architecture ...
5
I suppose we're talking about x86 architecture.
You cannot have Self-Modifying Code in protected mode, which is used by most UNIX-based operating systems (and not only) that I'm aware of, because the code segments are always read-only. A loader does not control that -it is something that is being handled by the memory management subsystem of the kernel.
...
4
From your description it appears that these were written against the SunOS Xview Code Generation Suite. I have a dim memory of this package which is probably roughly analogous to GTK or Java Swing, but predates most of their concepts and mechanism.
I expect the best that you can do is either:
Write a library that simulates libguide which is fraught with ...
4
The main goals of EGLIBC (described http://www.eglibc.org/mission) are all targeting embedded platforms:
Provide options to reduce on-disk and in-memory footprint:
As long as you want to keep binary compatibility to glibc these options are useless or have nearly no effect on x86-64.
Support cross-compilation and cross-validation:
Well... Who does ...
4
You can check whether the library is linked against pthread at least by using ldd. On Debian squeeze, my version is linked against pthread.
$ ii libfftw3-3 3.2.2-1 library for computing Fast Fourier Transforms
$ ldd /usr/lib/libfftw3_threads.so.3.2.4
linux-gate.so.1 => (0xb77be000)
libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb776c000)
...
4
You can temporarily substitute a different library for this particular execution. In Linux, the environment variable LD_LIBRARY_PATH is a colon-separated set of directories where libraries should be searched for first, before the standard set of directories; this is useful when debugging a new library or using a nonstandard library for special purposes. ...
4
libstdc++ 3 is not the default libstdc++ anymore. You can still install it, though it is best to do so with your distro package util. I'm assuming your BOINC client is for your arch, x86_64, and not compiled for x86. The difference is significant in resolving dependency issues.
Considering you are on a regular user account, you should theoretically be ...
4
Here's what I'd do:
Run ldd /usr/bin/Xorg
You should get a line that looks like this:
libz.so.1 => /usr/lib/libz.so.1 (0xb7357000)
If ldd claims that it can't resolve what file libz.so.1 is in, then uninstall and reinstall zlib:
pacman -R -f zlib
pacman -S zlib
If ldd can find a specific libz.so.1, then check to see if that file constitutes a ...
4
You've got it wrong: “old” libraries are installed on system-wide paths, and this is the desirable behavior. The way it works is: if two library versions are compatible at the binary level, then you only have one installed, and every application that uses this version uses the same library file. If two library versions are not compatible at the binary level, ...
4
Maybe
readelf -a
It displays information about ELF files. If the object you are studying still contains the comment section, you may try to extract it by
readelf -p .comment yourfile
For example
$ cat test.c
int main () {
return 0;
}
$ gcc test.c
$ readelf -p .comment a.out
String dump of section '.comment':
[ 0] GCC: (Ubuntu/Linaro ...
4
Unless you are on very old/low spec hardware, running gnome/gtk apps in KDE (or kde/qt apps in GNOME) should not have any noticeable impact on performance.
When you're on KDE, qt/kde libs are already loaded in memory, gtk/gnome libs are not. It's only when you fire-up a gtk/gnome app that gtk/gnome libs are loaded, the side effect being a higher memory usage ...
4
Ah yes this is a very confusing part if you've dealt with Unixes for any length of time. There is a standard that most Unixes "try" to follow called FHS - Filesystem Hierarchy Standard.
Given I primarily use Red Hat based distros I'm most familiar with their take on FHS for Fedora, CentOS, and RHEL Linux distros. But I've used Debian & BSD based distros ...
3
You have no check on the library. One way would be to replace
pack: $(OBJ)
$(AR) $(ARFLAGS) $(NAME).a $(OBJ)
by
pack: $(NAME).a
$(NAME).a: $(OBJ)
$(AR) $(ARFLAGS) $(NAME.a) $(OBJ)
so the library would not be remade if it is up to date.
3
System calls are handled directly by the kernel.
Library calls are handled by a dynamic library. The program making the library call must first import that library, before the call will work. The library calls themselves may use system calls.
Sometimes libraries are provided as "front-ends" to system calls, to provide extra functionality or ease of use ...
3
Given that you will be using some sort of package manager to install libraries, wouldn't it be much easier to just have a list of packages that you want to be installed and ensure somehow that they are installed?
100% of package managers that I know have some sort of mode (the default mode, usually) that either installs a package if it's not installed, ...
Only top voted, non community-wiki answers of a minimum length are eligible
