You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Don't build shared libopcodes for uClibc toolchain
There was a discrepancy between baremetal and Linux/uClibc toolchains.
Linux/uClibc toolchain had opcodes and bfd built as shared libraries, but
baremeatl had them linked statically into their users. Practically that
meant that location of those libraries should have been added too the
LD_LIBRARY_PATH for Linux/uClibc toolchain, while baremetal toolchain worked
just fine. Otherwise things worked just fine on Linux hosts. However on
macOS I've encountered a weird problem, where those dynamic libraries would
fail to load, complaining that symbols related to gettext/libintl cann't be
resolved. libintl itself is built as a static library, and presumably there
are some issues here on macOS. I've been too confused by macOS development
tools to understand better what exactly goes wrong there.
Solution is fairly obvious - make those libraries static, similarly to
baremetal toolchain. The original discrepancy has been caused by different
values of --enable-shared/--disable-shared used for baremetal and
Linux/uClibc. As far as I understand (I could be wrong here), value of
-shared is used by both libraries built for host and libraries built for
target. Historically ARC build scripts pass the value that is desired for
the target libraries - baremetal toolchain is static-only, Linux/uClibc
should use shared libraries. However, that was also affecting the host
libraries. To avoid discrepancy, with this patch build scripts now will pass
--disable-shared option to binutils configure script, thus making sure that
binutils doesn't produce undesired shared libraries.
Signed-off-by: Anton Kolesov <[email protected]>
0 commit comments