Bug 54959
| Summary: | XFree86-4.1.0-4 won't build on Seawolf | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Raw Hide | Reporter: | Thomas Dodd <ted> |
| Component: | XFree86 | Assignee: | Mike A. Harris <mharris> |
| Status: | CLOSED RAWHIDE | QA Contact: | David Lawrence <dkl> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 1.0 | ||
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2001-11-02 03:29:17 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
I don't see this with gcc-2.96-99 and bin-utils-2.11.92.0.7-1 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. 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. 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.
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. |
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: