Tag Info

Hot answers tagged

19

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


12

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.tc/docs/. The relevant section is on page 524 of the linked .pdf.


7

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


5

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


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


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

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

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

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


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

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

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.


1

No, you can't do that. There's no gcc pragma for compile in this way. The most similar is the Microsoft Visual C++ #pragma comment(lib, …) or #pragma comment(linker, …) [1] [2] for noting that some libraries should be included in the link procedure. Hi, GCC. How are you doing? In case you forgot, this source file you're looking at right now is written ...


1

gcc will compile C and C and C++ as C++ simply as a result of you naming the files appropriately, the preprocessor doesn't come into that. You'll need extern "C" blocks around your C declarations in your C++ files to make sure the linker can link stuff correctly, though. But what you're describing is almost never going to be helpful. If you're using a ...


1

Take @Warren Young's advice and upgrade the rest of the toolchain instead of upgrading just the linker. For Darwin 9 and later on ARM, the toolchain by CoolStar available from the BigBoss repository is recommended. The toolchain contains LLVM+Clang as a replacement for the outdated iphone-gcc, as well as LD64 and the newer Darwin CC Tools. See the ...


1

The kernel has a deb-pkg target. On debian, make deb-pkg and sudo dpkg -i'ing the two resulting packages (in ../) worked like a charm for me. I'd think it works the same on Ubuntu. On build and install, those includes wind up in the right places automagically.


1

Answers are often distribution specific, because they may have specific machinery to do this. In the case of Debian there is The Debian Linux Kernel Handbook. Since Ubuntu is essentially Debian, all of this should apply. If I understand correctly, you are asking about installing the kernel. One approach, a good one, is to build a binary package for the ...


1

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


1

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


1

From the glibc sources for ldd if (...) { /* The file has no symbol versioning. I.e., the dependent object was linked against another version of this file. We only print a message if verbose output is requested. */ ... errstring = make_string ("no version information available ..."); ... } It means "version mismatch", ...


1

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


1

If you don't want to set a global library search path for your whole system with the /etc/env.d approach, you can either: Just set the LD_LIBRARY_PATH to the PATH of your library (you did set it to the library itself, that won't work), the same which you set with the -L parameter to gcc e.g. export LD_LIBRARY_PATH="$PROJ/lib/3rdpartylib/:$LD_LIBRARY_PATH" ...



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