libstdc++ -> libiconv depenedncy: implications on in-tree libiconv
Arsen Arsenović
arsen@aarsen.me
Sun Apr 14 00:34:55 GMT 2024
Evening!
While working on
https://inbox.sourceware.org/20240414001113.1698685-1-arsen@aarsen.me/
I had noticed that libstdc++ currently does not get linked against an
in-tree libiconv, as the in-tree libiconv is only a host library.
Should it also be a target one?
With a quick hack of copying libiconv in the build dir as
arm64-apple-darwin21.6.0/libiconv, I had managed to get libstdc++ not to
link system libiconv. This implies that simply enabling building iconv
as a target library also would suffice.
There are considerations with this, though: naturally, this implies
that libstdc++ now contains a copy of libiconv as it gets linked in as a
'.a'. It appears not to cause a copy of the symbols to be emitted on
this platform:
cfarm104:gcc-build arsen$ objdump --syms ./aarch64-apple-darwin21.6.0/libstdc++-v3/src/.libs/libstdc++.6.dylib | grep iconv
cfarm104:gcc-build arsen$
... however, even in that case, the symbols are renamed AFAICT:
cfarm104:gcc-build arsen$ objdump --syms ./aarch64-apple-darwin21.6.0/libiconv/lib/.libs/libiconv.a | grep iconv
./aarch64-apple-darwin21.6.0/libiconv/lib/.libs/libiconv.a(iconv.o): file format mach-o arm64
00000000000dbbe0 g O __DATA,__data __libiconv_version
0000000000013730 g F __TEXT,__text _iconv_canonicalize
0000000000013080 g F __TEXT,__text _libiconv
00000000000130c0 g F __TEXT,__text _libiconv_close
0000000000012ca0 g F __TEXT,__text _libiconv_open
00000000000130e0 g F __TEXT,__text _libiconv_open_into
0000000000013468 g F __TEXT,__text _libiconvctl
00000000000135ac g F __TEXT,__text _libiconvlist
./aarch64-apple-darwin21.6.0/libiconv/lib/.libs/libiconv.a(localcharset.o): file format mach-o arm64
./aarch64-apple-darwin21.6.0/libiconv/lib/.libs/libiconv.a(relocatable.o): file format mach-o arm64
00000000000000e4 g F __TEXT,__text _libiconv_relocate
00000000000001e0 g F __TEXT,__text _libiconv_relocate2
0000000000000000 g F __TEXT,__text _libiconv_set_relocation_prefix
... so, that might be okay?
What do you think? Should be build a libiconv as a target lib for
libstdc++ use?
TIA, have a lovely night!
--
Arsen Arsenović
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 381 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/libstdc++/attachments/20240414/a86daee2/attachment.sig>
More information about the Libstdc++
mailing list