The les/usr/include/linuxand/usr/include/asmare symbolic links to
/usr/src/linux/include/linuxand/usr/src/linux/include/asm,respectively.
In other words, all of the Linux include les are actually under/usr/src/linux/include,
but to access them you need two symbolic links in/usr/include: /usr/include/linux -> /usr/src/linux/include/linux /usr/include/asm -> /usr/src/linux/include/asm
To make these, run the commands
ln -sf /usr/src/linux/include/linux /usr/include/linux ln -sf /usr/src/linux/include/asm /usr/include/asm
NOT the other way around. :) If you dont have these links then many compi- lations will surely fail.
44 5 INSTALLATION AND COMMON PROBLEMS
5.3.17 How can I upgrade to the newest version of GCC?
See section 12 on GCC for more information, but essentially all you need to do
is FTP to sunsite.unc.edu (or one of the other Linux FTP sites) and look in
/pub/Linux/GCC. You'll see a number of.tar.Zles there (often abbreviated.TZ
ortpz). The names change from time to time: you need to get the compiler (often
in a le such asgcc233.TZ),header les, and library les. At this point, the compiler
lives in/usr/bin, the compiler'ssetup les are under/usr/lib/gcc-lib/i386-linux,
and the libraries (shared, jump table, and static) are all in/usr/lib. It's all very
straightforward once you actually unpack the tar les and everything falls into place.
5.3.18 What's the deal with these things called
jump tables?
There's more information in sections 12, 8 and 9, but to be brief: There are three kinds of libraries for Linux. As of gcc v2.3.3 they all live in /usr/lib. The les
are...
/usr/lib/*.a static (non-shared) libraries (usegcc -static...) /usr/lib/*.ca classic shared lib stubs (use gcc -nojump...) /usr/lib/*.sa jump table shared lib stubs (usegcc -jump...)
There is an older form of the shared libraries, classic shared libraries, which is no longer widely used. Nonetheless, you may run across it from time to time.
When you compile a program, depending on the options you give gcc (-jumpis
the default) it will link it against one set of these libraries. The static libs contain all of the code and thus make your executable very big no shared code is used. The classic shared libs are actuallystubswhich reference the shared code in
/lib/libc.so.VERSION (where VERSION is a number like '4.2').
/lib/libc.so.VERSION is a le which contains the actual code of the library, which
is accessed at runtime by your executable. The jump-table library stubs are also shared libs, but they are built in such a way that you can upgrade the/lib/libc.so. VERSIONle without having to recompile the programs that use it.
So when we sayuses Jump Tables version 4.2we mean it uses the actual library
itself, /lib/libc.so.4.2. To compile programs that use jump tables version 4.2
you need the right version of/usr/lib/*.sainstalled, but you don't need them to
RUN programs that use jump tables.
However programs that are compiled to use, for example, jump table version
4.2 (in the le /lib/libc.so.4.2) won't work if you only have libc.so.4.1in-
stalled. They're only backwards-compatible. If you get errors about can't nd
/lib/libc.so.4.1 then the executable you're using is looking at runtime for a
jump table version that you don't have. Basically you're safe if you have the most recent version of the
/lib/libc.so.VERSIONle installed (which is found onsunsite.unc.edu: /pub-
verb"/Linux/GCC" and comes with the GCC stu).
You should always have a symbolic link with the major version number of the library in /lib, because that's what's actually read. For instance, if you have /lib/libc.so.4.2installed, then you need the symbolic link
/lib/libc.so.4 -> /lib/libc.so.4.2
Make this with the command
5.3 Some common Problems 45
5.3.19 How to upgrade jump tables? (Without hanging my system)
Be careful! If you upgrade your/lib/libc.so.VERSIONle and either remove the
symlink or delete theold libc.so.VERSIONle before the new one is in place (and
the link points to it), then more than likely all of your binaries likecp,mv,lsand lnuse the library, so they'll all stop working once you kill the link or the library
le. So to upgrade the le, copy the new version to/liband switch the link in one
step with a command such as
ln -sf /lib/libc.so.NEW_VERSION /lib/libc.so.4
whereNEW_VERSIONis the new version of the library you're installing. This will
switch the link in one step and everything should work. You just can't copy over the old le because the old version is in use bycp,mv, and so on.
5.3.20 How can I be sure I won't be writing over anything important?
I have to use DOS on my machine, and I don't want to lose any
les.
Back up everything.
Just in case. Then, write some easily recognizable pattern to the partition you have reserved for Linux, using some DOS tool. You can then usecat /dev/hdXunder Linux to examine which of the partitions you used.5.3.21 I just rebooted my machine, and now Linux dies with a
panic: trying to free unused inode. What's going on?
You probably forgot tosyncbefore rebooting, which stores on the disk physically
the contents of the kernel buers. You can either runfsckon the partition to TRY
to correct the problem (it might fail), or re-mkfsand re-install the software on
that partition.
The best way to shutdown your system is theshutdowncommand. To shutdown
and reboot the system, use
shutdown -r now
or substitute a number of minutes in place ofnow. Leave o the-rswitch if you
just want to shutdown and not reboot.
You can now use the rebootcommand, which syncs all disks, shuts down the
system and reboots it.
5.3.22 Can I use both OS/2 and Linux on my machine?
Yes! See the following two Q/A's about getting your OS/2 Boot Manager to work.
But, be warned:
IF YOU USE OS/2, DO NOT USE LINUX's FDISK
TO CREATE LINUX PARTITIONS!!
The problem is with a bug/feature in OS/2'sfdiskthat tries to correct errorsin partitions that it doesn't like... Linuxpartitions included. The solution: make your Linux partitions with OS/2'sfdisk,
then use Linux's fdisk to change the partition ID's to the right values (this is
self-explanatory with Linux'sfdisk).
If you made your Linux partitions with Linux'sfdisk, and OS/2 sees them, it
46 5 INSTALLATION AND COMMON PROBLEMS
5.3.23 I use OS/2's Boot Manager on my hard drive. How can I get it
to recognize Linux?
To do this, install LILO on your Linux root partition, NOT on your hard drive's
master boot record. The lilo command for this would be (if /dev/hda3 is your
Linux root partition, and your Linux kernel is in /vmlinux): /etc/lilo/lilo -c -b /dev/hda3 -v -v /vmlinux
Then use OS/2'sfdiskto add it to the Boot Manager.
Thanks to Thomas Brodt ([email protected]).