This is the mail archive of the libc-hacker@sourceware.cygnus.com mailing list for the glibc project.
Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Roland McGrath <roland@frob.com> writes: > I am not following you at all. The point here is to handle the cases where > multiple versions have been rolled into one, and the issue not what the > name of the set is but whether there is one set or two. Say a new port > begins support at GLIBC_2.1; then it should have all the GLIBC_2.0 symbols > that weren't obsoleted in GLIBC_2.1, but you want all those to go into a > single version set (GLIBC_2.1) to avoid the overhead of the distinct sets. There is no overhead (except for perhaps 16 additional bytes in the .so file). > then, we need to build the compatibility code because the old 2.1 > releases of this port require that in their ABI, but the symbol must > be versioned as GLIBC_2.1 instead of GLIBC_2.0 for this platform, > because that is the version set that the existing binaries are all > bound to. No. The symbol should have the version extension GLIBC_2.0. This is just a name. If you would magically change a symbol which was introduced in glibc 2.0 and therefore has the extension GLIBC_2.0 to have the extension GLIBC_2.1 because there is no support for compatibility with glibc 2.0 then you would have have to rewrite the Versions file. Example: fgetpos() was introduced in 2.0. libio/Versions contains fgetpos() in the section for GLIBC_2.0 for libc. fgetpos() get redefined in glibc 2.2 with an additional entry in for fgetpos in section GLIBC_2.2 for libc. Now comes a platform without support for glibc 2.0. With your scheme the initial fgetpos() would have the version extension GLIBC_2.1. This would mean you would have to move the definition from section GLIBC_2.0 to GLIBC_2.1. And for what? The version name extensions are just names. They describe when the version was introduced or last changed in glibc. I could have chosen completely different names. In the explanation here I carefully used the notation glibc 2.0 and GLIBC_2.0 to make the difference clear. So, just leave it is it is. There is no measurable difference but instead you would introduce many more problems. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |