>>>>> On Mon, 26 Aug 2002 21:45:43 +0200 (CEST),
	Johnny Billquist <bqt@update.uu.se> said:

>> And even if there is a way to get such symbols. There is a still
>> following problem:
>> http://mail-index.netbsd.org/tech-userlevel/2001/12/22/0002.html

> And global state isn't the big problem, that I can see, but global
> information, such as errno, and global files, such as stdin, stdout and
> stderr. State variables are tied to the code, and if you run separate
> code, with separate state variables, you get no conflicts, even though
> both sets might be doing the same thing. It's just inefficient.

> (Someone will probably prove me wrong 3 seconds after I post this. :-)

Unfortunetely you are wrong as you imagined. ;-)

Think about the follows:
	- program A calls ungetc() and DYNAMIC_FUNC() with
	  argument FILE *fp. And ungetc() is statically linked 
	  with A, but DYNAMIC_FUNC() is called via dlopen().
	- The DYNAMIC_FUNC() calls vscanf() internally,
	  but since A doesn't call vscanf() directly, vscanf() is
	  linked dynamically.
	- Then, think about a case that internal handling of
	  FILE structure is somewhat different between old libc,
	  which is statically linked with program A, and new libc,
	  which is dynamically linked with DYNAMIC_FUNC().
	  In this case, ungetc() and vscanf() modify the fp
	  with inconsist way. This makes the program A fail to work.

This is not armchair theory. The way to handle _ub._base in FILE
structure was changed between NetBSD-1.5 and NetBSD-1.6.
--
soda