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

[Ian Lance Taylor <iant at google dot com>]

Joseph Garvin <joseph.h.garvin@gmail.com> writes:

> 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 filename is irrelevant.  You can see whether you have a shared
library by running readelf -h.  If it reports that the "Type" is "DYN"
then you have a shared library.

It may be that -G works in some gcc configurations with some
linkers--I'm not sure what machine you are running on.  The -shared
gcc option should work for all targets which support shared libraries.


>> 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().

Whether the behaviour is intuitive really depends upon what you are
trying to do.  For example, there are debugging malloc libraries which
work by setting LD_PRELOAD to point to the malloc library.  That kind
of thing would fail if libc.so were linked with -symbolic.  Sometimes
you want calls to always be local, sometimes you want to permit other
symbols to be interposed.  Explicit symbol visibility lets you choose.
You can specify symbol visibility either in the source code or in a
linker script.

If you are happy with -symbolic then go ahead and use it, but don't
forget that you're doing so.  I've seen people get bitten later on by
a forgotten -symbolic.

Ian