Bug 63890 - Undeclared symbols encountered during compile
Summary: Undeclared symbols encountered during compile
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Raw Hide
Classification: Retired
Component: XFree86
Version: 1.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: David Lawrence
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-04-20 15:51 UTC by David Juran
Modified: 2007-04-18 16:42 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2002-04-23 19:05:23 UTC
Embargoed:


Attachments (Terms of Use)

Description David Juran 2002-04-20 15:51:07 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020313

Description of problem:
The source rpm XFree86-4.2.0-6.62 won't rebuild due to undeclared symbols.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. rpm --rebuild --target i686 XFree86-4.2.0-6.62

	

Actual Results:  g++ -Wall -pedantic -I/usr/include/freetype2/. -O2 -march=i686
-c ttf.cpp  -fPIC -DPIC -o .libs/ttf.lo
ttf.cpp: In method `ttf::Face::Face (const string &)':
ttf.cpp:88: `FT_Err_Post_Table_Missing' undeclared (first use this 
function)
ttf.cpp:88: (Each undeclared identifier is reported only once for each 
function it appears in.)
ttf.cpp:92: `FT_Err_Table_Missing' undeclared (first use this function)
ttf.cpp: In method `const char *ttf::Face::Weight () const':
ttf.cpp:519: warning: `const char *result' might be used uninitialized 
in this function
ttf.cpp: In method `const char *ttf::Face::Width () const':
ttf.cpp:600: warning: `const char *result' might be used uninitialized 
in this function
make: *** [ttf.o] Error 1
make: Leaving directory `/home/david/rpm/BUILD/XFree86-4.2.0/ttmkfdir2'


Additional info:

Comment 1 Mike A. Harris 2002-04-20 19:13:23 UTC
This probably is due to standards compliance patches for gcc 3 perhaps.

If you're rebuilding it in a pure Red Hat Linux 7.2 environment, it may
not rebuild cleanly at all.  I am able to rebuild the package for i686,
so there is definitely something different in our two environments.

yshao - can you comment on this, since it is failing in ttmkfdir C++
code?

/me who regrets moving ttmkfdir to the XFree86 packaging

Comment 2 David Juran 2002-04-20 23:46:00 UTC
If the build works for you, in which file and package are the symbols declared?

Comment 3 Mike A. Harris 2002-04-21 00:23:01 UTC
I have no idea personally.  The package builds in the rawhide build
environment.  If you have skipjack beta installed, and have got all
rawhide updates applied since skipjack, the package builds.  If it fails
to build in any other environment, it is not officially considered
a bug, however generally any minor build issues will also be fixed
in future builds if someone can point out what the problems are and/or
attach patches which both fix them, and don't cause it to break in
the supported environment.

I am guessing that what you are seeing is either:

1) A missing BuildRequires somewhere

or

2) One of the patches being applied for gcc 3 or somesuch is causing the
   build to fail in whatever your build environment is

One of my build machines is running RHL 7.0, and another 7.1.  Another
system runs 7.2.  All three systems are stock Red Hat Linux plus
updates as a base.  The 7.0 system includes various updated software
from 7.1/7.2/rawhide as needed.  All three systems rebuild the src.rpm
without problems.

I don't know if this is a bug, or if it is merely a problem with your
particular build environment.  Try commenting out the gcc3 patch
for ttmkfdir is my suggestion.  If that doesn't work, then perhaps
yshao has something else to suggest.

Other than that, I'd suggest upgrading to Skipjack + rawhide updates.
C'mon, you know you want to..   everyone is doing it... peer pressure....
;o)





Comment 4 David Juran 2002-04-23 19:05:18 UTC
Well yes, obvioulsy there's a BuildRequires missing somewhere. I'd rather
upgrade as little as possible, but in the SPEC-file I found this section:

# This MUST be set to 0 for 7.x builds.  If it is set to 1, change it to 0,
# as I sometimes need to set it to 1 while doing developmental testing.
%define with_ttmkfdir       1

So I changed it to 0, and then I at least got the packages. Could it be so that
this ttmkfdir never did work?
I'm still curious to see where those symbols are included from, but I rather
upgrade as little as possible and I guess you have better things to do as well
then tracing a preprocessor anyway (-:

Comment 5 Mike A. Harris 2002-05-21 02:12:02 UTC
Closing bug as NOTABUG


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