Bug 157308 - can't compile (link) ethereal 0.10.11 with gcc-3.4: undefined reference to `.LC770'
can't compile (link) ethereal 0.10.11 with gcc-3.4: undefined reference to `....
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: gcc (Show other bugs)
3
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Jakub Jelinek
http://bugs.ethereal.com/bugzilla/sho...
:
Depends On:
Blocks: 164808
  Show dependency treegraph
 
Reported: 2005-05-10 10:30 EDT by Jeff Morriss
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version: 3.4.4-2
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-09-05 04:46:42 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
packet-diameter.c run through the preprocessor (added "-E" to gcc command line) (349.46 KB, text/plain)
2005-05-11 05:55 EDT, Jeff Morriss
no flags Details

  None (edit)
Description Jeff Morriss 2005-05-10 10:30:23 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910

Description of problem:
I (and several others) are not able to compile (actually link) the current version of Ethereal (0.10.11) using an up-to-date FC3 system.  This was filed as Ethereal bug #156:

http://bugs.ethereal.com/bugzilla/show_bug.cgi?id=156

Some analysis by people there has us believing that this is a compiler bug (see below or the Ethereal bug for more details).

I am putting this as a "High" severity bug since it was originally considered a "blocker" bug for Ethereal (until it was thought to be a compiler bug with a workaround).  That and compiler bugs scare me.  Feel free to downgrade if you feel it appropriate.

Version-Release number of selected component (if applicable):
gcc-3.4.3-22.fc3

How reproducible:
Always

Steps to Reproduce:
1. download the ethereal-0.10.11 source or the FC3 SRPM
2. ./configure --without-ucd-snmp (or ./configure --with-ssl)
3. make
(2 & 3 can be replaced with "rpmbuild -ba")


Actual Results:  Linking failed with this error:

/bin/sh ./libtool --mode=link --tag=CC gcc  -DINET6 -D_U_="__attribute__((unused))" -Wall -W  -g -O2 -I/usr/local/include -DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API -pthread -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/atk-1.0 -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/freetype2/config -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include     -L/usr/local/lib -L/usr/local/lib -o mergecap  mergecap.o merge.o wiretap/libwiretap.la -Wl,--export-dynamic -lgmodule-2.0 -ldl -lglib-2.0   -lz 
epan/.libs/libethereal.so: undefined reference to `.LC771'
epan/.libs/libethereal.so: undefined reference to `.LC770'
epan/.libs/libethereal.so: undefined reference to `.LC772'
collect2: ld returned 1 exit status
make[2]: *** [ethereal] Error 1


Expected Results:  Binary should have been created.

Additional info:

NOTE that if I use "gcc32" (gcc32-3.2.3-6) (by doing "CC=gcc32 ./configure --without-ucd-snmp") instead of "gcc" Ethereal compiles/links just fine (thus supporting the hypothesis that this is a 'gcc' problem not an Ethereal problem).

NOTE that someone found another "workaround" for this problem: eliminating having the same string constant in 2 .o files, see:

http://www.ethereal.com/lists/ethereal-dev/200505/msg00069.html

NOTE that I experienced the same problem attempting to build the ethereal-0.10.11 SRPM released by FC3 (I had been hoping someone had patched something before generating that SRPM but now I think that maybe the machine used to build the binary RPM isn't at the latest (released) compiler version?).
Comment 1 Jakub Jelinek 2005-05-10 11:13:42 EDT
Please find out from which *.o file the undefined .LC770 etc. references are
(nm -u) and then attach here preprocessed source for that file and
GCC command line used to compile it.
Comment 2 Jeff Morriss 2005-05-11 05:55:16 EDT
Created attachment 114239 [details]
packet-diameter.c run through the preprocessor (added "-E" to gcc command line)

(In reply to comment #1)
> Please find out from which *.o file the undefined .LC770 etc. references are
> (nm -u) and then attach here preprocessed source for that file and
> GCC command line used to compile it.

The references appear to come from "packet-diameter.o":

mozart [~/Projects/ethereal/source/epan/dissectors/]> nm -u
.libs/packet-diameter.o|egrep LC77[0-2]
	 U .LC770
	 U .LC771
	 U .LC772

which was compiled (via libtool) thus:

if /bin/sh ../../libtool --mode=compile --tag=CC gcc -DHAVE_CONFIG_H -I. -I.
-I../.. -I./../.. -I./..  -I/usr/local/include	 -DINET6
-D_U_="__attribute__((unused))" -Wall -W  -g -O2 -I/usr/local/include
-DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API -pthread -I/usr/include/gtk-2.0
-I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/atk-1.0
-I/usr/include/pango-1.0 -I/usr/include/freetype2
-I/usr/include/freetype2/config -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include    -MT packet-diameter.lo -MD -MP -MF
".deps/packet-diameter.Tpo" -c -o packet-diameter.lo packet-diameter.c; \
then mv -f ".deps/packet-diameter.Tpo" ".deps/packet-diameter.Plo"; else rm -f
".deps/packet-diameter.Tpo"; exit 1; fi
 gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I./../.. -I./.. -I/usr/local/include
-DINET6 "-D_U_=__attribute__((unused))" -Wall -W -g -O2 -I/usr/local/include
-DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API -pthread -I/usr/include/gtk-2.0
-I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/atk-1.0
-I/usr/include/pango-1.0 -I/usr/include/freetype2
-I/usr/include/freetype2/config -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include -MT packet-diameter.lo -MD -MP -MF
.deps/packet-diameter.Tpo -c packet-diameter.c	-fPIC -DPIC -o
.libs/packet-diameter.o
packet-diameter.c: In function `dissect_avps':
packet-diameter.c:1853: warning: comparison between signed and unsigned
packet-diameter.c: In function `proto_register_diameter':
packet-diameter.c:2165: warning: dereferencing type-punned pointer will break
strict-aliasing rules
Comment 4 Jakub Jelinek 2005-05-16 10:09:24 EDT
Or http://gcc.gnu.org/ml/gcc-patches/2005-05/msg01541.html
Comment 5 Jakub Jelinek 2005-05-17 03:44:47 EDT
In rawhide, this is fixed in gcc-4.0.0-6.
Comment 6 Jakub Jelinek 2005-07-25 10:03:11 EDT
Should be fixed in gcc-3.4.4-2{,.fc3}.

Note You need to log in before you can comment on or make changes to this bug.