Article: 986 of comp.os.linux.announce
Path: pavo.csi.cam.ac.uk!doc.ic.ac.uk!agate!usenet.ins.cwru.edu!magnus.acs.ohio-state.edu!math.ohio-state.edu!uwm.edu!rpi!batcomputer!bounce-bounce
From: Mitchum DSouza < mitchum.dsouza@mrc-apu.cam.ac.uk>
Newsgroups: comp.os.linux.announce
Subject: GCC FAQ. Please read before posting GCC/compiler related queries
Followup-To: comp.os.linux
Date: 5 Aug 1993 09:39:29 -0400
Organization: None
Lines: 908
Sender: mdw@TC.Cornell.EDU
Approved: linux-announce@tc.cornell.edu (Matt Welsh)
Message-ID: <23r2ih$hj@theory.TC.Cornell.EDU>
Reply-To: Mitchum DSouza < mitchum.dsouza@mrc-apu.cam.ac.uk>
NNTP-Posting-Host: theory.tc.cornell.edu
Keywords: GCC FAQ
Hi,
After seeing yet another flurry of GCC related queries I am reposting an
updated version of the GCC FAQ.
Included is a more detailed explanation of LD_LIBRARY_PATH support on linux,
and also a worked example of cross-compiling to produce linux code on a
foreign machine (Sun).
Mitch
----------------------Linux GCC FAQ 4th August 1993--------------------------
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 is < varargs.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" mean ?
31) What is a libc.so.lite ?
32) Does 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/ ?
----------------------------------------------------------------
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/i386-linux/2.4.5/specs
gcc version 2.4.5
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/i486-linux/2.4.5/specs
gcc version 2.4.5
you are running a gcc compiled for a 486.
----------------------------------------------------------------
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 2.4.5 from
tsx-11.mit.edu:/pub/linux/packages/GCC/gcc-2.4.5-p1.tar.gz
However this does not mean that this is the lastest available
version of GCC from the GNU foundation. This is just the latest
*distribution*.
The Linux GCC maintainers 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 from
tsx-11.mit.edu:/pub/linux/packages/GCC/inc-4.4.1.tar.gz
----------------------------------------------------------------
3) Where can I find the newest shared libraries libc.so and libm.so ?
Ans: See (2) above. You need the file image*.tar.z. For 486 images look
under /pub/linux/packages/GCC/486.
----------------------------------------------------------------
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. The descriptions of the libraries may not be obvious. I will
add descriptions in a later table (i.e. when all are filled). Please
send descriptions of the libraries (except the obvious) if you know
what they are.
Here are the locations of currently registered DLL libraries for Linux.
======================================================================
libc.so tsx-11.mit.edu:/pub/linux/packages/GCC/image-4.4.1.tar.gz
libm.so included in above tar.z file.
libX11.so tsx-11.mit.edu:pub/linux/packages/X11/XFree86-1.3/xf86-1.3-bin.tar.gz
libXt.so included in above tpz file.
libXaw.so included in above tpz file.
librl.so sunsite.unc.edu:/pub/Linux/libs/librl-1.1.tar.z
libgr.so sunsite.unc.edu:/pub/Linux/libs/libgr-1.2.tar.z
libf2c.so sunsite.unc.edu:/pub/Linux/development/fortran/libf2c-0.7.tar.z
libF77.so use libf2c.so instead.
libI77.so use libf2c.so instead.
libXpm.so sunsite.unc.edu:/pub/Linux/libs/libXpm32g.tar.z
libnet.so redundant (reintegrated into libc.so address space
librpc.so to be used for nis/yp and rpcsvc)
libolgx.so sunsite.unc.edu:/pub/Linux/X11/devel/xview3l4.tar.z
libxview.so included in above tar.z file.
libsspkg.so included in above tar.z file.
libUIC.so included in above tar.z file.
libPEX.so
libtcl.so sunsite.unc.edu:/pub/Linux/development/tcl/tclDist.tar.z
libtk.so included in above tar.z file.
libWc.so
libXp.so
libIV.so
libUnidraw.so
libXm.so(motif) Not free. See note below.
libsrgp.so sunsite.unc.edu:/pub/Linux/X11/devel/suit.tpz
libsuit.so included in above tpz file.
------------
Note:-
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/libXaw3d-3.0-B.tar.z
and
sunsite.unc.edu:/pub/Linux/libs/libXaw.Scrollbar.taz
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 the introductory price of $199 for a complete runtime and
development system.
[...]
2) Shared motif library (libXm.so.1.2.2)
[...]
This introductory offer is valid until June 10. The price will then return
to our regular Motif pricing which is $199 for runtime and $299 for
development
(which includes runtime).
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.
----------------------------------------------------------------
5) How do I build a shared DLL library for Linux ?
Ans: You need to get the file
/pub/linux/packages/GCC/src/tools-2.7.5.tar.z
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'.
Solution is to get the new version of binutils package from
tsx-11.mit.edu in /pub/linux/packages/GCC/binutils.tar.z
----------------------------------------------------------------
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 --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.
1) Get the following files
tsx-11.mit.edu:/pub/linux/packages/GCC/src/binutils-1.9l.1.tar.gz
tsx-11.mit.edu:/pub/linux/packages/GCC/src/gas-1.38.1l.1.tar.gz
2) Extract and compile the cross assmbler and linker.
In the binutils dir binutils-1.9l.1:
% make -f Makefile.linux
In the the assembler dir gas-1.38.1l.1:
% make -f makefile.linux
3) Lets assume you already have a working gcc version on the Sun in
/usr/local/bin with all standard install paths - i.e the compilers
are in /usr/local/lib/gcc-lib. Now put the binaries produced from
step 2) into a directory
/usr/local/lib/gcc-lib/i386-linux-linux/2.4.5/bin
You will have to create this and its sub-directories.
4) Make a directory
/usr/local/lib/gcc-lib/i386-linux-linux/2.4.5/include
Put *ALL* linux specific header file with all the contents of the
subdirectories linux, asm, gnu, sys etc.. Make SURE of this.
See questions (2) and (23) on where to get these from.
5) 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 -O2 -s" \
LANGUAGES="c c++" \
tooldir=/usr/local/lib/gcc-lib/i386-linux-linux/2.4.5/bin
6) After that finishes, copy the binaries it the proper place...
% cp cc1 cc1plus cpp /usr/local/lib/gcc-lib/i386-linux-linux/2.4.5
Copy the front end to the compiler somewhere (maybe your ~/bin)
% cp xgcc ~/bin/gcc-linux
7) Get all your libs from your linux machine
% rcp linux_machine:/usr/lib/lib\*a /usr/local/lib/gcc-lib/i386-linux-linux/2.4.5
% rcp linux_machine:/usr/X386/lib\*a /usr/local/lib/gcc-lib/i386-linux-linux/2.4.5
% rcp linux_machine:/usr/lib/crt0.o /usr/local/lib/gcc-lib/i386-linux-linux/2.4.5
8) You may want to make links to the cross versions of ranlib, ar,
strip, ld, nm. I did
% cd ~/bin
% ln -s /usr/local/lib/gcc-lib/i386-linux-linux/2.4.5/bin/ar l-ar
% ln -s /usr/local/lib/gcc-lib/i386-linux-linux/2.4.5/bin/ranlib l-ranlib
% ln -s /usr/local/lib/gcc-lib/i386-linux-linux/2.4.5/bin/strip l-strip
% ln -s /usr/local/lib/gcc-lib/i386-linux-linux/2.4.5/bin/ld l-ld
% ln -s /usr/local/lib/gcc-lib/i386-linux-linux/2.4.5/bin/nm l-nm
9) Thats it. Try compiling something. Lots of well written packages
will let you do the following (assuming you have the path to your
~/bin set)
% make CC="gcc-linux -s" RANLIB=l-ranlib AR="l-ar cvr"
10) 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.7.5.tar.z
Use the Makefile.short in the tools subdirectory to compile a
cross version. Change the definition of XCFLAGS in the
Makefile.short before hand to point to the directory
/usr/local/lib/gcc-lib/i386-linux-linux/2.4.5/bin
in the above example. **Note** that for a Sun you also have to
change some definitions for it to compile. Please contact myself
if you need more info.
----------------------------------------------------------------
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/i386-linux/2.4.5/specs
----------------------------------------------------------------
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 / | \
/ | \
Version no. | Minor version no.
|
Major version no.
In general if the Version no. changes you will definetly NOT be able
to execute a program that was compiled with a different library. i.e
it is no use attempting to create a link from libc.so.4.3.3 to
libc.so.2 if your program requires libc.so.2.
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 is *greater* (or equal of course) than that the
program was compiled with. This means if your program is compiled
when you had libc.so.4.3.3 you will be still able to execute it if
you get a more recent version of the DLL library, say libc.so.4.3.4,
but then do not expect to be able to execute the program if you
decide to go back to say libc.so.4.2
The Minor version no. is as name suggests, an indication that a very
minor change has undergone in the shared DLL library, usually a typo
or small bug fix in the library code. The minor version no. may be
left out totally from the naming convention.
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 -O6 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.
A combination of any/all of these may be used.
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) *OR* 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 (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.
----------------------------------------------------------------
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; as a consequence it cannot
be swapped or shared.
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. If you start to run out of memory, the kernel can start
to delete unused code pages from demand pages executables - 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.
If you end up at the linker stage with a message like
Can't find libg.a
then you need to get from tsx-11.mit.edu the file
/pub/linux/packages/GCC/extra*.tar.z
However enough debugging information may be gleaned by simply doing
% cd /usr/lib; ln -s libc.a libg.a
on your linux machine.
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:
sunsite.unc.edu:/pub/Linux/development/gdb-4.8.z
An X debugger based on this, (i.e. you need gdb installed first), is
also available there (xxgdb).
----------------------------------------------------------------
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
that you want to debug. (I forget the exact details; I usually use
gdb's internal help when I want those esoteric extras.)
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.
----------------------------------------------------------------
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.tar.z
----------------------------------------------------------------
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 :-)
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'.
Note: your version of `ldd' may have a somewhat different output.
----------------------------------------------------------------
20) Does Linux have support for LD_LIBRARY_PATH ?
Ans: Yes and No.
Firstly 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. However unlike some commercial systems,
(eg: Sun-OS), whose dynamic linker is in fact a dynamic library,
Linux's dynamic linker is 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 is, 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.
Linux's LD_LIBRARY_PATH is very security concious, and do NOT expect
to work the way SunOS do it or the way you'd like it to.
Primarily the difference with SunOS'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 impure 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 need 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 compatability 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 is
force loaded from somewhere in the trusted search path, and the
remaining required libraries are searched in LD_LIBRARY_PATH. 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 excuted is a
"normal" binary, then LD_LIBRARY_PATH is searched first for the
libraries required.
If the library is NOT found in the users 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 lets these kind of nubile users
to execute binaries.
For Linux, as a runtime linking time comsideration, if a binary
requires multiple libraries to link to and one, (yes just one - and
it could be the first), of the libraries is NOT found in the users
LD_LIBRARY_PATH then the *whole* search process in the
LD_LIBRARY_PATH is aborted and switched to the trusted search path.
So all in all this could be called a half hearted attempt at
LD_LIBRARY_PATH support, (that is if you compare it to SunOS), but it is
there and I guess (hope) it will also evolve.
Now to the second question. I can remember this only vaguely, so bear with me.
----------------------------------------------------------------
21) My program wants /lib/cpp ! Where can I get it from ?
Ans: cpp appears in /usr/lib/gcc-lib/i386-linux/2.4.5
(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/i386-linux/2.4.5/cpp
** Change the 2.4.5 to whatever version of GCC your are using.
** Change the i386 to i486 if using the 486 compiler
An alternative, and possibly better solution is this:
% cat > /lib/cpp
#!/bin/sh
cc -E "$@"
Ctrl-D[EOF]
This way /lib/cpp won't stop working when you switch to a newer gcc
version and delete the old one.
----------------------------------------------------------------
22) Where is < varargs.h> ?
Ans: varargs.h appears with other system dependent files in
/usr/lib/gcc-lib/i386-linux/2.4.5/include
< varargs.h> is K&R stuff. By default, gcc is ANSI. < stdarg.h> should
be used instead.
** Change the 2.4.5 to whatever version of GCC your are using.
----------------------------------------------------------------
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
----------------------------------------------------------------
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 thought, 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 future
only `make' need be called to provide a working executable.
One of the most common problems are 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().
----------------------------------------------------------------
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 USENET newsgroups gnu.gcc.bug or gnu.gcc.help
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
(mitchum.dsouza@mrc-apu.cam.ac.uk) 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.
You can also strip your libraries after you build them.
----------------------------------------------------------------
28) What are .sa file I see in /usr/lib ?
Ans: The .sa files are the stubs to the shared libraries and contain all
global variables from a certain library, and pointers to functions
required for run time linking. See also question (13).
----------------------------------------------------------------
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.4.5-p2.tar.gz
----------------------------------------------------------------
30) What does the message "Internal compiler error: cc1 got fatal signal 11" mean ?
Ans: Gcc is probably the biggest memory hog you 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 a cc1 got corrupted due to a
race condition and bad blocks on my hard disk.
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.so.lite ?
Ans: A libc.so.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) Does 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/distributions/SLS/a4/shadow.tgz
This means adding -DSHADOW_PWD to the CFLAGS line in the Makefile, and
-lshadow in the LDFLAGS line.
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.
----------------------------------------------------------------
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. Also
one can get the full manual from any local ftp site that carries GCC
and other FSF goodies. You will require TeX to make the manual from
the GCC source distribution.
----------------------------------------------------------------
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>
============================================================================
Acknowledgements: (in no order)
H.J.Lu
Dirk Hohndel
David Engel
Eric Youngdale
Bill Metzenthen
Rik Faith
Steven S. Dick
Bruno Haible
Andrew Tefft
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.
============================================================================
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@uk.ac.cam.mrc-apu>
--
Send submissions for comp.os.linux.announce to: linux-announce@tc.cornell.edu
|