Re: broken fallback for __progname (get/setprogname())

27 okt 2011 kl. 00:52 skrev <[email protected]>
:

> Hello,
> 
> Heimdal 1.5 is being compiled with gcc 4.2.3 and uclibc git 20110915,
> not including setprogname() and getprogname(). Linking is dynamic.
> 
> In Heimdal 1.5 there is getprogname() in both lib/sl and lib/roken.
> 
> Unfortunately, each library gets its own instance of "char *__progname"
> (in contrast to "extern char *....") which in my eyes is questionable
> even if it may work in some cases.
> 
> I found this as kcc segfaulted, when getprogname() returned NULL after
> a proper call to setprogname().
> 
> Removing getprogname() from libsl makes kcc happy.
> 
> Love, why is there a separate (symlinked to lib/roken/getprogname.c)
> getprogname() in lib/sl at all?
> There are also several other c files symlinked to ../roken,
> what is the reason for duplicating the code between the two libraries?
> 
> Even if the libraries are assumed to never be used together (why?)

ABI.

> getprogname() needs a corresponding setprogname() to be useful,
> which was not the case in sl.

not if libc provides a __progname, removed get dependency.


> 
> Another, smaller issue, I'm curious what happens:
> 
> make check fails on iprop-slave unless there is
> "127.0.0.2 slave.test.h5l.se" in /etc/hosts
> 
> iprop-slave fails in a quite weird way, asking DNS for the KDC
> for a Kerberos realm "named" "9.94.84" or "9.94.85"
> which seems to be somehow related to TEST.H5L.SE vs TEST2.H5L.SE.
> 
> There is probably some assumption in the code which is true
> most of the time but not with the actual setup and uclibc.
> Of course, possibly a bug in the latter.
> 
> The run was in a chroot with barebones
> /etc/hosts:    a single line "127.0.0.1 localhost"
> /etc/resolve:  two properly working nameservers
> /etc/services: no entries for kerberos-related services
> 
> This is with uclibc, dynamic linking and thread support. Heimdal 1.5
> statically linked to the same uclibc version (though both compiled without
> thread support) passed all checks in the same situation.
> 
> ----
> Neither issue is a showstopper for myself but at least the first one
> looks worrysome.

This should no longer be an issue with Nico's patches of non canonization  that was committed last week.

Love