I was building dhcpd 4.2.0 on IRIX 6.5 using the native system compilers, and right before linking, I got a huge number of warnings from the linker talking about multiply defined symbols, specifically:<div><br>"unknown_class"</div>
<div>"known_class"</div><div>"default_collection"</div><div>"collections"</div><div><br></div><div>The linker still spat out a binary, but lo and behold, the moment I started the program, it segfaulted.</div>
<div><br></div><div>Checking dhcpd.h, I found (ln 2900-2904) that these symbols are declared /without/ the "extern" directive, meaning that each file that includes this creates a globally-visible copy of this symbol. This is a terrible idea and almost assuredly illegal. Since the comment above says "class.c", I checked class.c and found "default_collection" and "collections" being declared and initialized. I couldn't find "unknown_class" or "known_class" -- it looks like they aren't used in dhcpd (tried "cat *.c | grep known_class" gave nothing in server/ dir)</div>
<div><br></div><div>Apparently the linker accepted the first definition of the symbol and rejected the rest, so that meant that if class.o was not the first file that linker checked, the dhcp server would segfault since the fields are not initialized as they are in class.c.</div>
<div><br></div><div><br></div><div><br></div><div>The problem is that when I added these extern definitions, dhclient fails to link due to an undefined reference to "collections" (remember that server/class.c had the actual symbol?). Even though I'm not trying to use dhclient, this is another problem. It seems like the "right" thing to do is to move the declaration of shared, initialized global data to a separate file.</div>
<div><br></div><div>I'm also seeing other multiply defined symbols: "remote_port", "local_port", "dhcp_type_interface" (appearing in "dhclient.o" and "discover.o")</div>
<div><br></div><div>Any thoughts on how to resolve these errors cleanly?</div><div><br></div><div><br></div><div>Patrick Baggett</div><div><br></div>