blocks|key|2585948|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2585949|我注意到.so文件中存在重复的符号|blockquote|2585950|2585951|2585952|是像这样吗？|2585953|$+cat+foo.c
int+foo(void)
{
++++return+42;
}|code-block|syntax|javascript|2585954|编译：|2585955|$+gcc+-Wall+-fPIC+-c+foo.c|2585956|检查目标文件中的符号是否为foo|offset|length|style|CODE|2585957|$+readelf+-s+foo.o+%7C+grep+foo
+++++1:+0000000000000000+++++0+FILE++++LOCAL++DEFAULT++ABS+foo.c
+++++8:+0000000000000000++++11+FUNC++++GLOBAL+DEFAULT++++1+foo|2585958|一击即中。|2585959|创建一个共享库：|2585960|$+gcc+-Wall+-shared+-o+libfoo.so+foo.o|2585961|检查foo共享库中的符号|2585962|$+readelf+-s+libfoo.so+%7C+grep+foo
+++++5:+000000000000057a++++11+FUNC++++GLOBAL+DEFAULT++++9+foo
++++29:+0000000000000000+++++0+FILE++++LOCAL++DEFAULT++ABS+foo.c
++++44:+000000000000057a++++11+FUNC++++GLOBAL+DEFAULT++++9+foo|2585963|现在是两次命中。|2585964|这里没什么问题。查看更多图片：|2585965|$+readelf+-s+foo.o+%7C+egrep+'(foo%7CSymbol+table%7CNdx)'+
Symbol+table+'.symtab'+contains+9+entries:
+++Num:++++Value++++++++++Size+Type++++Bind+++Vis++++++Ndx+Name
+++++1:+0000000000000000+++++0+FILE++++LOCAL++DEFAULT++ABS+foo.c
+++++8:+0000000000000000++++11+FUNC++++GLOBAL+DEFAULT++++1+foo|2585966|目标文件有一个符号表，即其静态符号表.symtab，链接器使用该符号表进行链接时符号解析。但是：|2585967|$+readelf+-s+libfoo.so+%7C+egrep+'(foo%7CSymbol+table%7CNdx)'+
Symbol+table+'.dynsym'+contains+11+entries:
+++Num:++++Value++++++++++Size+Type++++Bind+++Vis++++++Ndx+Name
+++++5:+000000000000057a++++11+FUNC++++GLOBAL+DEFAULT++++9+foo
Symbol+table+'.symtab'+contains+48+entries:
+++Num:++++Value++++++++++Size+Type++++Bind+++Vis++++++Ndx+Name
++++29:+0000000000000000+++++0+FILE++++LOCAL++DEFAULT++ABS+foo.c
++++44:+000000000000057a++++11+FUNC++++GLOBAL+DEFAULT++++9+foo|2585968|共享库有两个符号表:静态符号表.symtab和动态符号表.dynsym，前者类似于对象文件，后者由加载器用于运行时符号解析。|2585969|当您将目标文件链接到共享库中时，链接器默认情况下会将GLOBAL符号从它们的.symtab转换为共享库的.symtab和.dynsym，但在目标文件中具有HIDDEN+visibility的那些符号除外(这些符号是在编译时使用attribute+of+hidden+visibility定义的)。|2585970|目标文件中任何具有HIDDEN可见性的GLOBAL符号都会转录为具有DEFAULT可见性的LOCAL符号，并进入共享库的.symtab中，而根本不会转录到共享库的.dynsym中。因此，当共享库与其他任何东西链接时，链接器和加载器都不能看到编译时被HIDDEN的全局符号。|2585971|但除了隐藏的符号(通常没有)外，相同的全局符号将出现在共享库的.symtab和.dynsym表中。出现在两个表中的每个已定义的符号都具有相同的定义。|2585972|之后，OP评论|BOLD|2585973|2585974|我通过运行objdump+-T命令获取了符号表，理想情况下，该命令应该列出仅存在于动态符号表中的符号。|2585975|2585976|2585977|这让我们有了不同的解释，因为objdump+-T确实只报告了动态符号表(如readelf+--dyn-syms)。|2585978|请注意，该符号报告了两次：|2585979|...
00aab4d0++w+++DF+.text++0000003c++Base++++++++boost::asio::error::detail::misc_category::~misc_category()
...
00aab50c++w+++DF+.text++0000003c++Base++++++++boost::asio::error::detail::misc_category::~misc_category()
...|2585980|在第2列中分类为w+(代码片段中的所有其他符号也是如此)。objdump的意思是这个符号是weak。|2585981|让我们重复一下观察结果：|2585982|foo.hpp|2585983|#pragma+once
#include+<iostream>

