broken fallback for __progname (get/setprogname())

[email protected]
Newsgroups gmane.comp.encryption.kerberos.heimdal.general
Message-ID <[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?)
getprogname() needs a corresponding setprogname() to be useful,
which was not the case in sl.

----
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.

Regards,
Rune
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.