Ethereal-dev: [ethereal-dev] Re: Multiple definition during compile

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Guy Harris <gharris@xxxxxxxxxxxx>
Date: Wed, 5 Jan 2000 21:29:58 -0800
> On Wed, Jan 05, 2000 at 08:26:14PM -0200, Roberto Machado wrote:
> 
> Hi!
> 
>  I wanted to try ethereal 0.8.0 today and faced problems to compile it
>  (only got there hacking the Makefile to remove support for the
>  gryphon plugin).
> 
>  System is BSDI 3.1. I'm using shlicc2, but gcc shows the same.
> 
> Regards,
> Roberto
> 
> [...]
> 
> extracting global C symbols from `plugins/gryphon/.libs/libgryphon.a'
> (cd .libs && shlicc2 -c -fno-builtin "etherealS.c")
> rm -f .libs/etherealS.c .libs/ethereal.nm .libs/ethereal.nmS .libs/ethereal.nmT
> shlicc2 -Wall -g -O2 -I. -I./wiretap -I/usr/local/include
> -I/usr/X11R6/include -I/usr/local/lib/glib/include
> -I/usr/local/include -o ethereal asn1.o capture.o colors.o column.o
> conversation.o dfilter-grammar.o dfilter-scanner.o dfilter.o
> ethertype.o file.o follow.o ipproto.o ipv4.o packet.o plugins.o
> prefs.o print.o proto.o ps.o register.o resolv.o summary.o util.o
> xdlc.o packet-aarp.o packet-afs.o packet-arp.o packet-ascend.o
> packet-atalk.o packet-atm.o packet-auto_rp.o packet-bgp.o
> packet-bootp.o packet-bootparams.o packet-bpdu.o packet-cdp.o
> packet-clip.o packet-data.o packet-dns.o packet-eth.o packet-fddi.o
> packet-ftp.o packet-giop.o packet-gre.o packet-hsrp.o packet-http.o
> packet-icmpv6.o packet-icp.o packet-icq.o packet-imap.o packet-ip.o
> packet-ipp.o packet-ipsec.o packet-ipv6.o packet-ipx.o packet-irc.o
> packet-isakmp.o packet-isis.o packet-isis-clv.o packet-isis-hello.o
> packet-isis-lsp.o packet-isis-snp.o packet-lapb.o packet-lapd.o
> packet-ldap.o packet-llc.o packet-lpd.o packet-mapi.o packet-mount.o
> packet-nbipx.o packet-nbns.o packet-ncp.o packet-netbios.o
> packet-nfs.o packet-nlm.o packet-nntp.o packet-ntp.o packet-null.o
> packet-osi.o packet-ospf.o packet-pim.o packet-pop.o packet-portmap.o
> packet-ppp.o packet-pppoe.o packet-pptp.o packet-q2931.o packet-q931.o
> packet-radius.o packet-raw.o packet-rip.o packet-ripng.o packet-rpc.o
> packet-rsvp.o packet-rtsp.o packet-rx.o packet-sap.o packet-sdp.o
> packet-smb.o packet-sna.o packet-snmp.o packet-srvloc.o packet-sscop.o
> packet-stat.o packet-tacacs.o packet-tcp.o packet-telnet.o
> packet-tftp.o packet-tns.o packet-tr.o packet-trmac.o packet-udp.o
> packet-v120.o packet-vines.o packet-vlan.o packet-vrrp.o packet-wccp.o
> packet-who.o packet-x25.o packet-yhoo.o packet-ypbind.o
> packet-ypserv.o packet-ypxfr.o inet_pton.o wiretap/libwiretap.a
> gtk/libui.a -lsnmp libltdl/.libs/libltdlc.a -ldl .libs/etherealS.o
> plugins/gryphon/.libs/libgryphon.a -lz -lpcap -L/usr/local/lib
> -L/usr/local/lib -L/usr/X11R6/lib -lgtk -lgdk -lgmodule -lglib -ldl
> -lXext -lX11 -lm
> proto.c:135: Definition of symbol _proto_init (multiply defined)
> packet-gryphon.c:1519: Definition of symbol _proto_init (multiply
> defined)
> rm -f .libs/etherealS.o

Uh-oh.  It appears as if libtool may have concluded that BSD/OS 3.1
doesn't support run-time linking (I remember Donn Seeley saying, a while
ago, that they were going to do their own shared library mechanism,
rather than going with a SunOS 4.x/SVR4-style mechanism as the
free-software BSDs and Linux did, and it may either be that it didn't
exist in 3.1 or didn't support run-time linking in 3.1), and therefore,
in order to support picking up the plugin, it tried statically linking
it into the image.

Does anybody know if there's a way to have a config file check whether,
on the platform on which you're running it, you'll get real run-time
linking from libtool?  If so, then

	1) we may want to use that, rather than the presence of
	   <dlfcn.h>, to decide whether to enable plugins (doing so
	   might make plugins work on HP-UX, which I suspect may not
	   have <dlfcn.h> as they have their own non-"dlopen()" API for
	   run-time linking, and the same may apply to Win32);

	2) we should also use that to decide what to do about the
	   Gryphon plugin, and perhaps we should leave it out if we
	   don't get real run-time linking on that platform.