struct+foo
{
++++explicit+foo(int+i)
++++:+_i{i}
++++{
++++++++std::cout+<<+__PRETTY_FUNCTION__+<<+std::endl;
++++}
++++~foo()
++++{
++++++++std::cout+<<+__PRETTY_FUNCTION__+<<+std::endl;
++++}
++++int+_i+=+0;
};|2585984|bar.cpp|2585985|#include+"foo.hpp"

foo+bar()
{
++++return+foo(2);
}|2585986|gum.cpp|2585987|#include+"foo.hpp"

foo+gum()
{
++++return+foo(1);
}|2585988|编译并创建一个共享库：|2585989|$+g%2B%2B+-Wall+-Wextra+-c+-fPIC+bar.cpp+gum.cpp
$+g%2B%2B+-shared+-o+libbargum.so+bar.o+gum.o|2585990|查看struct+foo中objdump报告的动态符号|2585991|$+objdump+-CT+libbargum.so+%7C+grep+'foo::'
00000000000009bc++w+++DF+.text++0000000000000046++Base++++++++foo::foo(int)
00000000000009bc++w+++DF+.text++0000000000000046++Base++++++++foo::foo(int)|2585992|构造函数foo::foo(int)的弱导出重复。就像你注意到的那样。|2585993|稍等片刻。foo::foo(int)是一个C%2B%2B方法签名，但实际上不是链接器可以识别的符号。让我们再来一次，这一次没有去角色化：|2585994|$+objdump+-T+libbargum.so+%7C+grep+'foo'
00000000000009bc++w+++DF+.text++0000000000000046++Base++++++++_ZN3fooC1Ei
00000000000009bc++w+++DF+.text++0000000000000046++Base++++++++_ZN3fooC2Ei|2585995|现在我们看到链接器看到的符号，不再看到重复的符号：_ZN3fooC1Ei+!=+_ZN3fooC2Ei，尽管这两个符号具有相同的地址和|2585996|$+c%2B%2Bfilt+_ZN3fooC1Ei
foo::foo(int)
$+c%2B%2Bfilt+_ZN3fooC2Ei
foo::foo(int)|2585997|它们都指向同一件事，foo::foo(int)。实际上，有5个不同的符号-+_ZN3fooCNEi，代表1+<=+N+<=+5-与foo::foo(int)成反比。(+g%2B%2B实际上在对象文件bar.o和gum.o中使用了_ZN3fooC1Ei、_ZN3fooC2Ei和_ZN3fooC5Ei+)。|2585998|因此，在现实中，动态符号表中没有重复的符号:隐藏的多对一的名称分离映射使其看起来是这样的。|2585999|但为什么呢？|2586000|对于这里来说，这个问题的答案恐怕太长太复杂了。|2586001|执行摘要|2586002|GCC+C%2B%2B编译器使用两个相同的弱符号，以不同的方式引用一个全局内联类方法，作为其允许在位置无关代码中成功链接全局内联类方法的库存公式的一部分。对于任何编译器来说，这都是一个不可回避的问题，而针对它的GCC公式也不是唯一可能的。Clang有一个不同的解决方案，它确实涉及到使用同义但不同的符号，因此不会产生您所见过的虚幻的“重复”符号。|2586003|entityMap|0|LINK|mutability|MUTABLE|url|https://gcc.gnu.org/wiki/Visibility|1|https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes|2|https://linux.die.net/man/1/objdump|3|https://en.wikipedia.org/wiki/Weak_symbol^0|0|0|0|0|0|0|0|0|D|3|0|0|0|0|0|2|3|0|0|0|0|0|I|7|0|0|F|7|S|7|0|Q|6|12|7|1G|7|1O|7|25|6|2C|A|0|35|U|1|0|9|6|J|6|Y|7|19|5|1O|7|29|7|3G|6|0|V|7|13|7|0|0|7|0|0|0|0|0|E|A|11|I|0|0|0|8|1|T|7|T|7|2|19|4|3|0|0|0|7|0|0|0|7|0|0|0|7|0|0|0|0|2|A|D|7|0|0|4|D|0|5|D|0|0|P|B|14|B|0|0|A|D|12|8|1B|2|1T|D|2C|3|2N|5|2T|5|32|B|3E|B|3Q|B|0|0|0|6|0|0|0|0^^$0|@$1|2|3|-4|4|5|6|3S|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|3T|7|@]|8|@]|9|$]]|$1|D|3|-4|4|5|6|3U|7|@]|8|@]|9|$]]|$1|E|3|-4|4|5|6|3V|7|@]|8|@]|9|$]]|$1|F|3|G|4|5|6|3W|7|@]|8|@]|9|$]]|$1|H|3|I|4|J|6|3X|7|@]|8|@]|9|$K|L]]|$1|M|3|N|4|5|6|3Y|7|@]|8|@]|9|$]]|$1|O|3|P|4|J|6|3Z|7|@]|8|@]|9|$K|L]]|$1|Q|3|R|4|5|6|40|7|@$S|41|T|42|U|V]]|8|@]|9|$]]|$1|W|3|X|4|J|6|43|7|@]|8|@]|9|$K|L]]|$1|Y|3|Z|4|5|6|44|7|@]|8|@]|9|$]]|$1|10|3|11|4|5|6|45|7|@]|8|@]|9|$]]|$1|12|3|13|4|J|6|46|7|@]|8|@]|9|$K|L]]|$1|14|3|15|4|5|6|47|7|@$S|48|T|49|U|V]]|8|@]|9|$]]|$1|16|3|17|4|J|6|4A|7|@]|8|@]|9|$K|L]]|$1|18|3|19|4|5|6|4B|7|@]|8|@]|9|$]]|$1|1A|3|1B|4|5|6|4C|7|@]|8|@]|9|$]]|$1|1C|3|1D|4|J|6|4D|7|@]|8|@]|9|$K|L]]|$1|1E|3|1F|4|5|6|4E|7|@$S|4F|T|4G|U|V]]|8|@]|9|$]]|$1|1G|3|1H|4|J|6|4H|7|@]|8|@]|9|$K|L]]|$1|1I|3|1J|4|5|6|4I|7|@$S|4J|T|4K|U|V]|$S|4L|T|4M|U|V]]|8|@]|9|$]]|$1|1K|3|1L|4|5|6|4N|7|@$S|4O|T|4P|U|V]|$S|4Q|T|4R|U|V]|$S|4S|T|4T|U|V]|$S|4U|T|4V|U|V]|$S|4W|T|4X|U|V]]|8|@$S|4Y|T|4Z|1|50]|$S|51|T|52|1|53]]|9|$]]|$1|1M|3|1N|4|5|6|54|7|@$S|55|T|56|U|V]|$S|57|T|58|U|V]|$S|59|T|5A|U|V]|$S|5B|T|5C|U|V]|$S|5D|T|5E|U|V]|$S|5F|T|5G|U|V]|$S|5H|T|5I|U|V]]|8|@]|9|$]]|$1|1O|3|1P|4|5|6|5J|7|@$S|5K|T|5L|U|V]|$S|5M|T|5N|U|V]]|8|@]|9|$]]|$1|1Q|3|1R|4|5|6|5O|7|@$S|5P|T|5Q|U|1S]]|8|@]|9|$]]|$1|1T|3|-4|4|5|6|5R|7|@]|8|@]|9|$]]|$1|1U|3|1V|4|C|6|5S|7|@]|8|@]|9|$]]|$1|1W|3|-4|4|5|6|5T|7|@]|8|@]|9|$]]|$1|1X|3|-4|4|5|6|5U|7|@]|8|@]|9|$]]|$1|1Y|3|1Z|4|5|6|5V|7|@$S|5W|T|5X|U|V]|$S|5Y|T|5Z|U|V]]|8|@]|9|$]]|$1|20|3|21|4|5|6|60|7|@]|8|@]|9|$]]|$1|22|3|23|4|J|6|61|7|@]|8|@]|9|$K|L]]|$1|24|3|25|4|5|6|62|7|@$S|63|T|64|U|V]|$S|65|T|66|U|V]]|8|@$S|67|T|68|1|69]|$S|6A|T|6B|1|6C]]|9|$]]|$1|26|3|27|4|5|6|6D|7|@]|8|@]|9|$]]|$1|28|3|29|4|5|6|6E|7|@$S|6F|T|6G|U|1S]]|8|@]|9|$]]|$1|2A|3|2B|4|J|6|6H|7|@]|8|@]|9|$K|L]]|$1|2C|3|2D|4|5|6|6I|7|@$S|6J|T|6K|U|1S]]|8|@]|9|$]]|$1|2E|3|2F|4|J|6|6L|7|@]|8|@]|9|$K|L]]|$1|2G|3|2H|4|5|6|6M|7|@$S|6N|T|6O|U|1S]]|8|@]|9|$]]|$1|2I|3|2J|4|J|6|6P|7|@]|8|@]|9|$K|L]]|$1|2K|3|2L|4|5|6|6Q|7|@]|8|@]|9|$]]|$1|2M|3|2N|4|J|6|6R|7|@]|8|@]|9|$K|L]]|$1|2O|3|2P|4|5|6|6S|7|@$S|6T|T|6U|U|V]|$S|6V|T|6W|U|V]]|8|@]|9|$]]|$1|2Q|3|2R|4|J|6|6X|7|@]|8|@]|9|$K|L]]|$1|2S|3|2T|4|5|6|6Y|7|@$S|6Z|T|70|U|V]]|8|@]|9|$]]|$1|2U|3|2V|4|5|6|71|7|@$S|72|T|73|U|V]]|8|@]|9|$]]|$1|2W|3|2X|4|J|6|74|7|@]|8|@]|9|$K|L]]|$1|2Y|3|2Z|4|5|6|75|7|@$S|76|T|77|U|V]|$S|78|T|79|U|V]]|8|@]|9|$]]|$1|30|3|31|4|J|6|7A|7|@]|8|@]|9|$K|L]]|$1|32|3|33|4|5|6|7B|7|@$S|7C|T|7D|U|V]|$S|7E|T|7F|U|V]|$S|7G|T|7H|U|V]|$S|7I|T|7J|U|V]|$S|7K|T|7L|U|V]|$S|7M|T|7N|U|V]|$S|7O|T|7P|U|V]|$S|7Q|T|7R|U|V]|$S|7S|T|7T|U|V]|$S|7U|T|7V|U|V]]|8|@]|9|$]]|$1|34|3|35|4|5|6|7W|7|@]|8|@]|9|$]]|$1|36|3|37|4|5|6|7X|7|@$S|7Y|T|7Z|U|1S]]|8|@]|9|$]]|$1|38|3|39|4|5|6|80|7|@]|8|@]|9|$]]|$1|3A|3|3B|4|5|6|81|7|@]|8|@]|9|$]]|$1|3C|3|3D|4|5|6|82|7|@]|8|@]|9|$]]|$1|3E|3|-4|4|5|6|83|7|@]|8|@]|9|$]]]|3F|$3G|$4|3H|3I|3J|9|$3K|3L]]|3M|$4|3H|3I|3J|9|$3K|3N]]|3O|$4|3H|3I|3J|9|$3K|3P]]|3Q|$4|3H|3I|3J|9|$3K|3R]]]]

