This is the mail archive of the binutils@sourceware.cygnus.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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


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

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

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 ?

Jose



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]