On Mon, Nov 26, 2018 at 11:30:51AM -0500, Mathieu Desnoyers wrote: > ----- On Nov 26, 2018, at 10:51 AM, Mathieu Desnoyers mathieu.desnoyers@xxxxxxxxxxxx wrote: > > > ----- On Nov 26, 2018, at 3:28 AM, Florian Weimer fweimer@xxxxxxxxxx wrote: > > > >> * Mathieu Desnoyers: > >> > >>> Using a "weak" symbol in early adopter libraries is important, so they > >>> can be loaded together into the same process without causing loader > >>> errors due to many definitions of the same strong symbol. > >> > >> This is not how ELF dynamic linking works. If the symbol name is the > >> same, one definition interposes the others. > >> > >> You need to ensure that the symbol has the same size everywhere, though. > >> There are some tricky interactions with symbol versions, too. (The > >> interposing libraries must not use symbol versioning.) > > > > I was under the impression that loading the same strong symbol into an > > application multiple times would cause some kind of warning if non-weak. I did > > some testing to figure out which case I remembered would cause this. > > > > When compiling with "-fno-common", dynamic and static linking work fine, but > > trying to add multiple instances of a given symbol into a single object fails > > with: > > > > /tmp/ccSakXZV.o:(.bss+0x0): multiple definition of `a' > > /tmp/ccQBJBOo.o:(.bss+0x0): first defined here > > > > Even if the symbol has the same size. > > > > So considering that we don't care about compiling into a single object here, > > and only care about static and dynamic linking of libraries, indeed the "weak" > > symbol is not useful. > > > > So let's make __rseq_abi and __rseq_refcount strong symbols then ? > > Actually, looking into ld(1) --warn-common, it looks like "weak" would be cleaner > after all, especially for __rseq_abi which we needs to be initialized to a specific > value, which is therefore not a common symbol. > > " --warn-common > Warn when a common symbol is combined with another common symbol or with a symbol definition. Unix > linkers allow this somewhat sloppy practice, but linkers on some other operating systems do not. > This option allows you to find potential problems from combining global symbols. Unfortunately, > some C libraries use this practice, so you may get some warnings about symbols in the libraries as > well as in your programs." > > Thoughts ? AFAIK this has nothing to do with dynamic linking. Rich