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