current testing state of glibc 2.3.4 and 2.4 headers

Jerry Lundström prox at lunar-linux.org
Mon Jan 31 09:26:23 UTC 2005


Jaime Buffery wrote:
> Hello, Terry
> On Sat, Jan 29, 2005 at 09:43:56AM -0600, Terry Chan wrote:
> 
>>Upon examination of the glibc-2.3.4 lunar module and the 2.3.4 source code,
>>I'm not sure that commenting out the glibc-2.3.2-ctype-compat.patch is such a 
>>great idea.  The patch probably needs some help in being applied, but the glibc-2.3.4
>>code does NOT appear to provide the patch's functionality.  You will find out very
>>shortly when you try to get your lunar box to compile a static binary, like tar-static,
>>bash_static, or sash.  If glibc-2.3.4 does allow you to correctly compile a static
>>binary and run older statically linked binaries, THEN the ctype-compat.patch is really
>>no longer necessary.
> 
> 
> Well, the case is that with the unpatched glibc, bash_static and tar_static both 
> give some warnings. In tar-static's case, this is what I get:
> 
> gcc  -Os -mcpu=i386 -march=i386 -static  -s -static -o tar  buffer.o compare.o 
> create.o delete.o extract.o xheader.o incremen.o list.o mangle.o misc.o names.o 
> sparse.o system.o tar.o update.o utf8.o ../lib/libta
> names.o(.text+0x94): En la función `gid_to_gname':
> : warning: Using 'getgrgid' in statically linked applications requires at 
> runtime the shared libraries from the glibc version used for linking
> names.o(.text+0x199): En la función `gname_to_gid':
> : warning: Using 'getgrnam' in statically linked applications requires at 
> runtime the shared libraries from the glibc version used for linking
> names.o(.text+0x112): En la función `uname_to_uid':
> : warning: Using 'getpwnam' in statically linked applications requires at 
> runtime the shared libraries from the glibc version used for linking
> names.o(.text+0x2a): En la función `uid_to_uname':
> : warning: Using 'getpwuid' in statically linked applications requires at 
> runtime the shared libraries from the glibc version used for linking

This is not really a problem, there are some functions that just isnt 
linked into statically packages and requires libc, i think some of the 
nslookup rutins needs libc also. I dont know if we ever going to run 
programs without having a libc present.

my 2c


More information about the Lunar-dev mailing list