Bug 54959 - XFree86-4.1.0-4 won't build on Seawolf
XFree86-4.1.0-4 won't build on Seawolf
Status: CLOSED RAWHIDE
Product: Red Hat Raw Hide
Classification: Retired
Component: XFree86 (Show other bugs)
1.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-10-23 14:43 EDT by Thomas Dodd
Modified: 2007-04-18 12:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-11-01 22:29:17 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Thomas Dodd 2001-10-23 14:43:43 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:0.9.4) Gecko/20010915

Description of problem:
Something changed in the Imake system.
Using the last gcc for RHL-7.1, building XFree86
dies in the font handler modules.

I tried. changing DisableModuleStringMerge (I'm using gcc-2.96-85)
and WithExternalMesa (Since I cannot compile the new Mesa
with the new XFree86 being installed)

The bug I found is in the xc/lib/font/bitmap/module

It runs 'ar' and creates libbitmap.a
then fails, giving "/bin/sh: libbitmap.a: command not found"


Looking at the Makefile in that directory at the rules
for libbitmap.a is see:

libbitmap.a: $(OBJS) $(EXTRALIBRARYDEPS)
        $(RM) $@
        $(MODAR) $@ $(OBJS)
        $(MODRANLIB) $@
        $(_NULLCMD_)

earlier we see:
       RM = rm -f
    MODAR = ar clq
MODRANLIB =
_NULLCMD_ = @ echo -n

so MODRANLIB is not defined correctly in the Makefile
or it's source. Same for FreeType, Speedo, Type1,and
X-TrueType in their modules/Makefile. And several
directories under X-TrueType have module directories
with the same issue.

RANLIB is defined as "ranlib"

ook in the spec file, where host.def is created.
If you set DisableModuleStringMerging=0 as needed
for gcc < 2.96-93 then ModuleRanlibCmd is unset,
which Imake uses to set MODRANLIB in the Makefiles.
I building now with that set outside the if block,
don't know if it will work correctly, but the
Makfile now has MODRANLIB=ranlib.
I checked host.def for my current 4.0.3-24 install
and it's not in there, so it may not work.

There seems to have been a change in the imake rules files
that causes MODRANLIB to be called when NeedModuleRanLib
is not set.



It finished the compile and install stages.
Then proceded to fail building the binary rpm.
-
RPM build errors:
    File not found: /var/tmp/XFree86-4.1.0-root/usr/lib/libOSMesa.so

    File not found by glob: /var/tmp/XFree86-4.1.0-root/usr/lib/libOSMesa.so.*
-

An it's not there. Looking I find them in
/var/tmp/XFree86-4.1.0-root/usr/X11R6/lib/ instead.
Looking at the Makefile for OSMesa in xc/lib/GL/mesa/src/OSmesa
That's where it says to install them
-
   SHLIBDIR = /usr/X11R6/lib
...
$(INSTALL) $(INSTALLFLAGS) $(INSTBINFLAGS) lib$(LIBNAME).so.$(SOREV) \
   $(DESTDIR)$(SHLIBDIR)
-

Looks like an error in the spec file again, since the %files section
has /usr/lib/libOSMesa.so and /usr/X11R6/lib/libOSMesa.so but in the
%install section, the section to remove Mesa when WithExternalMesa=1
only removes /usr/X11R6/lib/libOSMesa.* .

Or is it the Makefile for OSMesa not creating the link in /usr/lib
correctly (like libGL is done)? I don't have libOSMesa.so in either
place from XFree86-4.0.3-24 or Mesa-3.4.2-1.




I commented out the %files entries for /usr/lib/libOSMesa*

Now rpm -bl complains about files listed twice:
/usr/X11R6/lib/libGL.so

/usr/X11R6/lib/libGLU.so
/usr/X11R6/lib/libOSMesa.so


Which is true, they get caught in the lib*.so
and libGL*.so (or libOSMesa.so) entries.
Commenting those out of -devel allows the list
check to pass.






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


How reproducible:
Always

Steps to Reproduce:
1. See description	

Additional info:
Comment 1 Thomas Dodd 2001-10-23 14:47:18 EDT
I don't see this with gcc-2.96-99 and bin-utils-2.11.92.0.7-1

Comment 2 Thomas Dodd 2001-10-23 14:54:21 EDT
Correction. I forgot I built Mesa before the previous comment.
I changed the ExternalMesa flag to do a %prep
and get the needed tarball for Mesa, then built Mesa,
installed it, and built X from the original spec file.

So ignore my previous comment, the bug is still there.

Comment 3 Mike A. Harris 2001-10-26 20:10:17 EDT
Currently, the XFree86-4.1.0-4 package was just a limited distribution
test release for testing a single bug fix - which was unsuccessful.  It
is recommended to not use this release, however, if it works for you,
then you might as well use it anyway.  ;o)

The 4.1.0 package was designed for Red Hat Linux 7.2, and has some
building dependancies on the new release, some are changes made to the
specfile to solve X build problems with new compiler optimizations,
get past a bug in 7.1's rpm, and other issues.  When adding these
changes, I have tried to do so in a way to conditionalize the specfile
so that it can be easily reconfigured to build in a 7.1+errata
environment.  We currently do not support 4.1.0 in 7.1, however, since
there will be a 4.1.0 erratum for 7.1, I do have an interest in trying
to make the specfile build cleanly in 7.1 once a few defines are
enabled/disabled in the specfile.

Thanks for putting this in bugzilla.
Comment 4 Mike A. Harris 2001-11-01 22:29:10 EST
I think I just found and fixed this problem.  allow-module-flags patch
was surrounded by an %ifnarch s390, however it *should* have been
surrounded by a %if %{DisableModuleStringMerging}

As such, all x86 builds got this patch applied regardless of what the
state of the DisableModuleStringMerging define was.

Will appear in XFree86-4.1.0-6 on people.redhat.com probably sometime
this week.
Comment 5 Mike A. Harris 2001-12-04 19:49:13 EST
This problem is taken care of in XFree86 CVS automatically,
and the current src.rpm of 4.1.0 should also work.  In addition, I
may backport the fix from CVS to 4.1.0 to autodetect this.

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