<blockquote>
 I am noticing duplicate symbols present in .so file
</blockquote>

Like this?

<pre><code>$ cat foo.c
int foo(void)
{
 return 42;
}
</code></pre>

Compile:

<pre><code>$ gcc -Wall -fPIC -c foo.c
</code></pre>

Check symbols in the object file for <code>foo</code>:

<pre><code>$ readelf -s foo.o | grep foo
 1: 0000000000000000 0 FILE LOCAL DEFAULT ABS foo.c
 8: 0000000000000000 11 FUNC GLOBAL DEFAULT 1 foo
</code></pre>

One hit.

Make a shared library:

<pre><code>$ gcc -Wall -shared -o libfoo.so foo.o
</code></pre>

Check symbols in the shared library for <code>foo</code>:

<pre><code>$ readelf -s libfoo.so | grep foo
 5: 000000000000057a 11 FUNC GLOBAL DEFAULT 9 foo
 29: 0000000000000000 0 FILE LOCAL DEFAULT ABS foo.c
 44: 000000000000057a 11 FUNC GLOBAL DEFAULT 9 foo
</code></pre>

Now two hits.

Nothing is wrong here. See some more of the picture:

<pre><code>$ readelf -s foo.o | egrep '(foo|Symbol table|Ndx)' 
Symbol table '.symtab' contains 9 entries:
 Num: Value Size Type Bind Vis Ndx Name
 1: 0000000000000000 0 FILE LOCAL DEFAULT ABS foo.c
 8: 0000000000000000 11 FUNC GLOBAL DEFAULT 1 foo
