On Mon, Oct 19, 2009 at 5:44 PM, Ian Lance Taylor <iant@xxxxxxxxxx> 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().
