diff options
Diffstat (limited to 'FAQ')
| -rw-r--r-- | FAQ | 28 |
1 files changed, 28 insertions, 0 deletions
@@ -104,6 +104,11 @@ please let me know. [Q29] ``I don't include any kernel header myself but still the compiler complains about type redeclarations of types in the kernel headers.'' + +[Q30] ``When I start the program XXX after upgrading the library + I get + XXX: Symbol `_sys_errlist' has different size in shared object, consider re-linking + Why? What to do?'' ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ [Q1] ``What systems does the GNU C Library run on?'' @@ -777,6 +782,29 @@ ones. See the BUGS file for other known problems. ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ +[Q30] ``When I start the program XXX after upgrading the library + I get + XXX: Symbol `_sys_errlist' has different size in shared object, consider re-linking + Why? What to do?'' + +[A30] {UD} As the message says, relink the binary. The problem is that +very few symbols from the library can change in size and there is no way +to avoid this. _sys_errlist is a good example. Occasionally there are +new error numbers added to the kernel and this must be reflected at user +level. + +But this does not mean all programs are doomed once such a change is +necessary. Such symbols should normally not be used at all. There are +mechanisms to avoid using them. In the case of _sys_errlist, there is the +strerror() function which should _always_ be used instead. So the correct +fix is to rewrite that part of the application. + +In some situations (especially when testing a new library release) it might +be possible that such a symbol size change slipped in though it must not +happen. So in case of doubt report such a warning message as a problem. + + +~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Answers were given by: {UD} Ulrich Drepper, <drepper@cygnus.com> |