</code></pre>

An object file has one symbol table, its static symbol table <code>.symtab</code>,
that is used by the linker for link-time symbol resolution. But:

<pre><code>$ readelf -s libfoo.so | egrep '(foo|Symbol table|Ndx)' 
Symbol table '.dynsym' contains 11 entries:
 Num: Value Size Type Bind Vis Ndx Name
 5: 000000000000057a 11 FUNC GLOBAL DEFAULT 9 foo
Symbol table '.symtab' contains 48 entries:
 Num: Value Size Type Bind Vis Ndx Name
 29: 0000000000000000 0 FILE LOCAL DEFAULT ABS foo.c
 44: 000000000000057a 11 FUNC GLOBAL DEFAULT 9 foo
</code></pre>

a shared library has two symbol tables: a static symbol table <code>.symtab</code>, like
an object file, plus a dynamic symbol table, <code>.dynsym</code>, used by the loader for run-time symbol resolution.

When you link object files into a shared library, the linker by default transcribes the
<code>GLOBAL</code> symbols from their <code>.symtab</code>s into the <code>.symtab</code> and the <code>.dynsym</code> of the shared
library, except for those symbols that have <code>HIDDEN</code> <a href="https://gcc.gnu.org/wiki/Visibility" rel="nofollow noreferrer">visibility</a> in the object files
(which they get from being defined with the <a href="https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes" rel="nofollow noreferrer">attribute of hidden visibility</a>
at compilation).

