[Bug libc/12234] iconvlist API

["drepper.fsp at gmail dot com" <sourceware-bugzilla at sourceware dot org>]

http://sourceware.org/bugzilla/show_bug.cgi?id=12234

--- Comment #5 from Ulrich Drepper <drepper.fsp at gmail dot com> 2010-12-07 14:26:03 UTC ---
(In reply to comment #4)
> This is a chicken-and-egg problem.  How there can be a user of nonexisting API?

People could have tried to do exactly what you do today.  Nobody does.  This is
why I say there are no other users.


> This idea contradicts "How To Write Shared Libraries", section 1.6.
>   Number of Objects: The fact that a smaller number of objects containing
>   the same functionality is beneficial has been mentioned in several places
>   [...]

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.


> > But is it really worth the time?  The forking really shouldn't be that
> > expensive.
> 
> Isn't the prelink optimizing an even cheaper operation - dynamic relocating?

I don't quite follow.  Of course will any specialized solution to get the list
be faster than forking.  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.

-- 
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.