If the Flash plugin is already installed for Firefox, we have to find out where it is located:
sudo updatedb
sudo locate libflashplayer.so
If it is installed, output should be similar to this one...
falko@falko-desktop:~$ sudo locate libflashplayer.so
/opt/Adobe AIR/Versions/1.0/Resources/libflashplayer.so
/usr/lib/flashplugin-installer/libflashplayer.so
falko@falko-desktop:~$
... which means the Flash plugin is located in /usr/lib/flashplugin-installer/libflashplayer.so. If there's no output, this means that the Flash plugin isn't installed - you can then install it as follows:
sudo aptitude install flashplugin-installer
Now we create a plugins directory for Google Chrome...
sudo mkdir /opt/google/chrome/plugins
... and copy the Flash plugin to it:
sudo cp /usr/lib/flashplugin-installer/libflashplayer.so /opt/google/chrome/plugins
Finally we have to tell the Google Chrome launcher that it should look out for plugins. To do this, we right-click on Applications and select Edit Menus:
In the Launcher Properties window, replace the contents of the Command field with this line...
/opt/google/chrome/google-chrome --enable-plugins %U
... and click on Close:
Then leave the Menu Editor.
That's it! We can now launch Google Chrome (Applications > Internet > Google Chrome):
Configure Squid by opening /etc/squid/squid.conf using your favorite text editor. In the configuration file, search for the following directives and modify (or add, if they don't exist) as it follows: http_port 3128 - The port Squid will listen for connections. If your system has two or more interfaces, you can specify which IP address to use. Eg: http_port 192.168.0.1:3128 http_access deny all - Search for it in the config file, uncomment it (remove the # in front), and replace deny with allow so it becomes http_access allow all. Restart the Squid proxy with: CODE $ sudo /etc/init.d/squid restartNow you should have a fully functional HTTP proxy. To try it out, open a browser, open its preferences dialog and go to proxy settings. Here, enter the IP address of the machine running Squid and the port set in squid.conf. Now load a webpage. SETTING UP SQUID AUTHENTICATION AND WEB FILTERING This section will allow you to set up a web site filter for kids. The first time an address is entered in the browser's address bar, an authentication dialog will pop-up, prompting for a username and password. We will set-up two usernames, one with full and another with restricted access. First, open the /etc/squid/squid.conf and add the following line in the auth_param section: auth_param basic program /usr/lib/squid/ncsa_auth /etc/squid/passwd Now create the user accounts using htpasswd (use -c only for the first user): CODE $ sudo htpasswd -c /etc/squid/passwd dadCreate the ACLs by adding the following lines in the ACCESS CONTROLS (acl) sections in Squid.conf: CODE acl dadUser proxy_auth dadCreate the whitelist by opening a text editor, adding allowed domains like this: .google.com .kids-play.com .yahoo.com .msn.com and save it as /etc/squid/whitelist. Finally, search for http_access allow all in the Squid config file and modify it so it looks like this: http_access deny all This is how my Squid config sections look like: CODE # NETWORK OPTIONSUse deny all for squid with authentication and allow all for basic squid configuration. | |
double mean(double, double);
ar rcs libmean.a calc_mean.o
cc1: warning: -fPIC ignored for target (all code is position independent)
#include#include "calc_mean.h" int main(int argc, char* argv[]) { double v1, v2, m; v1 = 5.2; v2 = 7.9; m = mean(v1, v2); printf("The mean of %3.2f and %3.2f is %3.2f\n", v1, v2, m); return 0; }
LD_LIBRARY_PATH=. ./dynamically_linked
The GNU archiver ar combines a collection of object files into a single archive file, also known as a library. An archive file is simply a convenient way of distributing a large number of related object files together
To demonstrate the use of the GNU archiver we will create a small library ‘libhello.a’ containing two functions hello and bye.
The first object file will be generated from the source code for the hello function, in the file ‘hello_fn.c’ seen earlier:
#include#include "hello.h" void hello (const char * name) { printf ("Hello, %s!\n", name); }
The second object file will be generated from the source file ‘bye_fn.c’, which contains the new function bye:
#include#include "hello.h" void bye (void) { printf ("Goodbye!\n"); }
Both functions use the header file ‘hello.h’, now with a prototype for the function bye():
void hello (const char * name); void bye (void);
The source code can be compiled to the object files ‘hello_fn.o’ and ‘bye_fn.o’ using the commands:
$ gcc -Wall -c hello_fn.c $ gcc -Wall -c bye_fn.c
These object files can be combined into a static library using the following command line:
$ ar cr libhello.a hello_fn.o bye_fn.o
The option cr stands for "create and replace".(33) If the library does not exist, it is first created. If the library already exists, any original files in it with the same names are replaced by the new files specified on the command line. The first argument ‘libhello.a’ is the name of the library. The remaining arguments are the names of the object files to be copied into the library.
The archiver ar also provides a "table of contents" option t to list the object files in an existing library:
$ ar t libhello.a hello_fn.o bye_fn.o
Note that when a library is distributed, the header files for the public functions and variables it provides should also be made available, so that the end-user can include them and obtain the correct prototypes.
We can now write a program using the functions in the newly created library:
#include "hello.h" int main (void) { hello ("everyone"); bye (); return 0; } This file can be compiled with the following command line, as described in section 2.7 Linking with external libraries, assuming the library ‘libhello.a’ is stored in the current directory:
$ gcc -Wall main.c libhello.a -o hello
The main program is linked against the object files found in the library file ‘libhello.a’ to produce the final executable.
The short-cut library linking option -l can also be used to link the program, without needing to specify the full filename of the library explicitly:
$ gcc -Wall -L. main.c -lhello -o hello
The option -L. is needed to add the current directory to the library search path. The resulting executable can be run as usual:
$ ./hello Hello, everyone! Goodbye!
It displays the output from both the hello and bye functions defined in the library.
In addition to allowing programs to be run under the debugger, an important benefit of the -g option is the ability to examine the cause of a program crash from a "core dump".
When a program exits abnormally (i.e. crashes) the operating system can write out a core file (usually named ‘core’) which contains the in-memory state of the program at the time it crashed. This file is often referred to as a core dump.(14) Combined with information from the symbol table produced by -g, the core dump can be used to find the line where the program stopped, and the values of its variables at that point.
This is useful both during the development of software and after deployment--it allows problems to be investigated when a program has crashed "in the field".
Here is a simple program containing an invalid memory access bug, which we will use to produce a core file:
int foo (int *p); int main (void) { int *p = 0; /* null pointer */ return foo (p); } int foo (int *p) { int y = *p; return y; } The program attempts to dereference a null pointer p, which is an invalid operation. On most systems, this will cause a crash. (15)
In order to be able to find the cause of the crash later, we will need to compile the program with the -g option:
$ gcc -Wall -g null.c
Note that a null pointer will only cause a problem at run-time, so the option -Wall does not produce any warnings.
Running the executable file on an x86 GNU/Linux system will cause the operating system to terminate the program abnormally:
$ ./a.out Segmentation fault (core dumped)
Whenever the error message ‘core dumped’ is displayed, the operating system should produce a file called ‘core’ in the current directory.(16) This core file contains a complete copy of the pages of memory used by the program at the time it was terminated. Incidentally, the term segmentation fault refers to the fact that the program tried to access a restricted memory "segment" outside the area of memory which had been allocated to it.
Some systems are configured not to write core files by default, since the files can be large and rapidly fill up the available disk space on a system. In the GNU Bashshell the command ulimit -c controls the maximum size of core files. If the size limit is zero, no core files are produced. The current size limit can be shown by typing the following command:
$ ulimit -c 0
If the result is zero, as shown above, then it can be increased with the following command to allow core files of any size to be written:(17)
$ ulimit -c unlimited
Note that this setting only applies to the current shell. To set the limit for future sessions the command should be placed in an appropriate login file, such as‘.bash_profile’ for the GNU Bash shell.
Core files can be loaded into the GNU Debugger gdb with the following command:
$ gdb EXECUTABLE-FILE CORE-FILE
Note that both the original executable file and the core file are required for debugging--it is not possible to debug a core file without the corresponding executable. In this example, we can load the executable and core file with the command:
$ gdb a.out core
The debugger immediately begins printing diagnostic information, and shows a listing of the line where the program crashed (line 13):
$ gdb a.out core Core was generated by `./a.out'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 #0 0x080483ed in foo (p=0x0) at null.c:13 13 int y = *p; (gdb)
The final line (gdb) is the GNU Debugger prompt--it indicates that further commands can be entered at this point.
To investigate the cause of the crash, we display the value of the pointer p using the debugger print command:
(gdb) print p $1 = (int *) 0x0
This shows that p is a null pointer (0x0) of type ‘int *’, so we know that dereferencing it with the expression *p in this line has caused the crash.
The debugger can also show the function calls and arguments up to the current point of execution--this is called a stack backtrace and is displayed with the commandbacktrace:
(gdb) backtrace #0 0x080483ed in foo (p=0x0) at null.c:13 #1 0x080483d9 in main () at null.c:7
In this case, the backtrace shows that the crash occurred at line 13 after the function foo was called from main with an argument of p=0x0 at line 7 in ‘null.c’. It is possible to move to different levels in the stack trace, and examine their variables, using the debugger commands up and down.
A breakpoint stops the execution of a program and returns control to the debugger, where its variables and memory can be examined before continuing. Breakpoints can be set for specific functions, lines or memory locations with the break command.
To set a breakpoint on a specific function, use the command break function-name. For example, the following command sets a breakpoint at the start of the mainfunction in the program above:
$ gdb a.out (gdb) break main Breakpoint 1 at 0x80483c6: file null.c, line 6.
The debugger will now take control of the program when the function main is called. Since the main function is the first function to be executed in a C program the program will stop immediately when it is run:
(gdb) run Starting program: a.out Breakpoint 1, main () at null.c:6 6 int *p = 0; /* null pointer */ (gdb)
The display shows the line that will be executed next (the line number is shown on the left). The breakpoint stops the program before the line is executed, so at this stage the pointer p is undefined and has not yet been set to zero.
To move forward and execute the line displayed above, use the command step:
(gdb) step 7 return foo (p);
After executing line 6, the debugger displays the next line to be executed. The pointer p will now have been set to zero (null):
(gdb) print p $1 = (int *) 0x0
The command step will follow the execution of the program interactively through any functions that are called in the current line. If you want to move forward without tracing these calls, use the command next instead.
To temporarily fix the null pointer bug discovered above, we can change the value of p in the running program using the set variable command.
Variables can be set to a specific value, or to the result of an expression, which may include function calls. This powerful feature allows functions in a program to be tested interactively through the debugger.
In this case we will interactively allocate some memory for the pointer p using the function malloc, storing the value 255 in the resulting location:
(gdb) set variable p = malloc(sizeof(int)) (gdb) print p $2 = (int *) 0x40013f98 (address allocated by malloc) (gdb) set variable *p = 255 (gdb) print *p $3 = 255 If we now continue stepping through the program with the new value of p the previous segmentation fault will not occur:
(gdb) step foo (p=0x40013f98) at null.c:13 13 int y = *p; (gdb) step 14 return y;
The command finish continues execution up to the end of the current function, displaying the return value:
(gdb) finish Run till exit from #0 0x08048400 in foo (p=0x40013f98) at null.c:15 0x080483d9 in main () at null.c:7 7 return foo (p); Value returned is $13 = 255
To continue execution until the program exits (or hits the next breakpoint) use the command continue,
(gdb) continue Continuing. Program exited with code 0377.
Note that the exit code is shown in octal (0377 base 8 = 255 in base 10).