Click on a question number or underlined text to go to the relevant section
0) Where can I get the latest version of this FAQ ? 1) How do I tell what version of GCC I am using ? 2) Where is the latest distribution of GCC, as, ld, ar, etc.. ? 3) Where can I find the newest shared libraries libc.so and libm.so ? 4) What other shared libraries are available for Linux ? 5) How do I build a shared DLL library for Linux ? 6) Why do I get the message "PLT__oct__FUii" when I execute a certain binary ? 7) How do I build a cross compiler on platform XXX to produce code for Linux ? 8) What symbols are automatically defined by Linux's GCC ? 9) How do I get over BSD'isms (especially signals, sigvec etc..) when compiling code ? 10) Where are SIGBUS, SIGEMT, SIGIOT, SIGTRAP, SIGSYS etc ? 11) What is libhard and libsoft ? 12) What does the message "can't load library: /lib/libxxx.so, Incompatible version" mean ? 13) Why are my binaries so huge and how do I reduce them ? 14) What does the -N flag do, and when should I use it ? 15) How do I get debugging information into a program ? 16) What debuggers are available for Linux ? 17) How do I debug a daemon program ? 18) What is profiling and how do I profile a program ? 19) Is there a way to tell if a binary is linked statically or to a shared library ? 20) Does Linux have support for LD_LIBRARY_PATH ? 21) My program wants /lib/cpp ! Where can I get it from ? 22) Where are <float.h>, <limits.h>, <varargs.h>, <stdarg.h> and <stddef.h> ? 23) My program wants to include <linux/foo.h> but cannot find it, where is it ? 24) Do we have the function foo() in our libraries ? 25) How do I port program XXX to Linux ? 26) I think I have found a bug in gcc/library foo, what do I do now ? 27) Why are shared libraries so large in comparison to their static counterparts ? 28) What are .sa file I see in /usr/lib ? 29) Where can I get Objective C for Linux ? 30) What does the message "Internal compiler error: cc1 got fatal signal 11,4" mean ? 31) What is a libc-lite ? 32) Do Linux libraries have SHADOW Password support, and how do I switch it on/off ? 33) Can't find math.h routines ! My program compiles but cannot find log(), sin(), etc.., HELP !! 34) Is there a manual for GCC? If so, where do I get it, and how do I print it out ? 35) I get the message "Undefined symbol _bsd_ioctl". Where is this anyhow ? 36) If I upgrade versions, can I get rid of the old stuff from /usr/lib/gcc-lib/i[34]86-linux/<old-version> ? 37) [HELP] where is libipc.a ? Needed for dosemu 0.49.. 38) XXX won't compile: _daemon undefined, help !! 39) [HELP] ar and libraries. Linking fails although symbol appears in library. 40) HELP! newbie gets warning message "libc.so.4: incompat. minor ver no." 41) Where can I find `lint' to check my c programs before compilation ? 42) My program needs sgtty.h where is it ? 43) How do I stop or start core files being produced by SIGSEGV's ? 44) What does the message "can't load dynamic linker `/lib/ld.so'" mean ? 45) What is the difference between -O2 and -O6 optimizations ? 46) How can I check an unknown binary to see if it is a trojan horse ? 47) Where are the sources to the C library - how do I rebuild it ? 48) Where are the definitions of FD_* stuff ? 49) When linking with option -g I get undefined ___fpu_control and ___setfpucw ? 50) Where can I get the tools to internationalize my library/application ? 51) The DLL tool `mkimage' fails to find libgcc. Help!!! 52) How do I get rid of "__NEEDS_SHRLIB_libc_4 multiply defined" messages ? 53) What is this QMAGIC thing everyone is talking about ? 54) How do I generate a QMAGIC executable/library ? 55) Is it possible to turn the "warning using incompatible library version xxx" messages off ? 56) Are GNU's glibc 1.08 texinfo manual pages relevant to Linux's libc? 57) Can I sell my application if it was compiled within linux ? 58) Why do I get an "Assertion failure" message when rebuilding a DLL ? 59) Can I build DOS executables under linux ? 60) Is -fpic - i.e PIC (position independent code) supported on linux. ? 61) What is this ELF thing anyway ? 62) How do I build an ELF libc ? 63) Why does the execl() call fail on linux and just print out libc.so.4 messages ? 64) Can I preload objects with a.out binaries (a.la Sun LD_PRELOAD) ? 65) With the new gcc I cannot seem to generate ZMAGIC binaries ? 66) perl-5.00 needs dlopen() and friends. Where are they anyway ? 67) Where can I get more info about ELF ? 68) What does "ld: output file needs shared library libc.so.4" mean ? 69) Why do I get '/usr/bin/gcc:' or '/usr/bin/as: command not found' ? 70) Why can't the linker find any libraries other than those in /lib or /usr/lib ? 71) Where are stat(), fstat() gone in the ELF libs ? 72) Can someone explain what "ld: Output file requires shared library `libfoo.so.1`" means ? ============================================================================== 0) Where can I get the latest version of this FAQ ? Ans: The latest versions are posted to comp.os.linux.announce periodically, and archived at most popular Linux sites, e.g. sunsite.unc.edu:/pub/Linux/docs/faqs Other GCC, C, C++, g++, Objective-C, FAQ's may be found at rtfm.mit.edu:pub/usenet/news.answers -------------------------------------------------------------------------------1) How do I tell what version of GCC I am using ? Ans: Execute the command gcc -v to find out what version you are using. At the time of writing the above command produces on my machine Reading specs from /usr/lib/gcc-lib/i486-linux/2.7.0/specs gcc version 2.7.0 You would be well advised to upgrade to a version similar to this or above. P.S. If you get the output Reading specs from /usr/lib/gcc-lib/i386-linux/2.7.0/specs gcc version 2.7.0 you are running a gcc compiled for a 386. -------------------------------------------------------------------------------
2) Where is the latest distribution of GCC, as, ld, ar, etc.. ? Ans: The Official place for GCC distributions is tsx-11.mit.edu in /pub/linux/packages/GCC. All others sites mirror this. The latest versions of all GCC stuff will be found here. At the time of writing, the latest GCC is version for Linux is 2.7.0 and available from tsx-11.mit.edu:/pub/linux/packages/GCC/gcc-2.7.0.bin.tar.gz However this does not mean that this is the latest available version of GCC from the GNU foundation. This is just the latest *distribution*. The Linux GCC maintainer(s) have made it easy for you to compile the latest version available yourself. The configure script with GCC sources should set it all up for you. You will also need the latest include (header) files if you wish to compile stuff. At the time of writing the latest includes can be obtained with the libc package from tsx-11.mit.edu:/pub/linux/packages/GCC/libc-4.7.2.bin.tar.gz The latest `as', `ld', `ar' etc may be found in the package tsx-11.mit.edu:/pub/linux/packages/GCC/binutils-2.5.2l.17.bin.tar.gz -------------------------------------------------------------------------------
3) Where can I find the newest shared libraries libc.so and libm.so ? Ans: See question (4) below. You need the file libc-4.7.2.bin.tar.gz. Only 486 images are provided (they work also on 386's - but the image size is slightly larger). You will need to recompile the shared libraries if you want 386 libaries. See question (47) on where to obtain the source code to the linux C library. -------------------------------------------------------------------------------
4) What other shared libraries are available for Linux ? Ans: Ok here is a list I have been compiling. Any additions/changes graciously received. The locations given below were where they were last seen (or reportedly seen). They may have been moved by archive maintainers. P.S. For a more obvious description of the libraries below, their maintainers and their registered start/end address please read the `doc/table_description' file in the tools-2.17.tar.gz package. See the following question (5) on where to obtain this from. Here are the locations of currently registered DLL libraries for Linux. ====================================================================== libc.so.4 tsx-11.mit.edu:/pub/linux/packages/GCC/libc-4.7.2.bin.tar.gz libm.so included in above tar.gz file. libX11.so.3 tsx-11.mit.edu:pub/linux/packages/X11/XFree86-2.1.1/XF86-2.1.1-lib.tar.gz libXt.so.3 included in above tar.gz file. libXaw.so.3 included in above tar.gz file. libX11.so.6 sunsite.unc.edu:pub/Linux/X11/XFree86-3.1.2/a.out/X312lib.tgz libXt.so.6 included in above tgz file. libXaw.so.6 included in above tgz file. librl.so.2 sunsite.unc.edu:/pub/Linux/libs/librl-2.0.3.tar.gz libgr.so.2 sunsite.unc.edu:/pub/Linux/libs/graphics/libgr-2.0.3.tar.gz libf2c.so.0 sunsite.unc.edu:/pub/Linux/devel/fortran/libf2c-0.10.tar.gz libF77.so use libf2c.so shown above instead. libI77.so use libf2c.so shown above instead. libXpm.so.3 ftp.mrc-apu.cam.ac.uk:/pub/linux/libXpm-3.3.tar.gz libXpm.so.4 sunsite.unc.edu:/pub/Linux/libs/X/libXpm-4.6.tar.gz ftp.mrc-apu.cam.ac.uk:/pub/linux/libXpm-4.7.tar.gz libnsl.so ftp.lysator.liu.se:/pub/NYS/nys-0.27.1.tar.gz (frequent updates) libolgx.so sunsite.unc.edu:/pub/Linux/libs/xview3L5.1.tar.gz libxview.so included in above tar.gz file. libsspkg.so included in above tar.gz file. libUIT.so included in above tar.gz file. libPEX.so tsx-11.mit.edu:pub/linux/packages/X11/XFree86-2.1/XF86-2.1-pex.tar.gz libtcl.so sunsite.unc.edu:/pub/Linux/devel/tcl/ libtk.so various related tcl/tk stuff included in above tar.gz files. libWc.so Unknown libXp.so Unknown libIV.so sunsite.unc.edu:/pub/Linux/libs/X/iv3.1dist.tar.gz libUnidraw.so included in above .tgz files. libXm.so The Motif library is *not* free. See note below. libsrgp.so sunsite.unc.edu:/pub/Linux/X11/devel/suit.tpz libsuit.so included in above tpz file. (reported not shared) libOI.so tsx-11.mit.edu:/pub/linux/packages/OI/oi40.tar libOIrg.so included in above tar file. libld.so tsx-11.mit.edu:/pub/linux/packages/GCC/ld.so-1.7.3.tar.gz (required for libc 4.4.4 and above.) libarma.so ftp.atnf.csiro.au:/pub/karma libkarmaX11.so see above site libkarmaXt.so see above site libkarmagraphics.so see above site libkarmawidgets.so see above site libkarmaxview.so see above site libwxwin.so sunsite.unc.edu:/pub/Linux/X11/devel/wxWin_linux.tgz libandrew.so sunsite.unc.edu:/pub/Linux/X11/andrew/andrew61.prog.tar.gz libUil.so Commercial library. libBLT.so sunsite.unc.edu:/pub/Linux/devel/tcl/blt1.7l1-bin.tar.gz libvga.so sunsite.unc.edu:/pub/Linux/libs/graphics/svgalib-127.tar.gz libitcl.so sunsite.unc.edu:/pub/Linux/devel/tcl/itcl1.5l1-bin.tar.z ---------------------------------------------------------------------- Here are the locations of current precompiled ELF libraries for Linux. ======================================================================
libc.so.5 tsx-11.mit.edu:/pub/linux/packages/GCC/libc-5.0.2.bin.tar.gz libm.so included in above tar.gz file. libX11.so.6 sunsite.unc.edu:pub/Linux/X11/XFree86-3.1.2/elf/X312lib.tgz libXt.so.6 included in above tgz file. libXaw.so.6 included in above tgz file. libXpm.so.4 ftp.mrc-apu.cam.ac.uk:/pub/linux/libXpm-4.7.tar.gz -------- Note 1:- Drop in DLL libraries for Xaw to get a 3d effect (libXaw3d-0.6) and a Mac(TM) like scroll bar on Xaw clients are available respectively at sunsite.unc.edu:/pub/Linux/libs/X/Xaw3d-0.6C-bin.tar.gz (R5) sunsite.unc.edu:/pub/Linux/libs/X/Xaw3d-1.1-bin.tar.gz (R6) and sunsite.unc.edu:/pub/Linux/libs/X/libXaw.Scrollbar.taz Note 2:- For motif libs you have to pay bucks !! Read an extract that follows... ------------ Metro Link, Inc. is pleased to announce the availability of OSF/Motif 1.2.2 for Linux at $199 for a complete runtime and development system. Requirements: Linux 0.99pl4 or greater (currently 0.99pl12 O.K.) XFree86 1.2 or greater (1.3 O.K.) libc 4.3.3 or greater (libc 4.4 is O.K.) What is included: Runtime: 1) Motif Window Manager (mwm) 2) Shared motif library (libXm.so.1.2.2) 3) Motif demos both from OSF and from the net Development: 1) Shared+Static Motif library 2) Static Mrm and Uil libraries 3) UIL compiler 4) Motif header files 5) Manual pages for Motif function calls 6) Imakefile support 7) Source to OSF/Motif demos And your choice of any one of the X-window books published by O'Reilly & Associates, Inc. You can order OSF/Motif 1.2.2 for Linux by calling Metro Link,Inc. at (305) 970-7353 (voice) or (305) 970-7351 (fax) or by mailing us at sales@metrolink.com. ============================================================================== Metro Link Incorporated. 2213 W. McNab Rd. Pompano Beach, Florida 33069 X11.5 and OSF/Motif for QNX, SVR3, SVR4.[012], SCO, Linux, UnixWare, LynxOS, AT&T, Venix, ISC, Solaris, Pyramid, SunOS Voice: +1.305.970.7353 Fax: +1.305.970.7351 Email: mahesh@metrolink.com WATCH your: Word Action Thought Character Heart ============================================================================== -------------------------------------------------------------------------------
5) How do I build a shared DLL library for Linux ? Ans: You need to get the file tsx-11.mit.edu:/pub/linux/packages/GCC/src/tools-2.17.tar.gz from tsx-11.mit.edu, and install it. Read the README.tr in the doc subdirectory thoroughly - a lot of effort has been put into this to make it readable and possible for everyone to be able to build a shared DLL. If you find the README.tr more up to date than the README.ps, you will have to recreate it if you want a pretty Postscript version, but you *must* have groff installed. A `make README.ps' in the doc subdirectory should suffice. ** Note: the version numbers may have changed. -------------------------------------------------------------------------------
6) Why do I get the message "PLT__oct__FUii" when I execute a certain binary ? Ans: More likely than not you have a old version of the libraries, libc.so and/or you compiled a program using a incorrect version of `ld'. The solution is to get the new version of binutils package from tsx-11.mit.edu:/pub/linux/packages/GCC/binutils-2.5.2l.17.bin.tar.gz -------------------------------------------------------------------------------
7) How do I build a cross compiler on platform XXX to produce code for Linux ? Ans: Assuming you have obtained the source code to gcc, usually you can just follow the instructions given in the INSTALL file for GCC. A `configure --target=i386-linux-linux --host=XXX' on platform XXX followed by a `make' should do the trick. Note that you will need the linux includes, the kernel includes, and also to build cross assembler, and cross linker from the sources in /pub/linux/packages/GCC/src at tsx-11.mit.edu Here is an example of building a cross compiler on a Sparc (Sun) to produce code for a linux machine. This is the easy way, using linux libraries compiled by HLU that you already are using on your linux machine. For some of this I STRONGLY advise you to get GNU's make (gmake) to use for some of the compilations (binutils and gas will fail using the included Makefiles.linux with Sun's make) 7.1) Lets assume you already have a working gcc version 2.4.5 on the Sun in /usr/local/bin with all standard install paths - i.e the compilers are in /usr/local/lib/gcc-lib. First make the linux specific directories (you may need to make the intermediate directories too) up to % mkdir -p /usr/local/lib/gcc-lib/i386-linux-linux/bin % mkdir -p /usr/local/lib/gcc-lib/i386-linux-linux/2.4.5/include % mkdir /usr/local/lib/gcc-lib/i386-linux-linux/include 7.2) Start by setting some environment variables so you don't have to type long pathnames. Set this in your .login or .cshrc also as you will need to use l-ar, l-ranlib for cross compiling DLL's etc.. For the moment you can do the following In csh: % setenv LBINS /usr/local/lib/gcc-lib/i386-linux-linux/bin/ In sh: % LBINS=/usr/local/lib/gcc-lib/i386-linux-linux/bin/ % export LBINS Put *ALL* linux specific header files with all the contents of the subdirectories linux, asm, gnu, sys etc.. in ${LBINS}../include Make SURE of this. See questions (2) and (23) on where to get these from. You will have to do this each time a new kernel is released. On my linux machine sitting next to my sun I can say % rcp -r linux_machine:/usr/include ${LBINS}../ Otherwise you will need to get the includes and kernel sources, see questions (2), to achieve this. Also you will want the gnu specific files like limits.h, varargs.h, stdargs.h etc... Again from my linux machine I can say % rcp -r \ linux_machine:/usr/lib/gcc-lib/i386-linux/2.4.5/include \ ${LBINS}../2.4.5 You may have to change the i386 or 2.4.5 depending on your machine and version of gcc. 7.3) Now you have to extract and compile the cross assembler and linker: Get the following files tsx-11.mit.edu:/pub/linux/packages/GCC/src/binutils-1.9l.4.tar.gz tsx-11.mit.edu:/pub/linux/packages/GCC/src/gas-1.38.1l.2.tar.gz and extract them somewhere. 7.3.1) In the binutils dir binutils-1.9l.3: Edit Makefile.linux and change the line that has the bindir definition to have bindir=${LBINS} and the appropriate block for your machine ("sun4" in this case) line to HOST_ROOT=${LBINS}.. For 0.99pl12 (and above probably) you will have to copy a.out.h and page.h to a directory and include it in the MISCFLAGS. So in the current binutils dir, do this % mkdir linux % cp ${LBINS}../include/linux/a.out.h linux % cp ${LBINS}../include/linux/page.h linux and then edit the Makefile.linux and add -I. to the appropriate MISCFLAGS line. Then do % make -f Makefile.linux archpfx= install To be able to do l-ar, l-ranlib for the linux ar, ranlib utilities, do the following (I put the l-blah into my private ${HOME}/bin directory) % sh -c 'for i in ${LBINS}*; do \ ln -s $i ${HOME}/bin/l-`basename $i`; done' 7.3.2) *******FOR gas-1.38.1l.1******* In the the assembler directory gas-1.38.1l.1: Edit the makefile.linux file and change the appropriate lines to read the following LINUX_INCDIR= HEADERS=-DA_OUT_H=\"${LBINS}../include/linux/a.out.h\" Then type (lots of warnings will appear) % make -f makefile.linux Copy the cross assembler binary manually % cp a386 ${LBINS}as *******FOR gas-2.2 (and above)******* In the the assembler directory do % ./configure --host=sun4 --target=i386-linux-linux % make CC=gcc CFLAGS=-O2 LDFLAGS=-s 7.3.3) Finally make the two links % ln -s ${LBINS}as ${LBINS}../2.4.5/as % ln -s ${LBINS}ld ${LBINS}../2.4.5/ld 7.4) Now in the GCC source directory you extracted on your Sun do the following. % ./configure --host=sun4 --target=i386-linux-linux % make CC=/usr/local/bin/gcc CFLAGS="-O2 -s" \ tooldir=${LBINS}.. LANGUAGES="c c++ objc" This may end with an error when building the library libgcc.a, ignore it. All you want are the cross compiler binaries in this instance. 7.5) After that finishes, copy the binaries to the proper places... % cp cc1 cc1plus cpp cc1obj ${LBINS}../2.4.5 Copy the front end to the compiler to the bin directory and make a easy link somewhere (maybe your ~/bin) % cp xgcc ${LBINS}gcc % ln -s ${LBINS}gcc ${HOME}/bin/gcc-linux 7.6) Get all your libs from your linux machine % rcp linux_machine:/usr/lib/lib\*a ${LBINS}../2.4.5 % rcp linux_machine:/usr/X386/lib\*a ${LBINS}../2.4.5 % rcp linux_machine:/usr/lib/crt0.o ${LBINS}../2.4.5 7.7) That's it. Try compiling something. Lots of well written packages will let you do the following (assuming you have the path to your ${HOME}/bin set) % make CC="gcc-linux -O6 -s" RANLIB=l-ranlib AR="l-ar" 7.8) If you want to cross compile shared DLL's then you must also get tsx-11.mit.edu:/pub/linux/packages/GCC/src/tools-2.17.tar.gz Use the Makefile.cross in the tools subdirectory to compile a cross version. Change the definition at the top of the Makefile.cross to look like CROSSBINDIR=${LBINS} CROSSINCDIR=${LBINS}../include Finally change the BINDIR definition. I set it to ${LBINS}../dll/bin This will also create a ${LBINS}../dll/jump for you. Then a % make -f Makefile.cross install should do the business. -------------------------------------------------------------------------------
8) What symbols are automatically defined by Linux's GCC ? Ans: Symbols defined are `linux', `__unix__', `__i386__', `__linux__', `__unix', `__i386', `__linux'. You can get a correct list by using the flag -v to gcc whilst compilation. P.s. One should note that even though the compiler automatically defines "linux" in a program, this is *not* POSIX compliant. Instead __linux__ should be used in programs that need operating-system specific compilation, since __linux__ *is* POSIX compliant. This means you can wrap your linux specific code around (for example) #ifdef __linux__ ...[linux specific code here]... #endif /* ifdef linux */ without adding anything extra to the Makefile defines etc.. You can also add your own defines to the file /usr/lib/gcc-lib/i486-linux/2.7.0/specs or /usr/lib/gcc-lib/i486-linuxaout/2.7.0/specs if you are using the a.out compiler instead of the default ELF one. -------------------------------------------------------------------------------
9) How do I get over BSD'isms (especially signals, sigvec etc..) when compiling code ? Ans: You can compile your program with -I/usr/include/bsd and link it with -lbsd (i.e. Add -I/usr/include/bsd to CFLAGS and -lbsd to the LDFLAGS line in your Makefile). There is *no* need to add -D__USE_BSD_SIGNAL any more if you want BSD type signal behavior, as this is added automatically when you do the -I/usr/include/bsd -------------------------------------------------------------------------------
10) Where are SIGBUS, SIGEMT, SIGIOT, SIGTRAP, SIGSYS etc ? Ans: Linux is 100% POSIX compliant and these signals are not POSIX signals. As an easy way out you could redefine them to SIGUNUSED. See the definitions in /usr/include/bsd/signal.h However you should note that the lack of these signals *is* compliant with POSIX. Instead of #define'ing to them to SIGUNUSED, new programs should instead say: #ifdef SIGSYS ....[non-posix sigsys code here].... #endif for code that requires the use of SIGSYS (similarly for SIGBUS). Here is a snippet from ISO/IEC 9945-1:1990 (IEEE Std 1003.1-1990), paragraph B.3.3.1.1: "The signals SIGBUS, SIGEMT, SIGIOT, SIGTRAP, and SIGSYS were omitted from POSIX.1 because their behavior is implementation dependent and could not be adequately categorized. Conforming implementations may deliver these signals, but must document the circumstances under which they are delivered and note any restrictions concerning their delivery." -------------------------------------------------------------------------------
11) What is libhard and libsoft ? Ans: These are the libraries for the math emulation routines - the hard if you had hardware to do math (i.e. a 387), or soft if emulation of math routines was done in software. You do *not* need these libraries if you are using a current version of Linux, as math emulation is now done at kernel level - (i.e if you enabled it when you did a `make config' at kernel build time). Otherwise your 387 will do the work. You may safely remove them if your link /lib/libm.so.4 points to a libm.so.4.x.y -------------------------------------------------------------------------------
12) What does the message "can't load library: /lib/libxxx.so, Incompatible version" mean ? Ans: As shared libraries evolve it is necessary to have some sort of version numbering such that a program may be able to determine whether its execution will cause it to crash. This will happen for example if a function call has changed radically or doesn't exist. Say we have a library - libc.so.4.3.3 T T T T / / | \ / / | \ / / | \ Library name / | \ / | \ Major version no. | Patch level. | Minor version no. If the Major version no. changes, then you will only be allowed to execute a program if the Major version number of the current library you are running matches that with which the program was linked with. This means if your program is compiled when you had libc.so.4.3.3 you will not be able to execute it if you get a more recent version of the DLL library, say libc.so.5.1.2. I.e it is no use attempting to create a link from libc.so.5.1.2 to libc.so.4 if your program requires libc.so.4. The Minor version no. is as name suggests, an indication that a minor change has undergone in the shared DLL library, maybe just a new addition of a function, and shows that backward compatibility is still retained. If you attempt to use a library whose minor version number is smaller than what the binary was originally compiled with then a warning to this effect will ensue, but normal execution should still be possible. The Patch level no. may be left out totally from the numbering convention. It is usually used just for a typo or small bug fix in the library code. So getting back to the question, it usually means that you are trying to run a binary and you don't have the correct library(ies) installed on your system. To rectify the situation get the latest libs - See questions (3), (19). -------------------------------------------------------------------------------
13) Why are my binaries so huge and how do I reduce them ? Ans: If you want smaller binaries there are a number of things you can do. * Optimize the code - Use the -O2 flag when compiling, * Strip the resultant binary - Use the -s flag at the ld stage. * Make the binary impure - Use the -N flag at the ld stage. * Make the binary QMAGIC - Use the -qmagic flag at the ld stage - See question (53) for building QMAGIC executables. A combination of any/all of these may be used. If you want to strip a binary, but don't have the source handy to use the "-s" flag with ld. You can also use the "strip" command. See "man strip" for more information. The linker `ld' will choose by default to link your program to the shared libraries. However if it doesn't find the relevant stubs (i.e. the .sa files, see question (28)) *OR* if the these files are unreadable by the user then it will attempt to link static (i.e. to the .a files). This may be a reason why your binaries are so huge. The search path it looks for these .sa and .a libraries are /usr/lib, then /lib and then /. This means you may intersperse the stubs and DLL shared libs anywhere in these directories. More flexibility will soon be available - See also question (20). Also many of the FSF authors believe that we want to debug their programs, and leave the -g option in their Makefiles. The result is that large amounts of debugging symbols are left in and the program is linked statically. Check the Makefile carefully to make sure -g has been removed from either the CFLAGS and/or the LDFLAGS if you are compiling software and you are satisfied with it's operation. Note with newer `ld' executables QMAGIC is the default for the a.out format. -------------------------------------------------------------------------------
14) What does the -N flag do, and when should I use it ? Ans: A demand paged binary can be swapped. If you use the -N option you get an impure executable file which does not have its various segments padded out to page boundaries. Linux can optimize the swapping of sharable (clean) pages by simply "forgetting" them - because it can always reload them directly from the file. Otherwise, it has to physically write them into the swap partition or swap file - which needs some time and uses up disk space. This is usually irrelevant for very small programs, which is why they are often compiled with -N. Large programs (eg. gcc or emacs), or programs which are likely to have multiple instances (like the shell or xterm), should be compiled without -N so that their code pages can be shared cleanly. If you start to run out of memory, the kernel can start to delete unused code pages from demand page executables as they can always be reloaded later. This is impossible for impure executables. So, if your program is likely to use significant amounts of memory, then don't use -N or the kernel's memory management will be obstructed. Clearly `one-off' programs can all be compiled using this flag - i.e. anything which doesn't stay for long periods of time in memory, say for example hostname, fsck, mkfs, w, etc.. Do *not* use the -N flag on daemons, which by nature are meant to be resident in memory. -------------------------------------------------------------------------------
15) How do I get debugging information into a program ? Ans: You need to compile your program (i.e. all objects) and also link it with the -g flag on - in other words compile *everything* with -g. Debugging still works with -g on for some files only (the ones, which are buggy). More important than using the -g flag is to *not* use the -fomit-frame-pointer flag, as it cheats `gdb' severely. Unfortunately, the shared libs are usually compiled with -fomit-frame-pointer for performance. Therefore, it is wise to give the -g or the -static flag to the linker, to link with the non-shared libs, when debugging. If you fail to do so, you are usually unable to do a backtrace, when you are caught with a segmentation violation in a system routine. If you end up at the linker stage with a message like Can't find libg.a then you need to get it from the file tsx-11.mit.edu: /pub/linux/packages/GCC/extra-4.6.27.tar.gz However enough debugging information may be gleaned by simply doing % cd /usr/lib; ln -s libc.a libg.a on your linux machine. However, you will not be able to debug any of the library calls unless you use the full libg.a (~2.7Mb). Make sure *NOT* to strip the binary if you want to perform debugging. -------------------------------------------------------------------------------
16) What debuggers are available for Linux ? Ans: Well of course, the best debugger available ever is `gdb'. Look for it at your favorite site. Eg: prep.ai.mit.edu:/pub/gnu/gdb-4.13.tar.gz A Linux precompiled version may be found at: sunsite.unc.edu:/pub/Linux/devel/debuggers/gdb-4.12-bin.tar.gz or sunsite.unc.edu:/pub/Linux/Incoming/librl-2.0.3.tar.gz An X debugger based on this, (i.e. you need gdb installed first), is also available. The source may be found at ftp.x.org:/contrib/xxgdb-1.08.tar.gz Also, the UPS debugger has been ported by Rick Sladkey. It runs under X as well, but unlike xxgdb, it is not merely an X front end for a text based debugger. It has quite a number of nice features, and if you spend any time debugging stuff, you probably should check it out. The Linux precompiled version and patches for the stock UPS sources can be found at: sunsite.unc.edu:/pub/Linux/devel/debuggers/ups-2.45.2-linux-0.1.tar.gz You will need to get the full sources from your nearest X archive or ftp.x.org:/contrib/ups-2.45.2.tar.Z if you wish to rebuild it yourself -------------------------------------------------------------------------------
17) How do I debug a daemon program ? Ans: Simply put, you have to get the daemon program not to fork before you can debug it. However using the debugger `gdb' you can attach to the daemon even *after* it has forked. You do this by telling gdb the process id no. that you want to debug. Use the `attach' command to do this. GDB's integrated online help is useful here. Also if you are not in possession of the source, and the binary is stripped you can obtain the program `strace', attach it to the daemon process id and examine the output produced. This can be useful if you know what you are looking for. Look in sunsite.unc.edu:/pub/Linux/devel/strace/strace-3.0.tar.gz -------------------------------------------------------------------------------
18) What is profiling and how do I profile a program ? Ans: Profiling is a way to examine where and which functions time is being spent on, the number of calls made to a certain function and total execution times. It is a good way to optimize code and look at where time is being unnecessarily wasted. To enable profiling all objects and linking must be compiled with the -p flag. See question (15) on where to get the libraries necessary for profiling. To actually get a graph profile you need also the program `gprof'. You will find it included in the binutils package. Again, find it at your favorite Linux archive site. Eg: tsx-11.mit.edu:/pub/linux/packages/GCC/binutils-2.5.2l.17.bin.tar.gz -------------------------------------------------------------------------------
19) Is there a way to tell if a binary is linked statically or to a shared library ? Ans: Yes. Use the utility `ldd'. This gives you information on what libraries are required. If no output is generated when you run `ldd' on a program then it indicates the program was linked statically. Eg (1): the command (on my linux system) % ldd /bin/init gives no output meaning init was linked statically. And a good thing too it was linked statically :-) (NOTE: For programs linked with libc.so.4.5.19 and above, the message "statically linked" will be output in this case). For statically linked ELF executables you will get the message "statically linked (ELF)". Eg (2): the command (on my linux system) % ldd /usr/bin/gs i.e. the ghostscript interpreter gives the following output. libm.so.4 => /lib/libm.so.4.4 (4.0) libX11.so.3 => /lib/libX11.so.3.0 (DLL Jump 3.0pl0) libc.so.4 => /lib/libc.so.4.4 (DLL Jump 4.3) This tells me that the program `gs' was dynamically linked and requires three shared libraries. The numbers in brackets tell me that only one library, (libX11), matches the current version of the library I have when the program was compiled. When `gs' was compiled the math library, (libm), I had was version 4.0 and not a DLL library, but it will happily run with my 4.4 DLL shared version. Similarly my current c library, (libc), is a version greater that when I compiled `gs'. For dynamically linked ELF executables you will get a messages like (paths may be different) Linux ELF dynamic linker: gs: file loaded: /usr/X386/lib/libX11.so.4 Linux ELF dynamic linker: gs: file loaded: /usr/lib/libm.so.4 Linux ELF dynamic linker: gs: file loaded: /usr/lib/libc.so.4 Note: For ELF executables you MUST be using a `ldd' or `ldconfig' from the ld.so package (See question (4)) version 1.5.0 or greater for this to work. -------------------------------------------------------------------------------
20) Does Linux have support for LD_LIBRARY_PATH ? Ans: Yes and No, depending on the version of libc your binary was originally compiled with. * Initially LD_LIBRARY_PATH was supported with libraries > than 4.3.3. I.e. the __load.o routine in your stub (/usr/lib/libc.sa) was replaced to cater for this. With binaries compiled using libc version less than 4.4.4, linux's dynamic linker contains the loader as a static object in the form of __load.o which appears in the libc.sa stub and automatically gets linked into every binary you build. This means that changes to __load.o take a very long time to propagate and appear in every single binary. So to answer the question: Yes, it is supported if anything is compiled using library versions greater that 4.3.3, (libc.so.4.3.4 and above), but the upshot is that you will not notice it unless you recompile *all* your binaries. * With libc version 4.4.4 and above, the dynamic loader was in fact made dynamic and loads and unloads itself after searching and locating the required libraries. The upshot of this is that binaries are smaller and any changes to the dynamic loader/linker are isolated from libc. You will need to read the manpages to ld.so and ldconfig from the ld.so package. See question (4) under libld.so. Linux's LD_LIBRARY_PATH is very security concious, and do NOT expect it to work the way Sun-OS do it or the way you'd like it to. Primarily the difference with Sun-OS's LD_LIBRARY_PATH use is the fact that during compilation (linking) stage, the LD_LIBRARY_PATH is parsed to find valid libraries to link to and these are *recorded* within the incomplete binary produced. Hence at runtime the binary knows where to look for the shared libraries before it looks up LD_LIBRARY_PATH, (and often it never parses LD_LIBRARY_PATH at all, as it finds the shared libraries first in the recorded path), thus reducing overhead. Linux on the other hand does NOT record this information, but instead searches at runtime (execution) for libraries it needs to link to. When a binary is executed on Linux it first searches /usr/lib, then /lib and then / for a library to runtime link to if you do *not* have any LD_LIBRARY_PATH. This can be referred to as the "trusted search path". Note that / is not really a search path, but was put in for backward compatibility as some users were building shared DLL's using names like "/lib/libfoo.so" so uselib() would now do (1) uselib("/usr/lib//lib/libfoo.so.x") ---- fails (2) uselib("/lib//lib/libfoo.so.x") ---- fails again (3) uselib("//lib/libfoo.so.x") ---- succeeds.!! So don't actually put your DLL's in / :-) Now if you *do* have a LD_LIBRARY_PATH and you are root, (user with uid 0), then LD_LIBRARY_PATH is searched followed by the trusted search path. If on the other hand you are a normal user, (uid != 0), and the binary to be executed is a suid executable, then the libc.so.x and necessary libraries are force loaded from somewhere in the trusted search path. The LD_LIBRARY_PATH is ignored, (in fact reset totally). This stops a normal user from emulating his own, for example, setuid() calls from a libc library (s)he created. Finally if you are a normal user and the binary to be executed is a "normal" binary, then LD_LIBRARY_PATH is searched first for the libraries required. If the library is NOT found in the user's LD_LIBRARY_PATH then the search path is set to the "trusted search path" and the search carries on. This gets over the problems of incorrect/silly LD_LIBRARY_PATH settings and still allows these kind of nubile users to execute binaries. -------------------------------------------------------------------------------
21) My program wants /lib/cpp ! Where can I get it from ? Ans: cpp appears in /usr/lib/gcc-lib/i486-linux/2.6.2 (the gcc version numbers may have changed when you read this) You need to do the following % cd /lib; ln -sf /usr/lib/gcc-lib/i486-linux/2.6.2/cpp ** Change the 2.6.2 to whatever version of GCC your are using. ** Change the i486 to i386 if using the 386 compiler A possible alternative is this: % cat > /lib/cpp #!/bin/sh exec cc -E "$@" Ctrl-D[EOF] % chmod 755 /lib/cpp This way /lib/cpp won't stop working when you switch to a newer gcc version and delete the old one. However the former command (i.e the link) will read from stdin, while the latter will complain about a missing filename argument (unless you explicitly specify - as stdin). Any program that uses /lib/cpp as a filter without any arguments will therefore fail. For example "xrdb" won't work (the error is silently ignored). Because of these differences, it is advisable to remember to update the link instead. -------------------------------------------------------------------------------
22) Where are <float.h>, <limits.h>, <varargs.h>, <stdarg.h> and <stddef.h> ? Ans: These files depend on the version of your compiler. Therefore they are hidden in a compiler directory. /usr/lib/gcc-lib/i486-linux/2.6.2/include ** Change the 2.6.2 to whatever version of GCC your are using. ** Change the i486 to i386 if using the 386 compiler -------------------------------------------------------------------------------
23) My program wants to include <linux/foo.h> but cannot find it, where is it ? Ans: As some of the includes are kernel version dependent, they are thus kept along with the kernel releases. You need to get the latest kernel sources, unpack them and then make appropriate links. If say you unpacked the kernel source in /usr/src such that you have a /usr/src/linux directory, then you should do the following: % cd /usr/include % ln -sf /usr/src/linux/include/linux % ln -sf /usr/src/linux/include/asm The MCC release does not initially have these links, and hence one can install a new kernel source tree, and still be using the old include files. Watch out for this. -------------------------------------------------------------------------------
24) Do we have the function foo() in our libraries ? Ans: An easy way to check out whether a function is supported in a certain library is to do the following, say you are unsure whether flock() is supported ... % nm /usr/lib/libc.a | grep flock If you get something like 00000000 T flock flock() is defined in libc.a/libc.sa. If you only get lines like 00000000 U flock it only indicates a reference to flock(). The `U' means that flock is defined elsewhere and you need to include the library where it is defined such that the reference can be resolved. -------------------------------------------------------------------------------
25) How do I port program XXX to Linux ? Ans: Gone are the days when one had to `port' a program to Linux. These days if something hasn't been ported to Linux then it is not worth having :-) Seriously though, in general only minor changes are needed to the sources to get over Linux's 100% POSIX compliance. It is also worthwhile passing back any changes to authors of the code such that in the future only `make' need be called to provide a working executable. One of the most frequent problems is that some common functions are defined as macros in Linux's header files and the preprocessor will refuse to parse similar prototype definitions in the code. Common ones are atoi() and atol(). There is another common problem: "sprintf(string, fmt, ...)" returns a pointer to string on most unixes, while linux returns the number of characters, which were put into the string. Other problems tend to arise from the fact, that GCC is an ANSI compiler. Most important changes are for the preprocessor. Adding the option: -traditional is often the only (but poor) solution. +---------------------------------------------------------------+ | Some other worthy comments are noted below from Bruno Haible: | +---------------------------------------------------------------+ This is an attempt to describe some of the problems that may arise when porting Unix software to Linux. We assume the software is written in C. Linux (i.e. its system calls and C library functions) is as closely POSIX compliant as possible. This makes this list very short. Problem 1: The select() timeout ------------------------------- Symptom: A program that should only poll for input becomes a CPU hog. Problem: The select() system call. The timeout parameter was classically used read-only by the system. Some manual page already noted three years ago: select() should probably return the time remaining from the original timeout, if any, by modifying the time value in place. This may be implemented in future versions of the system. Thus, it is unwise to assume that the timeout pointer will be unmodified by the select() call. If you do not take this advice seriously you get a zero timeout written back to your timeout structure, which means that future calls to select() using the same timeout structure will immediately return. Fix: Put the timeout value into that structure every time you call select(). Change code like struct timeval timeout; timeout.tv_sec = 1; timeout.tv_usec = 0; while (some_condition) { select(n,readfds,writefds,exceptfds,&timeout); } to struct timeval timeout; while (some_condition) { timeout.tv_sec = 1; timeout.tv_usec = 0; select(n,readfds,writefds,exceptfds,&timeout); } Problem 2: Interrupted system calls ----------------------------------- Symptom: When a program is stopped using Ctrl-Z and then restarted - or in other situations that generate signals: Ctrl-C interruption, termination of a child process etc. - it complains about "interrupted system call" or "write: unknown error" or things like that. Problem: The system call the program was executing has been interrupted to process the signal, and then it returned -1 and set errno = EINTR. The program then was likely to draw bad conclusions from that. Explanation: Your program has signal handlers installed (using signal(), sigaction() or sigvec()). The signal occurred, and your signal handler was invoked. In other Unix systems, this usually happens asynchronously or in a few slow system calls: When a signal is caught during the execution of system calls such as read(2), write(2), open(2) or ioctl(2) on a slow device (such as a terminal, but not a file), during a pause(2) system call or a wait(2) system call that does not return immediately because a previously stopped or zombie process already exists, the signal-catching function is executed and the interrupted system call then returns a -1 to the calling process with errno set to EINTR. Linux (following POSIX) checks for signals and may execute signal handlers * asynchronously (at a timer tick), * on return from *any* system call, * during the execution of the following system calls: select(), pause(), connect(), accept(), read() on terminals or sockets or pipes or /proc files, write() on terminals or sockets or pipes or line printer, open() on FIFOs or PTYs or serial lines, ioctl() on terminals, fcntl() with command F_SETLKW, wait4(), syslog(), any TCP or NFS operations. [For other operating systems you may have to include the system calls creat(), close(), getmsg(), putmsg(), msgrcv(), msgsnd(), recv(), send(), wait(), waitpid(), wait3(), tcdrain(), sigpause(), semop() to this list.] In the last two cases and assuming the program's signal handler returns, the system call returns -1 and sets errno to EINTR. If the SA_RESTART flag is set for the corresponding signal, however, in most cases the system call is automatically restarted (continued) after execution of the signal handler, and your program won't see any EINTR. You may ask why this is not the default behaviour. This is because returning and setting EINTR is more powerful: it gives your program the opportunity to immediately react on every signal it receives. System calls are no longer "dark tunnels". Note that in some versions of BSD Unix the default behaviour is to restart system calls. To get system calls interrupted you have to use the SV_INTERRUPT or SA_INTERRUPT flag. You may choose between two fixes. Fix 1: For every signal handler that you install, add SA_RESTART to the sigaction flags. For example, change signal (sig_nr, my_signal_handler); to signal (sig_nr, my_signal_handler); { struct sigaction sa; sigaction (sig_nr, (struct sigaction *)0, &sa); #ifdef SA_RESTART sa.sa_flags |= SA_RESTART; #endif #ifdef SA_INTERRUPT sa.sa_flags &= ~ SA_INTERRUPT; #endif sigaction (sig_nr, &sa, (struct sigaction *)0); } Note that while this applies to most system calls, you must still check for EINTR on read(), write(), ioctl(), select(), pause(), connect(). Here are two examples for read() and ioctl(), Original piece of code using read() int result; while (len > 0) { result = read(fd,buffer,len); if (result < 0) break; buffer += result; len -= result; } becomes int result; while (len > 0) { result = read(fd,buffer,len); if (result < 0) { if (errno != EINTR) break; } else { buffer += result; len -= result; } } and; Original piece of code using ioctl() int result; result = ioctl(fd,cmd,addr); becomes int result; do { result = ioctl(fd,cmd,addr); } while ((result == -1) && (errno == EINTR)); Some noteworthy differences between GCC and other C compilers: ------------------------------------------------------------- GCC doesn't allow several library functions such as mktemp(3) to be called with a constant string. This is not a bug, but a design decision from the GNU project. Constant strings are stored in the text area of the binary (saving space, memory, and forcing good coding practice) and can't be changed during runtime. There are three solutions to this problem: 1) Compile your program with `-fwritable-strings' This allows storage of string constants in the writable data segment (and it doesn't uniquize them). This is for compatibility with old programs which assume they can write into string constants. The option `-traditional' also has this effect. Writing into string constants is a very bad idea; "constants" should be constant. 2) Compile with `-traditional' as mentioned above. `-traditional' has quite a few other (bad) effects as well. See the GCC Info page for more (`info gcc' on the shell command line). 3) Don't use a constant by changing the program to write your constant string into a string pointer with strcpy (or something equivalent). -------------------------------------------------------------------------------
26) I think I have found a bug in gcc/library foo, what do I do now ? Ans: Have you really ? Well first try and narrow the code down to a few lines and see if the program still fails/doesn't work as expected. Does the same behavior occur both with a static and shared version ? (i.e. is it a problem with the DLL libs, or the static libs) Have you access to another platform running gcc ? In other words is the problem a GCC one as opposed to a Linux/GCC one ? If so you may want to post to one or more of the relevant USENET newsgroups gnu.gcc.bug, gnu.gcc.help, gnu.g++.help, comp.lang.c, or comp.lang.c++. Is the problem in the math emulator ? If so you could email Bill Metzenthen (apm233m@vaxc.cc.monash.edu.au) the writer of the emulator code. Finally you could try emailing linux-bugs@sunsite.unc.edu, myself (mitch@Dubai.Sun.COM) or even HLU. -------------------------------------------------------------------------------
27) Why are shared libraries so large in comparison to their static counterparts ? Ans: Shared libraries reserve space for future expansion in the form of `holes' which can be made to take no disk space. A simple `cp' call or using the program `makehole' will achieve this. With a.out DLL's you can also strip them after building as the address's are in fixed locations. Do not attempt to strip ELF libraries. -------------------------------------------------------------------------------
28) What are .sa file I see in /usr/lib ? Ans: The .sa files are the stubs to the shared DLL libraries and contain all exported data from a certain library, and pointers to functions required for run time linking. See also question (13). An ELF library does not have a corresponding stub as all the exported data is in the shared object. -------------------------------------------------------------------------------
29) Where can I get Objective C for Linux ? Ans: Objective C is in releases of gcc for Linux versions gcc-2.4.0 and above. This is not currently fully tested at the moment. The latest version may be obtained from tsx-11.mit.edu:/pub/linux/packages/GCC/gcc-2.6.2-p2.tar.gz -------------------------------------------------------------------------------
30) What does the message "Internal compiler error: cc1 got fatal signal 11,4" mean ? Ans: Gcc is probably the biggest memory hog you're likely to run on your machine and it will surely eat up a lot of your RAM. Usually a fatal signal 11 will mean some sort of parity errors in your RAM or other hardware faults. I had this once when `cc1' got corrupted due to a race condition and bad blocks on my hard disk. There have also been reports that overheating chips, (not french fries), can also produce such errors. And watch for poor IDE controller/drive combos that are being run faster than the standard 8MHz AT bus clock. These can give the same errors by causing corruption of the swap space. Usually, a signal 11 (segmentation violation) means that a process tried to access memory out of its process space, or tried to write into a read-only location. Sometimes, this signal is caused by software bugs, not by hardware faults (or your system would hang repeatedly, because the same thing happened to the kernel). With gcc 2.3.3, some people could reproduce a lot of "signal 11"'s. A "fatal signal 4" has been reported to be generated due to lack of memory (happened on a 4MB system). Also it can mean a failure in one of the `ld' or `as' stages. Try recompiling whatever with a -v flag to gcc and see if it is failing in one of the cc1, cpp, as or ld stages possibly. -------------------------------------------------------------------------------
31) What is a libc-lite ? Ans: A libc-lite is a light-weight version of the libc library built such that it will fit on a floppy and suffice for all of the most menial of UNIX tasks. It does *not* include curses, dbm, termcap etc code. If your /lib/libc.so.4 is linked to a lite lib, you are advised to replace it with a full version. See question (3) on where it is available from. -------------------------------------------------------------------------------
32) Do Linux libraries have SHADOW Password support, and how do I switch it on/off ? Ans: Yes. You need to compile programs with the defines SHADOW_PWD in place, and link it with the shadow library - available separately in: sunsite.unc.edu:/pub/Linux/system/Admin/shadow-3.3.1.tar.gz This means adding -DSHADOW_PWD to the CFLAGS line in the Makefile, and -lshadow in the LDFLAGS line. You may also have to change the source a bit, as the "crypt()" in the shadow support is implemented as a macro and not a function. Hence any "extern int crypt()" may trip it up. This means that there is NO WAY of switching shadow password'ing on/off without having to compile *all* necessary binaries which use the getpwent(), setpwent() etc routines. NOTE: At some point in the future the shadow routines may be integrated into the standard C library. -------------------------------------------------------------------------------
33) Can't find math.h routines ! My program compiles but cannot find log(), sin(), etc.., HELP !! Ans: When you compile a program using certain functions, you *must* also link the program to the appropriate library. This means for math functions you have to include libm.a at the linker stage, i.e. add -lm to the LDFLAGS, for curses functions add -lcurses, for dbm functions add -ldbm etc... Always put the -lm flag after the objects. So this is no good: % gcc -lm -o math_prog math_prog.c as the math functions will not be resolved. Instead do: % gcc -o math_prog math_prog.c -lm -------------------------------------------------------------------------------
34) Is there a manual for GCC? If so, where do I get it, and how do I print it out ? Ans: There is a file on sunsite in the GCC directory sunsite.unc.edu:/pub/Linux/GCC/gcc-man.tar.z This file contains the man pages cccp.1, cpp.1, g++.1 and gcc.1. If you want a full printed manual for GCC, then you will have to get the full source from your local ftp site that carries GCC and other FSF goodies. You will require TeX to make the manual from the GCC source distribution. If it is the library function calls you are looking for, then you need to get the full source for glibc. This will be on the same ftp archive that you found the sources for GCC. Again, you will need TeX to generate the manual. Be warned that this manual is about 900 pages long. Save a tree and keep it online as a dvi file. Both of the above packages also come with "info" files, that can be viewed using Gnu info, xinfo, or emacs. "info" files are a hyper- text based information system. -------------------------------------------------------------------------------
35) I get the message "Undefined symbol _bsd_ioctl". Where is this anyhow ? Ans: You forgot to include the bsd library /usr/lib/libbsd.a into your program at the linking stage. Solution: Add -lbsd to the Makefile LDFLAGS line. (or add it manually if it doesn't have a LDFLAGS line) -------------------------------------------------------------------------------
36) If I upgrade versions, can I get rid of the old stuff from /usr/lib/gcc-lib/i[34]86-linux/<old-version> ? Ans: Well unless you are testing gcc releases it is fairly safe to get rid of any older versions in that directory. You can compile with older versions of gcc using "gcc -V <old-version> -------------------------------------------------------------------------------
37) [HELP] where is libipc.a ? Needed for dosemu 0.49.. Ans: The Inter Process Communication (IPC) functions are included as standard in libc as of libc.so.4.4.1. This means if you have libc.so.4.4.1 and above, you do not need -lipc and can remove this line from the Makefile. If you do not have libc.so.4.4.1 and its related stub libc.sa then you need to upgrade you libraries. -------------------------------------------------------------------------------
38) XXX won't compile: _daemon undefined, help!! Ans: daemon() is in libbsd.a. Just add -lbsd to your Makefile LDFLAGS line. -------------------------------------------------------------------------------
39) [HELP] ar and libraries. Linking fails although symbol appears in library. Ans: There is a known bug in `ar' where sometimes `ranlib' does not generate a correct table. This can be worked around with the commands % ar -dv libfoo.a __.SYMDEF % ranlib libfoo.a -------------------------------------------------------------------------------
40) HELP! newbie gets warning message "libc.so.4: incompat. minor ver no." Ans: You need a shared library upgrade. See questions (12), (3) and (55) for more details. -------------------------------------------------------------------------------
41) Where can I find `lint' to check my c programs before compilation ? Ans: There is no `lint' or the likes for checking programs. Instead use the plethora of gcc options for checking your programs. Read the manual pages for the variety options. The most useful % gcc -Wall foo.c will warn you of most of the possible problems that might occur. Alternatively a PD lint is available from larch.lcs.mit.edu:/pub/Larch/lclint -------------------------------------------------------------------------------
42) My program needs sgtty.h where is it ? Ans: It is in /usr/include/bsd directory. So just add the line -I/usr/include/bsd to your CFLAGS line in the Makefile when compiling. -------------------------------------------------------------------------------
43) How do I stop or start core files being produced on SIGSEGV's ? Ans: This is not really a GCC question, but more a shell one. Anyhow to stop core files being produced totally: In C-shell `csh' (tcsh) % limit core 0 In Bourne shell `sh' (bash) % ulimit -c 0 To start corefiles when you receive signal 11 (SEGV): In C-shell `csh' (tcsh) % limit core unlimited In Bourne shell `sh' (bash) % ulimit -c unlimited -------------------------------------------------------------------------------
44) What does the message "can't load dynamic linker `/lib/ld.so'" mean ? Ans: This means you haven't installed the dynamic linker/loader. See question (4) under libld.so on where to obtain this from. -------------------------------------------------------------------------------
45) What is the difference between -O2 and -O6 optimizations ? Ans: Nothing at present. If you look at the source code for GCC (eww! yuck!) with an i386/i486 host/target, you will see that -Ox for x>=2 does the same thing. In fact it is a bad thing to use x>2 in your Makefiles, because if GCC implements -O3 on Intel targets in the future, it may be an optimization that breaks your code. -------------------------------------------------------------------------------
46) How can I check an unknown binary to see if it is a trojan horse ? Ans: First, if you are worried that it is going to hose your machine, *don't* run it. (At least not as root!) Try and find the source and recompile it. Other than that, you might be able to get some information on it by typing "strings <filename> | less". If you are game enough to run it, you can use `strace' to see if it is doing anything nasty. See question (17) on its whereabouts. -------------------------------------------------------------------------------
47) Where are the sources to the C library - how do I rebuild it ? Ans: For a.out (DLL) library source, look in tsx-11.mit.edu:/pub/linux/pagkages/GCC/libc-4.7.2.tar.gz For ELF library source (libc.so.5.x) look in tsx-11.mit.edu:/pub/linux/pagkages/GCC/libc-5.0.9.tar.gz If you want shared libraries you will also need the dll tools package. See question (5) on where to obtain this from. To rebuild, unpack the sources, make sure you have the corresponding include files for that version of the C library, and then under libc-linux directory do the following % ./configure Answer all the questions at this point. If you are building on a native linux machine (i.e not cross-compiling) you can just type <return> at this point (i.e. accept the default values). Then type % make NOTE: If you are cross-compiling, it is probably a wise idea to keep a copy of the configure generated file `config.in' for future use. You can just copy the old version into the libc-linux directory and type `make'. -------------------------------------------------------------------------------
48) Where are the definitions of FD_* stuff ? Ans: Just include <sys/time.h> and these macros will be included. -------------------------------------------------------------------------------
49) When linking with option -g I get undefined ___fpu_control and ___setfpucw ? /usr/lib/crt0.o Undefined symbol ___fpu_control reference from text segment. /usr/lib/crt0.o Undefined symbol ___setfpucw reference from text segment. what's wrong? Ans: You have updated your crt0.o libc.sa and libc.a from a recent copy of the linux libc, but you have still an old libg.a around. If you really want to get a static binary (this is implied by -g) with a debug library, you should get and install libg.a. See question (15) on the whereabouts of this. -------------------------------------------------------------------------------
50) Where can I get the tools to internationalize my library/application ? Ans: Get the file sunsite.unc.edu:/pub/Linux/utils/nls/cat-pack.tar.gz and follow the instructions there. User contributed catalogs in various languages may be found in sunsite.unc.edu:/pub/Linux/utils/nls/catalogs and placed in the Incoming directory under there. NOTE: Internationalization tools and functions are only available in libraries greater than version 4.4.4 (i.e. libc.so.4.5.x and above) NOTE: In this context `Internationalization' is used loosely and as of linux pl14 supports only Latin-1/ISO-8859-1 (european) and KOI-8 (russian) locales. -------------------------------------------------------------------------------
51) The DLL tool `mkimage' fails to find libgcc. Help!!! Ans: As of libc.so.4.5.x and above, libgcc is no longer shared. Hence you must replace occurrences of `-lgcc' on the mkimage line with `gcc -print-libgcc-file-name` With the backquotes intact. -------------------------------------------------------------------------------
52) How do I get rid of "__NEEDS_SHRLIB_libc_4 multiply defined" messages ? Ans: As of libc.so.4.5.x and above, libgcc is no longer shared. Thus you MUST delete all /usr/lib/libgcc* files. % rm -f /usr/lib/libgcc* -------------------------------------------------------------------------------
53) What is this QMAGIC thing everyone is talking about ? Ans: QMAGIC is an executable format just like your standard a.out (which are ZMAGIC) binaries, but which leaves the first page unmapped. This allows for easier NULL dereference trapping as no mapping exists in then range 0-4096. As a side effect your binaries are nominally smaller as well (~1K). Your `file' command will be able to identify a QMAGIC binary if the proper entry has been added to your /etc/magic file. I have distributed suitable entries to most channels. -------------------------------------------------------------------------------
54) How do I generate a QMAGIC executable/library ? Ans: You need the latest `ld' binary or patches to the source to be able to generate QMAGIC executables. This will be distributed in the `binutils-2.5.2l.17.bin.tar.gz' file - See question (2). To build a QMAGIC executable: Add one of the following to your LDFLAGS line in the Makefile LDFLAGS = -Wl,-qmagic or LDFLAGS = -Xlinker -qmagic To build a QMAGIC library: Supported with the `mkimage' tool from the tools-2.17.tar.gz package onwards you may use the "-qmagic" flag to the linker on the "mkimage" command line. Note that with newer versions of `ld', QMAGIC is the default a.out format. ZMAGIC executables are no longer supported (although they will succesfully run). -------------------------------------------------------------------------------
55) Is it possible to turn the "warning using incompatible library version xxx" messages off ? Ans: Yes. If you have ld.so version 1.4 and above you may set the environment variable LD_NOWARN to suppress warning messages. Note: fatal mesages are still output. In csh (tcsh): setenv LD_NOWARN In sh (bash): export LD_NOWARN=true -------------------------------------------------------------------------------
56) Are GNU's glibc 1.08 texinfo manual pages relevant to Linux's libc? Ans: Yes, except for the stdio internals. -------------------------------------------------------------------------------
57) Can I sell my application if it was compiled within linux ? (a) It is legal to sell your applications. You may take as much money as you want. (b) Simply using a GNU tool to develop your application does not affect your copyright to your applications. This includes using g++ and gcc. (c) However, your copyright is affected if you include code from other GNU applications into yours. In this case, you have to put the resulting ("derived") work under the GNU copyleft. That means, that you have to release source code upon request, and that your customer(s) may distribute (and/or sell!) copies of your source code and/or binary. (d) 99% of all C programs written are linked against the C library. Linking means, that you include GNU code into your program. However, the C library is released under special terms (GNU Library Public License, GLPL), which allows linking as an exception to what is said in c). You can link with the C library at will, but you have to provide your program in a form, that the user can update the library. In case of shared linking, this is not a problem, but if you want (or must) link with static libraries, you must provide your program in a form, which has not yet been linked with the static library (say, link all your .o-files into one big .o using "ld". Take a look at the kernel sources to see how it works). (e) What is said at point a) is always true: you may sell your application, whether or not it has to be distributed under the GNU copyleft, for as much money as you want. -------------------------------------------------------------------------------
58) Why do I get an "Assertion failure" message when rebuilding a DLL ? Ans: This cryptic message most probably means that one of your jump table slots has overflowed because too little space has been reserved in the original jump.vars file. You can locate the culprit(s) by running the `getsize' command provided in the tools-2.17.tar.gz package. See question (5) on where to obtain this from. The only solution in this case may be to bump up the major version number of the library forcing it to be backward incompatible. -------------------------------------------------------------------------------
59) Can I build DOS executables under linux ? Ans: Get a life !! Anyway I have been told that it is somewhat possible by using the "emx" package or the "go" extender. Please look in sunsite.unc.edu:/pub/Linux/devel/msdos I have not tested this and cannot vouch for its abilities. -------------------------------------------------------------------------------
60) Is -fpic - i.e PIC (position independent code) supported on linux. ? Ans: Yes but only with ELF executables. a.out PIC is not supported. This is currently in the testing stage, but works very well. -------------------------------------------------------------------------------
61) What is this ELF thing anyway ? Ans: This section is from the document '/news-archives/comp.sys.sun.misc'. ELF ("Executable Linking Format) is the "new, improved" object file format introduced in SVR4. ELF is much more powerful than straight COFF, in that it *is* user-extensible. ELF views an object-file as an arbitarily long list of sections (rather than an array of fixed size entities), these sections, unlike in COFF, do not HAVE to be in a certain place and do not HAVE to come in any specific order etc. Users can add new sections to object-files if they wish to capture new data. ELF also has a far more powerful debugging format called DWARF (Debugging With Attribute Record Format) - not currently fully supported on linux (but work is underway). A linked list of DWARF DIEs (or Debugging Information Entries) forms the .debug section in ELF. Instead of being a collection of small, fixed-size information records, DWARF DIEs each contain an arbitrarily long list of complex attributes and are written out as a scope-based tree of program data. DIEs can capture a large amount of information that the COFF .debug section simply couldn't (like C++ inheritance graphs etc.). ELF files are accessed via the SVR4 (Solaris 2.0 ?) ELF access library, which provides an easy and fast interface to the more gory parts of ELF. One of the major boons in using the ELF access library is that you will never need to look at an ELF file qua. UNIX file, it is accessed as an Elf *, after an elf_open() call and from then on, you perform elf_foobar() calls on its components instead of messing about with its actual on-disk image (something many COFFers did with impunity). ELF is now supported by GNU gdb-4.12 (and above) on linux and many other tools and is definitely something to look forward to in linux. You may compile gdb with ./configure i386-sysv-linuxelf You may find more doccumentation (postscript) on version 1.1 of ELF from tsx-11.mit.edu:/pub/linux/packages/GCC/ELF.doc.tar.gz -------------------------------------------------------------------------------
62) How do I build an ELF libc ? Ans: Get the libc sources (See question (47) on where to obtain it) and then you simply need to do % make ELF=true after running % ./configure This is assuming you have installed the ELF gcc/ld/as etc.. as indicated in question (60) above. NOTE: This is only supported for libc versions 4.6.x -------------------------------------------------------------------------------
63) Why does the execl() call fail on linux and just print out libc.so.4 messages ? Ans: The execl() call does NOT fail on linux. It basically means your application does not strictly conform to POSIX.1. You have just not read the manpage correctly and are not providing execl() with the right parameters. Here is a quote from the manpage: Two interfaces are available. execl() is useful when a known file with known arguments is being called; the argu- ments to execl() are the character strings constituting the file and the arguments; the first argument is conventionally the same as the file name (or its last component). A (char *)0 argument must end the argument list. The cast to type char * insures portability. So your execl() should provide a *minimum* of two arguments like execl("/bin/ls","ls",NULL); instead of just execl("/bin/ls", NULL); The single argument execl() command is reserved for the use of identifying the executable dependencies (i.e. its shared libraries) or whether it is static. -------------------------------------------------------------------------------
64) Can I preload objects with a.out binaries (a.la Sun LD_PRELOAD) ? Ans: Yes but only if you are using ld.so version 1.5.2 or above. See question (4) under libld.so on where to obtain this from. -------------------------------------------------------------------------------
65) With the new gcc I cannot seem to generate ZMAGIC binaries ? Ans: Well it's not really gcc but the new binutils which do not support the creation of ZMAGIC binaries. Support will continue unhindered for the execution of these binaries so old programs will still be able to work. -------------------------------------------------------------------------------
66) perl-5.00 needs dlopen() and friends. Where are they anyway ? Ans: dlopen() and friends are only supported in the ELF executable format. ELF compiler and utilities will be available shortly. They are undergoing final testing now (Dec `94). Perl-5.00 has been succesfully built using ELF format with complete dynamic loading facilities. -------------------------------------------------------------------------------
67) Where can I get more info about ELF ? Ans: Daniel Barlow has put up a URL describing some more detail about ELF. Set your URL to the location http://sable.ox.ac.uk/~jo95004/elf.html -------------------------------------------------------------------------------
68) What does "ld: output file needs shared library libc.so.4" mean ? Ans: Most likely it means you are using the -g flag in compiling and you haven't got the correct libraries (the static archives installed). Usually people have installed the shared libraries (.sa) files and do not have any corresponding static archives (.a) files. This means when the linker attempts to build an executable with the -g flag, it starts by looking for the .sa files first and then drops back to .a libraries. Now in the .sa stubs there is usually an undefined symbol _NEEDS_SHRLIB_libc_4 which gets resolved from the libc.sa stub. However with -g you end up linking with libg.a or libc.a and thus this symbol never gets resolved, leading to the above error message. In conclusion, get the static archives, or explicitly add -static when compiling with the -g flag. -------------------------------------------------------------------------------
69) Why do I get '/usr/bin/gcc:' or '/usr/bin/as: command not found' ? Ans: You haven't read the release notes for the compiler or the binutils. Basically you haven't installed the ELF dynamic linker ld-linux.so as all newer precompiled binaries are in ELF format only (you can still produce a.out binaries). See question (4) under libld.so on where to obtain this from. -------------------------------------------------------------------------------
70) Why can't the linker find any libraries other than those in /lib or /usr/lib ? Ans: Most people ask this question when linking X programs (i.e. the linker can't find -lX11 or -lXt unless they specify the -L flag like -L/usr/X11R6/lib or whatever). In this case the true answer is that they should really use a Imakefile which will set the appropriate directory paths automatically on a wide variety of systems. The other (compiler version dependent) solution is to add the -Lpath to your specs file /usr/lib/gcc-lib/i486-linuxaout/2.7.0/specs under the *libs: line. This will have the effect of always passing -Lpath to the linker -------------------------------------------------------------------------------
71) Where are stat(), fstat() gone in the ELF libs ? Ans: In the older (libc.so.4.x and earlier) stat(), fstat() and friends were functions, but have now been changed to be macros in <sys/stat.h>. Thus you should include that header file when you require stat() and friends. -------------------------------------------------------------------------------
72) Can someone explain what "ld: Output file requires shared library `libfoo.so.1`" means ? Ans: With DLL's the linker links against THE CORRESPONDING STUB and NOT the shared DLL. By this I mean the linker is looking for a libfoo.sa somewhere in your library path. Always remember the fact that for DLL's - the libfoo.so is a RUN TIME LIBRARY and libfoo.sa is a LINK/COMPILE TIME library/archive. So if your don't have the libfoo.sa then your compile will fail, and if you dont have libfoo.so.x (assuming the correct major version) then your execution will fail. Several distributions (Slackware etc..) package runtime and the developer disks separately. This means even if you have the .so's you cannot compile. Install the right package and all will be fine. Note that for ELF there are no stubs, so if you have the libfoo.so file you have a complete environment - i.e. runtime and developer. =============================================================================== Acknowledgements: (in no order) H.J.Lu Dirk Hohndel David Engel Eric Youngdale Bill Metzenthen Rik Faith Steven S. Dick Bruno Haible Andrew Tefft Kai Petzke Tuomas J Lukka Fergus Henderson Paul Gortmaker Olaf Flebbe Jens Schweikhardt Bruce Evans Axel Boldt Daniel Quinlan and of course Linus Torvalds =============================================================================== N.B. Please do not feel offended if your name has not appeared here and you have contributed however significantly/insignificantly. It is entirely my fault. Email me and I will rectify it. =============================================================================== Please help in making this FAQ the definitive answer repository of Linux GCC queries by e-mailing questions, (and answers if you have them), corrections and additions to me Mitchum DSouza <m.dsouza@mrc-apu.cam.ac.uk>