Any <code>GLOBAL</code> symbols with <code>HIDDEN</code> visibility in the object files are transcribed as <code>LOCAL</code> symbols
with <code>DEFAULT</code> visibility into the <code>.symtab</code> of the shared library and are not transcribed
into the <code>.dynsym</code> of the shared library at all. So when the shared library is linked with
anything else, neither the linker nor the loader can see the global symbols that were <code>HIDDEN</code> at compilation.

But apart from hidden symbols, of which there are often none, the same global symbols
will appear in the <code>.symtab</code> and the <code>.dynsym</code> tables of a shared library. Each defined symbol
that appears in both tables addresses the same definition.

Later, OP comments

<blockquote>
 I took the symbol table by running objdump -T command, which should ideally list symbols present only in dynamic symbol table.
</blockquote>

This steers us to a different explanation, because <code>objdump -T</code> does indeed report only
the dynamic symbol table (like <code>readelf --dyn-syms</code>).

Notice that the symbol reported twice:

<pre><code>...
00aab4d0 w DF .text 0000003c Base boost::asio::error::detail::misc_category::~misc_category()
...
00aab50c w DF .text 0000003c Base boost::asio::error::detail::misc_category::~misc_category()
...
</code></pre>

is classified <code>w</code> in column 2 (as are all the other symbols in your snippet). What <a href="https://linux.die.net/man/1/objdump" rel="nofollow noreferrer"><code>objdump</code></a> means by that is
that the symbol is <a href="https://en.wikipedia.org/wiki/Weak_symbol" rel="nofollow noreferrer">weak</a>.

Let's repoduce the observation:

foo.hpp

<pre><code>#pragma once
#include &lt;iostream&gt;

struct foo
{
 explicit foo(int i)
 : _i{i}
 {
 std::cout &lt;&lt; __PRETTY_FUNCTION__ &lt;&lt; std::endl;
 }
 ~foo()
 {
 std::cout &lt;&lt; __PRETTY_FUNCTION__ &lt;&lt; std::endl;
 }
 int _i = 0;
};
</code></pre>

bar.cpp

<pre><code>#include "foo.hpp"

foo bar()
{
 return foo(2);
}
</code></pre>

gum.cpp

<pre><code>#include "foo.hpp"

foo gum()
{
 return foo(1);
}
</code></pre>

Compile and make a shared library:

<pre><code>$ g++ -Wall -Wextra -c -fPIC bar.cpp gum.cpp
$ g++ -shared -o libbargum.so bar.o gum.o
</code></pre>

See what dynamic symbols <code>objdump</code> reports from <code>struct foo</code>:

