Re: [new test case jluu@mainsoft.com: Re: Possible linker problem]

[Ian Lance Taylor <ian at zembu dot com>]

   From: "Jose Luu" <jluu@mainsoft.com>
   Date: Wed, 15 Mar 2000 19:56:35 +0100

   >To the best of my knowledge, the Windows linker behaviour is not
   >analogous to -Bsymbolic.  Windows uses an explicit list of exports,
   >typically marked by __dllspec.  -Bsymbolic provides no control over
   >exported symbols (as you have discovered).  If you want to emulate the
   >Windows behaviour, you should be generating linker version scripts
   >from lists of exported symbols.

   I agree on most of you points, and we do use linker exports list when
   available, however, under Windows, when 2 shared libs (or the main
   executable) export the same symbol, it is resolved first within the same
   library (ie -Bsymbolic way), this is why, in addition to using exports list,
   we do use Bsymbolic.

I see.  I wasn't considering the case of the symbol being explicitly
exported multiple times.

   The problem I am trying to solve originated with the global vars containing
   RTTI information generated by the g++ compiler, which have to be exported so
   that other shared libs (or the main) can use the dynamic subclassing. Now I
   am not very familiar with the symbol versioning and all the uses that can be
   made of it. I am going to investigate some more in this direction, right now
   I wonder if it can be used at all because, unlike my example in C, we have
   no control on how the variable is named (this is a mangled name like
   __ti14ParentClassDll), and how it is used (refer to my first test case
   t143).

Version scripts support shell matching for the symbol names.  You
could match on __ti* to catch all the typeinfo structs.

   Is it thinkable to add a flag that would be used when linking a main
   executable that would mean: "do not COPY symbols from shared objects" (this
   flag would apply to all symbols refered from the main executable and defined
   in shared lib)?
   What functionality would we be missing when using this flag ?

Simply omitting the COPY reloc would give you a program which did not
work.  The references in the main program would refer to uninitialized
memory.

The only way to omit the COPY reloc and also have the references in
the main program work correctly would be to generate dynamic relocs
for all the references in the main program.  This would of course
cause the main program to start more slowly.  Implementing this
correctly in the linker would be doable, but would not be trivial.

I actually don't understand why you are having trouble with the
typeinfo information, since as far as I know that information is
const.  It's true that the -Bsymbolic shared library and the main
program will be looking at different areas of memory, but so what?  If
the data doesn't change, it should work anyhow.

Ian