Red Hat Bugzilla – Bug 65733
rpm --rebuild fails
Last modified: 2008-05-01 11:38:02 EDT
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.
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.
# ---- 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)
Because of the different buffer sizes only with glibc the macros
are expanded properly.
Steps to Reproduce:
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
#define BUFSIZ 8192
as debug.h is included after everything else throughout
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
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)