<pre><code>$ objdump -CT libbargum.so | grep 'foo::'
00000000000009bc w DF .text 0000000000000046 Base foo::foo(int)
00000000000009bc w DF .text 0000000000000046 Base foo::foo(int)
</code></pre>

Duplicate weak exports of the constructor <code>foo::foo(int)</code>. Just like what you
noticed.

Hang on a tick though. <code>foo::foo(int)</code> is a C++ method signature, but not
actually a symbol that the linker can recognise. Let's do that again, this time
without demangling:

<pre><code>$ objdump -T libbargum.so | grep 'foo'
00000000000009bc w DF .text 0000000000000046 Base _ZN3fooC1Ei
00000000000009bc w DF .text 0000000000000046 Base _ZN3fooC2Ei
</code></pre>

Now we see the symbols the linker sees, and the duplication is no longer to be seen:
<code>_ZN3fooC1Ei</code> != <code>_ZN3fooC2Ei</code>, although both symbols have the same address and

<pre><code>$ c++filt _ZN3fooC1Ei
foo::foo(int)
$ c++filt _ZN3fooC2Ei
foo::foo(int)
</code></pre>

they both demangle to the same thing, <code>foo::foo(int)</code>. There are in fact 5
distinct symbols - <code>_ZN3fooC</code>N<code>Ei</code>, for 1 &lt;= N &lt;= 5 - that demangle to <code>foo::foo(int)</code>.
(And <code>g++</code> actually uses <code>_ZN3fooC1Ei</code>, <code>_ZN3fooC2Ei</code> and <code>_ZN3fooC5Ei</code> in the object
files <code>bar.o</code> and <code>gum.o</code>). 

So in reality, there are no duplicated symbols in the dynamic symbol table: the
sneaky many-to-one nature of the name-demangling mapping just makes it look that way.

But why?

I'm afraid the answer to that is too long and complicated for here.

Executive Summary

The GCC C++ compiler employs the two weak symbols that
demangle identically to refer to a global inline class-method in different ways, as part of
its stock formula for enabling the successful linkaqe of global inline class-methods in Position Independent Code.
This is a non-neglible problem for any compiler, and the GCC formula for it is not the only possible one. Clang has a different
solution, that does involve the use of synonymous but distinct symbols and so doesn't
give rise to the illusory "duplication" of symbols that you've seen.

I am new to c++ symbol tables and libraries, wanted to understand the behavior of symbol table.
We are having an android application with native support on it. In process of analyzing symbol tables of shared libraries, I am noticing duplicate symbols present in .so file. Please find the sample list of symbol table.

<pre><code>0162502c w DO .data 00000004 Base boost::asio::error::get_addrinfo_category()::instance

00aaa4f4 w DF .text 0000009c Base boost::asio::error::get_misc_category()

01626334 w DO .bss 00000004 Base guard variable for boost::asio::error::get_misc_category()::instance

00aab4d0 w DF .text 0000003c Base boost::asio::error::detail::misc_category::~misc_category()

00aab368 w DF .text 0000003c Base boost::asio::error::detail::addrinfo_category::~addrinfo_category()

00aab3a4 w DF .text 00000034 Base boost::asio::error::detail::addrinfo_category::name() const

00aab3d8 w DF .text 000000f8 Base boost::asio::error::detail::addrinfo_category::message(int) const

00aab50c w DF .text 0000003c Base boost::asio::error::detail::misc_category::~misc_category()
</code></pre>

Here you can notice following symbol "boost::asio::error::detail::misc_category::~misc_category()" appearing twice.

I wanted to understand why are we getting duplicate symbols in symbol table. Also interested to know why my app is running fine when there are duplicate symbols [ which linker should ideally throw duplicate symbols error ] Also would like to know does having duplicate symbols in symbol tables would increase the size of "so" eventually leading to increasing in the size of app 

If this happens, how could I ensure that I get only unique entries in symbol table.
Note:- we are using clang

C++ shared libraries have duplicate symbols

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我是c++符号表和库的新手，想要了解符号表的行为。我们有一个具有原生支持的android应用程序。在分析共享库的符号表的过程中，我注意到.so文件中存在重复的符号。请查看符号表的示例列表。0162502c  w   DO .data  00000004  Base        boost::asio::error::...

C++共享库具有重复的符号-腾讯云开发者社区-腾讯云

问C++共享库具有重复的符号
EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问C++共享库具有重复的符号EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问C++共享库具有重复的符号
EN