Doug Rabson wrote: > > It _would_ be a good idea to document any internal library > > symbols used by macros. Removing such symbols is a > > good way to break existing compiled applications. > > > > Library design involves a lot of tradeoffs. > > In the windows world, all this is handled by having a strict list of explicit > symbol exports, either in the source code using syntax extensions or with a > file supplied to the linker. I'm not sure whether binutils supports this kind > of thing but it would allow us to cut down the set of symbols exported from > libc.so.
Linux does it, so binutils supports it. Linux does this for kernel modules, and for libraries. On Linux, glibc2 (or whatever it's called this morning) does not export any symbols that it uses internally. In the general case, it's better to eat some small amount of overhead, than to export a data interface. Note that data interfaces get in the way of the LGPL "relink" clause for shared libraries. For example, if you had a GPL'ed program that was written in Modula 3 or FORTRAN 95, that had a reference to the __sF, then distribution of that program would demand distribution of the intermediate library source code, where normally it would not be required, due to the "relink clause" not being satisfied, since an attempt to link against the 5.0 libc would fail. Data interfaces are a pain in the ass legally, as well as making your code not work. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
