Bug 63890 - Undeclared symbols encountered during compile
Undeclared symbols encountered during compile
Product: Red Hat Raw Hide
Classification: Retired
Component: XFree86 (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2002-04-20 11:51 EDT by David Juran
Modified: 2007-04-18 12:42 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-04-23 15:05:23 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description David Juran 2002-04-20 11:51:07 EDT
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:

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 
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 15:13:23 EDT
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++

/me who regrets moving ttmkfdir to the XFree86 packaging
Comment 2 David Juran 2002-04-20 19:46:00 EDT
If the build works for you, in which file and package are the symbols declared?
Comment 3 Mike A. Harris 2002-04-20 20:23:01 EDT
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


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....

Comment 4 David Juran 2002-04-23 15:05:18 EDT
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-20 22:12:02 EDT
Closing bug as NOTABUG

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