This is a collection of issues for SL5, 64bit kernels with 32 & 64 bits code support. The help below assumes you are working within the STAR enviornment that is, your .login and .cshrc are standards. 

Note: If you use the 'cons' make system, none of the below are needed. A correlative is that we strongly suggest you using cons for your code.

Use of PIC symbols

If you plan to create shared libraries, please use -fPIC compiler option. 

ATTENTION: capitalization is important.

More or less quoting the gcc manual:

PIC or position-independent code symbols are suitable for use in a shared library, if supported for the target machine. Linux and SL supports PIC. Such code accesses all constant addresses through a global offset table (GOT). The dynamic loader resolves the GOT entries when the program starts (the dynamic loader is not part of GCC; it is part of the operating system). If the GOT size for the linked executable exceeds a machine-specific maximum size, you get an error message from the linker indicating that -fpic does not work; in that case, recompile with -fPIC instead.

This option is not needed for non-shared libraries (but does not hurt).

Makefile - switching compiler options

First, please note that it is best to compile explicitely with the 64 and 32 bit support compiler and inker flag whenever you set your own Makefile. This will avoid re-writting it. In STAR, the environment is consistent and 64 bits code suport is detectable by checking the USE_64BITS environment variable. An example is below for shared libraries.

ifeq ( $(USE_64BITS),1)
   CFLAGS   =  -m64 -fPIC 
   LDFLAGS  =  -m64
else
   CFLAGS   =  -m32 -fPIC 
   LDFLAGS  =  -m32
endif

Using configure

As noted in Additional software components, the of

% ./configure CXXFLAGS="-m32 -fPIC" CFLAGS="-m32 -fPIC" LDFLAGS="-m32" FCFLAGS="-m32 -fPIC"

forces the genertaion of a Makefile ensuring 32 bit compatibility.

_ostream error message upon linking

If upon linking your code, you het the following message

/usr/bin/ld: MyCode: hidden symbol `void std::__ostream_fill<char, std::char_traits<char>(std::basic_ostream<char, std::char_traits<char> >&, long)' isn't defined
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: ld returned 1 exit status
make: *** [MyCode] Error 1

you bumped onto a gcc compiler bug which mangles symbols upon compilation (inlining) but cannot resolve them at link time because the symbols do not exists in the system library (apparently a miss). You then need to add -fno-inline to your compilation option. Since this flag may have performance side effects, do not use it systematically.

Using  libraries and packages

For using the CERN libraries or other libraries transparently, you are strongly advised NOT to refer to it directly but use the setup scripts provided with those libraries. An example below for the CERNLib

CERNLIB = $(shell cernlib mathlib packlib kernlib jetset74)

...

# Then your link may look like
$(EXE): $(OBJECTS)
   $(FC) -o $(EXE) $(OBJECTS) $(CERNLIB) $(LDFLASG)