mips64el: binutils: Rewrite the explanation of --enable-default-hash-style=gnu

On MIPS there are some differences in the classic ELF hash table vs.
GNU-style hash table decision.
This commit is contained in:
Xi Ruoyao 2024-01-05 04:03:08 +08:00
parent e871ed6001
commit 6de49cb73c
No known key found for this signature in database
GPG Key ID: ACAAD20E19E710E3

View File

@ -136,16 +136,16 @@ cd build</userinput></screen>
<varlistentry> <varlistentry>
<term><parameter>--enable-default-hash-style=gnu</parameter></term> <term><parameter>--enable-default-hash-style=gnu</parameter></term>
<listitem> <listitem>
<para>By default, the linker would generate both the GNU-style <para>By default, the linker would generate the classic ELF hash
hash table and the classic ELF hash table for shared libraries and table for shared libraries and dynamically linked executables
dynamically linked executables. The hash tables are only intended because the GNU-style hash table is incompatible with the MIPS o32
for a dynamic linker to perform symbol lookup. On LFS the dynamic ABI. The hash tables are only intended for a dynamic linker to
linker (provided by the Glibc package) will always use the perform symbol lookup. On LFS the dynamic linker (provided by the
GNU-style hash table which is faster to query. So the classic Glibc package) supports the GNU-style hash table, and this LFS
ELF hash table is completely useless. This makes the linker edition does not support the o32 ABI. So this is used to make the
only generate the GNU-style hash table by default, so we can avoid linker generate the GNU-style hash table instead of the classic
wasting time to generate the classic ELF hash table when we build ELF hash table by default, as the GNU-style hash table is faster
the packages, or wasting disk space to store it.</para> to query.</para>
</listitem> </listitem>
</varlistentry> </varlistentry>