It seems like making it shared library would fix the issue then. Alternatively, you could make parlib rely on externed variables for determining if its ctors have ran (instead of local static ones). These could then be initialized only in the binary and not in any other .so.
On Wed, Feb 8, 2017 at 9:45 AM barret rhoden <[email protected]> wrote: > On 2017-02-08 at 16:26 Kevin Klues wrote: > > Why are there multiple copies of the parlib being loaded? Is it because > it > > is statically linked into both the binary and some other .so? I just > reread > > your original email, but its still not clear to me why they would both > have > > the ctors unless they both had a statically linked copy of parlib. > > Yeah, I think it's because we tell gcc to link everything with parlib.a, > whole-archive style. > > #define LINK_GCC_C_SEQUENCE_SPEC \ > "--whole-archive -lparlib --no-whole-archive " \ > "%{static:--start-group} %G %L %{static:--end-group}%{!static:%G}" > > The static libraries, e.g. libelf.a, don't get it. But the shared > objects, e.g. libelf.so, get a copy of parlib, including its ctors. > > -- > You received this message because you are subscribed to the Google Groups > "Akaros" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Akaros" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. For more options, visit https://groups.google.com/d/optout.
