Porting mkinitrd from pump to libdhcp4client threw up this problem - libdhcp4lient's "quiet" symbol was clashing with nash's symbol of the same name. Looking through libdhcp4client's symbol table there are a lot of symbols like this that could cause problems for apps wishing to use the lib e.g. local_port, remote_port, cmds ... Since there aren't many symbols that actually should be exported, maybe provide an explicit list of them directly to the linker?
Is this still a problem ? mkinitrd seems to be building OK with libdhcp now...
It's a problem in that it will be a problem for some program in the future
(Nash was re-written around the time of the libdhcp port to not have a global "quiet" variable)
This should really be fixed, this is one fubar library interface.
Created attachment 141358 [details] symbol clashes between FC6 libraries and libdhcp4client The attached file lists global symbol clashes between libdhcp4client and other libraries shipped in FC6.
Ugh, old bug here that I hadn't seen. Just now seeing it since I've taken over the DHCP stuff. I completely agree that this is on fubar library. I have been working to fix it up in devel and will release an update for FC6 after that. Thanks for these notes.
I guess it's unsurprising you hadn't seen it since it all existing dhcp bugs seem to still be assigned to jvdias - maybe a mass re-assign is needed? FWIW of course the v6 library has similar problems, below. Thanks for looking at this! Clashes for /usr/lib/libdhcp6client.so.1: with /usr/lib/libdhcp.so.1 => resolv_dhcpv6_file server6_lease_file (...3 symbols omitted...) lease_file with /usr/lib/libsnmp.so.10.0.1 => strlcpy with /usr/lib/libnetsnmp.so.10.0.1 => strlcpy with /usr/lib/libamu.so.4.0.0 => strlcat strlcpy foreground with /usr/lib/libkdecore.so.4.2.0 => strlcat strlcpy with /usr/lib/libc-client.so.1 => hash_add with /usr/lib/libkdefakes.so.4.2.0 => strlcat strlcpy with /usr/lib/libobjc.so.1.0.0 => hash_add hash_delete with /usr/lib/libdhcp4client.so.1 => libdhcp_control with /usr/lib/libnfsidmap.so.0.2.0 => strlcpy with /usr/lib/libpegcql.so.1 => lineno
Yeah, I'll see what I can do to get a mass-reassign done. I thought that was done, but I guess not. I mean, some bugs got assigned to me when I inherited the packages. I do know about the libdhcp6client library problems as well. Still working on libdhcp4client. Thanks for the report. Also, could you open bugs for these issues in RHEL5? The same problems affect RHEL5 and I really need to get it fixed there. Having a bug open for it is good. Thanks.
Fixed up in rawhide now. This is the first in a series of steps to actually get rid of this library. For now we need it, so as long as that's the case, it shouldn't be exporting over 915 symbols. I've reduced the symbol table to the functions needed by libdhcp.