Ok, you should now have a working compiler and you're ready to compile some other programs. But what do you do when something goes wrong?

There are a few utilities that you can use to help track down what went wrong.

During compilation due to some unforeseen error make may abort. Contact the developer when that happens. As is often the case there may be more than one compile time error. 'make -k' will tell make to keep going even if it encounters an error that would normally end the make session. The benefit to the developer if they ask you to run this is they might be able to fix all the problems at once instead of going through the process of fixing them one at a time. I've been asked to do this before and it's a great time saver.

If you encounter an error such as "symbol missing", use the nm command to list out which symbols are present in the library in question. Usually all you'll need to do is update the library and off you go.

If a program crashes after it's compiled a developer may ask you to run gdb against it. You'll need to ftp and install the GNU Debugger before you can do this. I'm not a developer so I had to ask them for a cheat sheet on the commands they wanted me to type and they sent me a list. It's not that complicated. They were able to quickly fix the problem thanks to the debugger.

And if you want to see the internals of application as it runs you can use truss or apptrace. On Solaris 10 you can try to use the DTrace facility to help track down what went wrong. In addition there are products that you can purchase that are designed to help you with errant code. See the Sun Country - (Quality Assurance Section) web site for a listing of these products.

If you have problems with an application that doesn't work once it's compiled and running you may need to crash it intentionally. Contact the developer and see if they want a core file from the application. There are tools such as Solaris Modular Debugger, or as mentioned previously, the GNU Debugger, that may help them to determine what went wrong with the code.

Don't forget that some programs are dependant on other programs. A dependant program may be the one that is actually causing the problem and you may need to look at it instead. You can use truss to make sure that the application is not in a deadlock state. A deadlock state occurs when one process is waiting for another to finish and the other process isn't ever going to finish. Truss will usually show the process as "sleeping" when this happens.

GCC & Visibility

You can read up on visibility at http://gcc.gnu.org/wiki/Visibility.

This can cause the code that you're trying to compile to fail to compile.

On the scren it starts with a few of these:

warning: visibility attribute not supported in this configuration; ignored

followed by:

ld: fatal: relocation error: R_386_GOTOFF: file .libs/some_file.o: symbol some_file: relocation must bind locally

and at this point the ability to move forward comes to an end.

The problem is that the Solaris linker does not support GCC & visibility.

Some developers are now aware of this situation and they are taking steps in their configure scripts to check the linker, (/usr/ccs/bin/ld in this case), to see if the linker supports visibility. Older versions of their program may not check for this and and the fix in those cases is to move up to a newer version that does the check. For those programs that do not check the linker for visibility support you should contact the developer's directly and let them know what is going on so they can update their configure scripts to handle this situation.

Some programs offer a configure switch, --disable-visibility, and you should use this if it is offered. Even if it isn't offered you can still tell configure to use it but nothing will change since there is no code in configure that deals with the switch.

The last approach to handling visibility and Solaris is to switch the linker to the GNU linker which has no problem with visibility on Solaris. The GNU linker is part of the GNU project: binutils, and you can compile up the latest version of binutils to circumvent this issue.

Putting the GNU linker (ld) first in your path may not do you any good however. Depending on how gcc was compiled and whether libtool is being used or not, gcc may still revert to using /usr/ccs/bin/ld instead of your just installed /path/ld. Be sure to check the gcc build instructions to see how to configure gcc to use an alternate linker. This solves the issue on Solaris.

Next Section:  Imake Instructions (7 of 11)