From: "Arsen Arsenović" <arsen@aarsen.me>
To: libstdc++ <libstdc++@gcc.gnu.org>
Cc: Gcc <gcc@gcc.gnu.org>
Subject: libstdc++ -> libiconv depenedncy: implications on in-tree libiconv
Date: Sun, 14 Apr 2024 02:34:55 +0200 [thread overview]
Message-ID: <867ch0rdcg.fsf@aarsen.me> (raw)
[-- Attachment #1: Type: text/plain, Size: 2237 bytes --]
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ć
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 381 bytes --]
reply other threads:[~2024-04-14 0:35 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=867ch0rdcg.fsf@aarsen.me \
--to=arsen@aarsen.me \
--cc=gcc@gcc.gnu.org \
--cc=libstdc++@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).