Re: Global Symbols and Version Scripts
On other ELF systems, I think there is a linker option that causes all symbols
to be resolved internally when the library is built. This should prevent
references to a symbol within a shared library from picking up a symbol of
the same name from another library.
On Tue, 15 Feb 2000 gk4@us.ibm.com wrote:
>
>
> Dale,
>
> Enclosed is a internal note that was sent to me which is LSB specific that
> I am not sure about. Could you or someone familiar with the "Shared
> Libraries and Naming Conventions" portion of the LSB specification comment
> on the note below?
>
> Thanks,
>
> George Kraft IV
> gk4@us.ibm.com
> 512-838-2688; t/l 678-2688
> IBM Linux Technology Center
>
>
> Just a word to those developers about a unique Linux issue.
>
> We have been developing a number of shared libs for our project. We have
> found that if two shared libs have the same external symbols declared and
> defined with them, then the first one loaded will be used for libraries
> loaded later. For example, we have a shared lib with the declaration and
> definition of the variable dgTrcExec which is a pointer to a variable
> length structure of trace information for that shared lib. In a second
> shared lib we again declare and define the same variable, dgTrcExec, to
> point to a similar structure, but with a different number of entries for
> that shared lib. What we have found is that if the first library is loaded,
> and then the second lib is loaded, all references to the second's internal
> dgTrcExec will refer to the variable in the first lib and not the one in
> the second. As a result, the second library will reference the wrong
> information or SIGSEGV is it references information beyond the end of the
> variable length structure. Not nice!
>
> So, how are we solving the problem... Because Linux exports all symbols by
> default, the only way we have found to eliminate this problem is to make
> these external symbols local, not global. [Naturally we could rename them
> to be unique for each shared lib, but that was not an option]. To make them
> local we defined a version script which lists each variable as local. For
> example, the version script file fontmanagerld.vs contains: VERS_1.0 {
> local: dgTrcExec; };
>
> So to summarize, some operating system platforms, such as AIX, assume all
> symbols are local and you must specify which are global using a export
> file. Linux is the opposite. It assumes that all symbols are global and you
> must specify which are local using a version script. As a result,
> programming that is being ported over from AIX, can have radically
> different behavior if you are not aware of differences such as this.
>
> EOR
>
>
>
> --
>
> To UNSUBSCRIBE, email to lsb-spec-request@lists.linuxbase.org
> with subject of "unsubscribe". Trouble? Email listmaster@lists.linuxbase.org
>
Stuart
Stuart R. Anderson anderson@metrolink.com
Metro Link Incorporated South Carolina Office
4711 North Powerline Road 129 Secret Cove Drive
Fort Lauderdale, Florida 33309 Lexington, SC 29072
voice: 954.938.0283 voice: 803.951.3630
fax: 954.938.1982 SkyTel: 800.405.3401
http://www.metrolink.com/
Reply to: