It has changed in the past, and these days, anyone can get a copy of the
LGPL via the web rather than by post.
Like 657a122 (Remove FSF mailing address) in libabc by Josh Tripplet,
but let the FSF website in which the license can be found.
In a specific configuration (chroot with the linux32 personality), the
modprobe_install_cmd_loop test failed, because the bash process handling
the install command segfaulted. The backtrace showed a uname() call
during libpthread initialization, at which point the environ pointer
hadn't been initialized yet:
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x080c1591 in getenv (name=<optimized out>,
name@entry=0xf775f850 "TESTSUITE_UNAME_R") at getenv.c:81
81 for (i = 0, len = strlen (name); environ[i]; i++)
(gdb) bt
#0 0x080c1591 in getenv (name=<optimized out>,
name@entry=0xf775f850 "TESTSUITE_UNAME_R") at getenv.c:81
#1 0xf775f754 in uname (u=u@entry=0xff946350) at testsuite/uname.c:32
#2 0xf74ffc6c in is_smp_system ()
at ../nptl/sysdeps/unix/sysv/linux/i386/smp.h:39
#3 __pthread_initialize_minimal_internal () at nptl-init.c:460
#4 0xf74fe32c in _init () at ../sysdeps/i386/crti.S:74
#5 0x00000000 in ?? ()
(gdb) p environ
$1 = (char **) 0x0
I don't know why it only happend in the chroot, but glibc can call its
own functions and impose any restrictions before main() is started, so
we have to adapt.
Also, do not return error if there is an environment, but the
environment variable is not found. If uname() is called by kmod, then
the respective test will simply fail later. If it's something else
calling uname(), then we do not want to disturb the program.
Lucas De Marchi
Michal Marek
Lucas De Marchi