Re: [bug-inetutils] inetutils-1.8: ftp build error
I am forwarding an error reported on the inetutils mailing list. The problem is that readline 6.x exports `xmalloc' and `xrealloc', and it causes a linker error when used together with gnulib. Probably readline shouldn't export these symbols, but I think it should be possible somehow to workaround this problem in gnulib as well. What do you think? This is a known bug, the reason if I recall is that readline exports xmalloc and xrealloc is to allow programs to hook their own version into readline. So the readline maintainer has declined any fixes for this.
Re: [bug-inetutils] inetutils-1.8: ftp build error
Alfred M. Szmidt a...@gnu.org ha escrit: This is a known bug, the reason if I recall is that readline exports xmalloc and xrealloc is to allow programs to hook their own version into readline. So the readline maintainer has declined any fixes for this. This is a severe bug. It makes readline useless for any project that uses gnulib. Regards, Sergey
Re: [bug-inetutils] inetutils-1.8: ftp build error
This is a known bug, the reason if I recall is that readline exports xmalloc and xrealloc is to allow programs to hook their own version into readline. So the readline maintainer has declined any fixes for this. This is a severe bug. It makes readline useless for any project that uses gnulib. I should note that this was from my recollection, but I agree, it is painful. Here is what Chet had to say on the topic: Re: [Bug-readline] [PATCH] hide symbols for helper xmalloc/xrealloc/xfree functions | libreadline is exporting symbols for its internal helper | xmalloc/xrealloc/xfree functions. These function names are | quite common, but might not behave exactly the same way as | readline expects. | | I want applications to have the option to override these functions if | they so choose.
Re: [bug-inetutils] inetutils-1.8: ftp build error
On 7/25/10 10:33 AM, Alfred M. Szmidt wrote: This is a known bug, the reason if I recall is that readline exports xmalloc and xrealloc is to allow programs to hook their own version into readline. So the readline maintainer has declined any fixes for this. This is a severe bug. It makes readline useless for any project that uses gnulib. Maybe. There are workarounds, as I detailed in a message to bug-readline in June. Another problem is that gnulib has significantly expanded the scope of the xmalloc/xrealloc/xfree interface. The source file that defines those also defines half a dozen other functions: x2realloc, xzalloc, etc. It also calls those functions internally, requiring the source file to be linked in whether or not the application calls any of them directly. I don't consider this good interface design. Readline defines only xmalloc/xrealloc/xfree. That's an acceptably small footprint, though I could also see adding xcalloc. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: [bug-inetutils] inetutils-1.8: ftp build error
xmalloc etc. are commonly used names in GNU applications, regardless of whether the apps are gnulib-based; for example, Emacs and GCC both have their own xmalloc, independent of gnulib. It would be nicer if readline were compatible with this common usage, without application developers having to do something unusual in order to have their own xmalloc. At the very least, if it's really intended for GNU readline to usurp common names like xmalloc, its documentation should explain how to work around the problem without having to rename the app's own xmalloc.
Re: [bug-inetutils] inetutils-1.8: ftp build error
On 7/25/10 2:38 PM, Paul Eggert wrote: xmalloc etc. are commonly used names in GNU applications, regardless of whether the apps are gnulib-based; for example, Emacs and GCC both have their own xmalloc, independent of gnulib. It would be nicer if readline were compatible with this common usage, without application developers having to do something unusual in order to have their own xmalloc. At the very least, if it's really intended for GNU readline to usurp common names like xmalloc, its documentation should explain how to work around the problem without having to rename the app's own xmalloc. That's not the problem. Bash has its own xmalloc, too. The recommended way to do this is to have the application supply its own xmalloc. Readline is GNU software, and uses xmalloc/xrealloc in the same way as other GNU software. It supplies fallback implementations for those applications that don't provide the functions. Applications that do can easily override the readline definitions. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: [bug-inetutils] inetutils-1.8: ftp build error
On 7/25/10 2:36 PM, Mike Frysinger wrote: why do you need to use those function names ? using a name spaced function like rl_malloc or _rl_malloc would keep the same functionality without clashing with other people. No, it wouldn't. It would not allow, for instance, an application to control all the memory allocation and management readline performs. xmalloc is a pretty common name for people to use in their own projects and i dont think people even realize that readline is doing this. i know i wasnt aware of it and have used readline along with xmalloc in my application before. Exactly. You can override readline's use of xmalloc easily -- almost without effort. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: [bug-inetutils] inetutils-1.8: ftp build error
On 7/25/10 2:00 PM, Chet Ramey wrote: On 7/25/10 10:33 AM, Alfred M. Szmidt wrote: This is a known bug, the reason if I recall is that readline exports xmalloc and xrealloc is to allow programs to hook their own version into readline. So the readline maintainer has declined any fixes for this. This is a severe bug. It makes readline useless for any project that uses gnulib. Maybe. There are workarounds, as I detailed in a message to bug-readline in June. I looked and figured out the root cause -- gnulib doesn't implement xfree. I will put a workaround in the next version of readline. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: [bug-inetutils] inetutils-1.8: ftp build error
On Sunday, July 25, 2010 17:18:02 Chet Ramey wrote: On 7/25/10 2:36 PM, Mike Frysinger wrote: why do you need to use those function names ? using a name spaced function like rl_malloc or _rl_malloc would keep the same functionality without clashing with other people. No, it wouldn't. It would not allow, for instance, an application to control all the memory allocation and management readline performs. why not ? the symbols would still be exported and overridable by end users. it would simply be using a namespace already reserved for readline. xmalloc is a pretty common name for people to use in their own projects and i dont think people even realize that readline is doing this. i know i wasnt aware of it and have used readline along with xmalloc in my application before. Exactly. You can override readline's use of xmalloc easily -- almost without effort. except i dont want that behavior -mike signature.asc Description: This is a digitally signed message part.
