Hot answers tagged

29

If you compile an executable with gcc's -g flag, it contains debugging information. That means for each instruction there is information which line of the source code generated it, the name of the variables in the source code is retained and can be associated to the matching memory at runtime etc. Strip can remove this debugging information and other data ...


15

The Link Editor Command Language appears to be described in the AT&T UNIX™ PC Model 7300 Unix System V Programmers Guide, chapter 17: The Link Editor. I found a copy of the Programmer's Guide (pdf) at http://www.tenox.net/docs/. The relevant section is on page 524 of the linked .pdf.


12

If fdisk is just an example and your goal is really to make static executables from dynamic executables, try Elf statifier. There's even a comparison with Ermine (by the Ermine vendor, so caveat (non-)emptor). Note that If you have many executables, their combined size is likely to be more than the combined size of the dynamically-linked executables plus ...


7

Installing gcc puts a libstdc++.so.6 into both $PREXIF/lib and $PREFIX/lib64. Using the latter as RPATH for boost and my program solved the issue. Using only the former results in a fall-back to the system libstdc++.so.6.


7

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. ...


6

Write a wrapper script that sets the LD_LIBRARY_PATH environment variable. This is the pendant of PATH for shared libraries. The system search path is always searched after the directories listed in $LD_LIBRARY_PATH. See the dynamic linker manual for reference. #!/bin/sh export LD_LIBRARY_PATH=~/opt/openssl-1.0.1/lib exec /path/to/a.out "$@" Or, for a ...


5

The main entry point is God. Be it a C or C++ source file, it is the center of the application. Only in the same way that nitrogen is the center of a pine tree. It is where everything starts, but there's nothing about C or C++ that makes you put the "center" of your application in main(). A great many C and C++ programs are built on an event loop or an ...


5

I have also .1 as I can see from the content it is used for manual Yes, these are written in groff markup. They aren't compiled, they're interpreted at runtime via man or some other viewer (using groff as a backend). The .1 actually denotes the manual section (see man man). When an executable is installed into an element of the system's executable ...


4

Not at all. One involves redirecting all references to a file name ( any kind of file ) to a different file instead ( symlinks ), and the other involves building an executable image by copying code from a library into the executable ( static linking ) or referencing a dynamic library that contains the required code and loading that dynamic library at ...


3

You shouldn't be upgrading your toolchain piecemeal. The parts have to work together. The GNU tools allow so much variation that it is essential that the pieces be set up to work together, especially for a cross-compiler. If you need a newer ld for some reason, you should build up a complete toolchain to support it.


3

AFAIK that header file is more an old-school unix or BSD thing, you can find it in Solaris and {Free,Open,Net}BSD: http://svnweb.freebsd.org/base/head/sys/x86/include/frame.h?revision=247047&view=markup On FreeBSD it's /usr/include/machine/frame.h, there's one for each CPU architecture if you have the kernel source installed, or rummage around that ...


3

Have a look at the CUPS port in cygwin-ports, they provide version 1.4.6 as of January 30th 2011. It patches quite a lot...


3

What matters is what Linux distribution each machine uses, because they handle library paths differently. On the Gentoo (Sabayon) machine, if you want a third party library to be usable system-wide, you should: Create a file under /etc/env.d/ that will contain the additional environment setup. The files are named using the scheme [0-9][0-9]somename - the ...


3

You probably need to install the development-package libkrb5-dev or krb5-multidev: apt-get install libkrb5-dev and need the correct parameters for gcc (run krb5-config.mit gssrpc --libs to get them): gcc test.c -o test $(krb5-config.mit gssrpc --libs) which expands to (depending on the system): gcc test.c -o test -L/usr/lib/x86_64-linux-gnu/mit-krb5 ...


3

You would be interested in removing library paths if a given shared library has embedded paths via the rpath feature. Those are added at the time the library is created by the linker. You can remove (or alter) those paths using chrpath, e.g., chrpath -d mylibraryfile.so Removing pathnames from the LD_LIBRARY_PATH variable also is a possible area of ...


2

The only thing I can think of is that the .so files aren't in a directory the linker looks for libraries in. Can you find out where the file libxml2.so resides, and then put that directory on the link command line with a -L ?


