Bug 209147 - out of order compilation of source files
out of order compilation of source files
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: ecj (Show other bugs)
4.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ben Konrath
:
Depends On:
Blocks: 209249
  Show dependency treegraph
 
Reported: 2006-10-03 11:55 EDT by giuseppe bonacci
Modified: 2007-11-30 17:07 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-08-30 16:54:50 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)
failed build (compressed log file) (2.42 KB, application/gzip)
2006-10-03 11:55 EDT, giuseppe bonacci
no flags Details

  None (edit)
Description giuseppe bonacci 2006-10-03 11:55:42 EDT
apologies for the length of this report.

I recently tried to "rpmbuild --rebuild" all of RHEL4 (AS) from source.

to speed things up, I activated swap on a large file (~ 6 GB), and then mounted
/usr/src/redhat/BUILD as a 5 GB tmpfs.  since my RAM was rather large (~
512 MB), that ensured that building most small packages only involved
I/O within RAM, and did not even touch the platters, because the build
directory was deleted after successful builds: much faster than
building with /usr/src/redhat/BUILD living in a "real" file system.

most packages built fine.  an exception was ecj, that kept failing with
the attached log.  it took me awhile to understand where the problem is,
and it became clear only after I successfully built in a real file system,
and discovered that the same specfile
- in a tmpfs, tries to compile QualifiedAllocationExpression.java BEFORE
  TypeReference.java, and therefore fails
- in a real file system, compiles TypeReference.java first, and all the
  rest goes smoothly.

the core of the problem is the fact is that the find utility (used in
your spec-file) does not guarantee any order in its output: it follows
the order of entries in the directory it is visiting.

without knowing the details of the tmpfs implementation in Linux, I
guess that while in most real file systems directories are almost linear, and
the order is the same as when files were extracted from the source file
to the directory, in the tmpfs the order is random (maybe the directory
is represented by a tree and traversed in pre- or post-order).

whatever the reason, ecj might fail to build somewhere else, if directory 
layout has not an intrinsic order.  perhaps the spec-file should order source
files a priori.
Comment 1 giuseppe bonacci 2006-10-03 11:55:42 EDT
Created attachment 137661 [details]
failed build (compressed log file)
Comment 3 Andrew Overholt 2006-11-20 17:53:42 EST
I believe Ben has fixed this in rawhide.

Giuseppe:  are you requesting that this be fixed in an RHEL4 update?
Comment 4 giuseppe bonacci 2006-11-21 04:04:09 EST
This bug should be relevant only to those that are rebuilding from SRPMs (i.e.
several non-"paying customers" like me) in the setup outlined above (probably
very few).  Therefore I don't think that making a new ecj srpm just to fix this
would significantly benefit your customer base.  

However, in case you have to publish another srpm to correct some other problem,
it would be nice to have this fix included, in order to ease rebuilding the package.

Anyway, having this PR around for a while might be a time saving reference for
the very few that incur this problem.
Comment 6 Ben Konrath 2007-08-30 16:54:50 EDT
As per comment #4, this bug doesn't seem to be worth fixing because it only
impacts a few people and it's fixed in RHEL5. Closing bug.

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