Description of Problem: rpm --rebuild xxxx.src.rpm fails when rpm is compiled against uClibc (dietlibc). Version-Release number of selected component (if applicable): All Versions I think. How Reproducible: rpmio/macro.c char rpmExpand(const char *arg, ...) uses a buffer of BUFSIZ. BUFSIZ is defined in stdio.h and is in glibc 8192, in uClibc 256 and in dietlibc 128 bytes. /usr/lib/rpm/macros # ---- Scriptlet templates. # Macro(s) that expand to a command and script that is executed. # CAVEAT: All macro expansions must fit in a BUFSIZ (8192 byte) # buffer. # Because of the different buffer sizes only with glibc the macros are expanded properly. Steps to Reproduce: 1. 2. 3. Actual Results: Expected Results: Additional Information:
I won't ask why you're linking rpmbuild against dietlibc, I'm not sure I want to know :-) However, since you're clearly bulding rpm from sources, edit the toplevel debug.h, and add #undef BUFSIZ #define BUFSIZ 8192 as debug.h is included after everything else throughout rpm.
Sure its a bug. When I need a static buffer with exactly 8K then i use an buffer with exactly 8K and not a buffer with a size depending of libc's implementation. The reason why i use uclibc is I'am building an development environment completely uclibc based. Look at this rpm statically linked against glibc: -rwxr-xr-x 1 rpm rpm 1580104 Mai 15 09:04 /bin/rpm rpm statically linked against uClibc: -rwxr-xr-x 1 rpm rpm 1022252 May 30 17:06 /bin/rpm
When I want a manifest constant that scales throughout my code, I use a #define so that I can change the value, particularly when I'm mistrustful of what constants are set by libraries. Redefine BUFSIZ in <debug.h> and be happy.
> Redefine BUFSIZ in <debug.h> and be happy. This is a real bad idea because it will break all internal libc routines which depends on BUF_SIZ. (Bufferoverflow) Example: When I define BUF_SIZ to 8192 in debug.h rpm --rebuild segfaults when a line is longer than 255 chars in 'package.spec'. (Seen in dnsmasq.spec) Regards, Gernot