Mail Archives: djgpp-workers/1999/10/21/07:58:48
On Thu, 21 Oct 1999, Diego Zuccato wrote:
> Well, but in which order are FSEXTs defined in 3rd party libraries
> called ?
That's something for the library author to decide upon. All we can do is
provide infrastructure for the author to make this decision.
If you think such a decision is impossible in principle, please tell why.
If I would need to decide, I'd place my handler between the one from libc
(if there is one) and the application. If there are other non-libc
handlers installed before mine, I'd chain to them if I don't handle the
call.
> That's not easy to define... If link order is important, then each FSEXT
> could register itself at queue's tail (IIRC, constructors are called in
> link order, right ?).
That's exactly the problem with the current setup, where the services are
hooked in a function declared as __attribute__((constructor)).
> > How can several libraries define the order manually? I don't think
> > there's a provision for this in the current fsext code.
>
> It could be link order.
Link order is user-defined; a library has no control on it.
> "gcc usercode.c lib1.a lib2.a" will use services from lib1, but
> "gcc usercode.c lib2.a lib1.a" will use services from lib2 ... This way
> it's completly under user control...
We need to give the control to the library author, rather than to the end
user who links the program. The reason for this is that more often than
not, the end user doesn't know about all the intricacies of what's going
on under the hood in libraries they use.
For example, how many people who use the DJGPP ports of GNU ls or Ispell
know that both of these have an fsext inside? Heck, even Info uses an
fsext. How many people know that, or care?
By the same token, a user who links the application against libsocket
usually couldn't care less what magic is used to fake /dev/pty or
some such. We cannot expect users to make these critical decisions.
- Raw text -