Re: Difference between -shared, -symbolic, and -G?

[Joseph Garvin <joseph dot h dot garvin at gmail dot com>]

On Mon, Oct 19, 2009 at 5:44 PM, Ian Lance Taylor <iant@google.com> wrote:
> The -G option takes an argument, which is the size of data which is
> considered "small." ?This is only meaningful on a few targets, such as
> MIPS. ?I don't really understand your questions about it.

Weird... it's what our build environment is using to indicate it wants
a shared library O_o

It turns out this is the appropriate flag for sun studio's compiler, I
think it was being used by mistake. GCC still generates a .so as long
as you do -o filename.so, and the resulting file is definitely still
loaded at runtime when linked against (verified RPATH gets searched by
deleting file and having app complain). But is it being shared between
processes? What happens if you -l a library that was compiled with
-fpic but not -shared or -symbolic? Does GCC infer that you should've
specified them based on the filename ending in .so?

> The -symbolic option modifies -shared to indicate that all symbols
> should be resolved locally. ?Normally the executable may override a
> symbol defined in a shared library, so that if function f() in the
> shared library calls g() in the shared library, if the executable
> defines g(), then f() will call g() from the executable. ?The
> -symbolic option reverses this so that f() will call g() from the
> shared library. ?In most cases it's better to use explicit symbol
> visibility rather than -symbolic.

Why is it better? In the absence of explicit symbol visibility (a
bigger undertaking than just changing a compile flag) would you agree
that symbolic makes more sense than shared? Symbolic sounds like a
much saner default -- I think it's almost always what you want. If an
app accidentally has a function that has the same name as my library,
I don't want the wrong version getting called. It's intuitive that an
app calling f() get it's version of f() and a library calling f() gets
its version of f().