2

glib is not your problem. This is: re.c:(.text+0xd6): undefined reference to `print_uppercase_words' What it's saying is you're calling a function print_uppercase_words, but it can't find it. And there's a reason. Look very closely. There's a typo: void print_upppercase_words(const gchar *string) After you fix that, you might still have a problem ...


2

Please use LD_LIBRARY_PATH. Refer to these useful links as well: http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html http://linuxmafia.com/faq/Admin/ld-lib-path.html


2

Like Renan said, this is the result of a 32/64 bit mismatch. On OpenSUSE, try zypper in Mesa-32bit to install the 32 bit version of the library. In general, if you have the 64 bit version, you can use rpm -qf to find the package containing the library: % rpm -qf /usr/lib64/libGLU.so.1 Mesa-7.11-11.4.2.x86_64 On OpenSUSE, the naming convention for ...


2

I was able to solve this with the help of the comments, particular credit to @Mat. Since I wanted to compile the openmpi version, it helped to use mpif90 instead of gfortran, which, on my system, is $ mpif90 --showme /usr/bin/gfortran -I/usr/include -pthread -I/usr/lib/openmpi -L/usr/lib/openmpi -lmpi_f90 -lmpi_f77 -lmpi -ldl -lhwloc


2

It will depend on where the file is, in my case it works like this: :~$ locate gcc_s /lib/x86_64-linux-gnu/libgcc_s.so.1 /usr/lib/gcc/x86_64-linux-gnu/4.6/libgcc_s.so /usr/lib/gcc/x86_64-linux-gnu/4.7/libgcc_s.so And you have to make sure that path is present in one of the ld.so.conf files like: :~$ cat /etc/ld.so.conf.d/x86_64-linux-gnu.conf # Multiarch ...


2

I generally approach this question like this. I'm on a Fedora 19 system but this will work on any distro that provides locate services. $ locate "linux/init.h" | grep include /usr/src/kernels/3.13.6-100.fc19.x86_64.debug/include/linux/init.h /usr/src/kernels/3.13.7-100.fc19.x86_64.debug/include/linux/init.h ...


2

The direct (perhaps obvious) answer is that the search path for the libraries you are looking at with ldd does not include the directories where the library's own dependencies are located. Normally, unless a library's dependencies are found in system-wide standard locations, the library should have been built with a run path specified (by using the ...


2

A couple of things need to be clarified here: There is virtually no difference between a program being on the hard storage or in memory. If the kernel doesn't find the file already mapped into memory, mmap happens and from then on, the file is accessed through the memory pages, mapped into the virtual memory of a program. Note that this whole mechanism is ...


2

You can check for option -f of ldconfig: -f conf Use conf instead of /etc/ld.so.conf. If you run: ldconfig -f custom.conf with user with enough privileges it will modify /etc/ld.so.cache. ld reads /etc/ld.so.cache and I don't think you can make it to read from different file. As you don't want to modify system files you can do following: ...


2

You can use the standard ELF program dump: dump -Lv libxxx.so | grep SYMBOLIC


2

Your system doesn't have /lib/ld.so, so it isn't equipped for dynamically linked a.out executables. It could be equipped for statically linked a.out executables, if your kernel includes support for them; Ubuntu's doesn't (this requires the CONFIG_BINFMT_AOUT kernel configuration option). The a.out format has been obsolescent on Linux for about 20 years and ...


1

By the sounds of it, lld has not matched the maturity of Clang/LLVM yet, so it isn't included in the main packages. There is some confusion around the linkers in LLVM (I was quite confused myself). The rest of this answer (while not directly answering the original question) helps clear up the confusion to define what it is we are talking about! There are ...


1

Currently the LLVM apt repository states that it includes LLVM, Clang, compiler-rt, polly and LLDB. lld isn't included. Even the latest snapshot packages in Debian (which feed in to Ubuntu and are maintained by the same team as the LLVM packages) don't include lld. For now you'll need to build lld from source!


1

So everything was correctly installed. It turns out that the program expected libopcodes.so to be symlinked to the multi-arch version and not the regular version. Correcting the symlinks fixed the issue.



Only top voted, non community-wiki answers of a minimum length are eligible