Red Hat Bugzilla – Full Text Bug Listing
|Summary:||libdhcp4client exports many un-namespaced symbols|
|Product:||[Fedora] Fedora||Reporter:||Mark McLoughlin <markmc>|
|Component:||dhcp||Assignee:||David Cantrell <dcantrell>|
|Status:||CLOSED RAWHIDE||QA Contact:|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2007-02-03 11:16:50 EST||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description Mark McLoughlin 2006-07-11 10:35:00 EDT
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?
Comment 1 Jason Vas Dias 2006-07-25 16:27:38 EDT
Is this still a problem ? mkinitrd seems to be building OK with libdhcp now...
Comment 2 Mark McLoughlin 2006-07-26 02:34:37 EDT
It's a problem in that it will be a problem for some program in the future
Comment 3 Mark McLoughlin 2006-07-26 02:35:50 EDT
(Nash was re-written around the time of the libdhcp port to not have a global "quiet" variable)
Comment 4 Joe Orton 2006-11-16 06:12:49 EST
This should really be fixed, this is one fubar library interface.
Comment 5 Joe Orton 2006-11-16 06:14:18 EST
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.
Comment 6 David Cantrell 2006-11-16 11:23:26 EST
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.
Comment 7 Joe Orton 2006-11-17 05:43:35 EST
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
Comment 8 David Cantrell 2006-11-17 10:35:32 EST
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.
Comment 9 David Cantrell 2007-02-03 11:16:50 EST
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.