This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/12234] iconvlist API
- From: "jan.kratochvil at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: Tue, 7 Dec 2010 16:48:27 +0000
- Subject: [Bug libc/12234] iconvlist API
- Auto-submitted: auto-generated
- References: <bug-12234-131@http.sourceware.org/bugzilla/>
http://sourceware.org/bugzilla/show_bug.cgi?id=12234
--- Comment #6 from Jan Kratochvil <jan.kratochvil at redhat dot com> 2010-12-07 16:48:14 UTC ---
(In reply to comment #5)
> (In reply to comment #4)
> > This idea contradicts "How To Write Shared Libraries", section 1.6.
>
> You seem to miss how the PIE solution would work. The iconv program would
> continue to work as before. It'd just be loaded slightly differently. But at
> the same time you could use the same file in dlopen() and then get a pointer to
> a function which returns the list.
GDB will have to load two shared libraries (glibc+iconv) instead of just one
(glibc). This is against the "How To Write Shared Libraries" recommendation.
> I was asking why this is a bottleneck for you in the
> first place. This is something which has to be done in response to a user
> action. The command line interaction of the user should be much slower than
> any fork and reading the result.
GDB is also being called from various scripts. GDB currently does not allow to
make the iconv list initialization lazy due to its existing commands
infrastructure. Thanks for the advice how to optimize it on the GDB side.
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.