1. Feature: Feature Name: Include provided collapse_path patch for gcc 2. More Detailed Description Client requests that we include the provided collapse_path patch for gcc. The patch is to rework the relative paths in the compilation to be absolute (/a/b/../c -> /a/c). These relative paths can be a problem in AFS and potentially NFS environments. Architectures (mark all that apply) 32-bit x86 X 64-bit Itanium2 X 64-bit AMD64/Intel EM64T X 64-bit IBM POWER * 31-bit IBM S/390 * 64-bit IBM zSeries * X - Required * - Client doesn't use at present, but this patch should be generic. Dependencies: None External links: None Priority (H,M,L): M Target Releases: RHEL3 U5, RHEL4 GA/U1 Target Release Date: See above Drivers or hardware dependency: None Target Kernel: N/A 3. Business Justification: Including this patch will make the relocation and deployment of the compiler much easier for clients in AFS environments. 4. Code Status: Done by client, not submitted/accepted upstream. Would require us to get upstream acceptance. 5. Hardware to Red Hat? N/A 6. Partner management contact, email, phone, chat: Mike Herron, mherron
Request from PM: Can the tools team please a) state if they know of an alternate solution. b) provide any insight in the work that happened upstream (rumored). c) provide a design estimate for making these patches acceptable to upstream, and integrating them into RHEL3 as well. d) list any reasons why this is a really bad idea. We may want to have a short call with the customer to discuss engineer to engineer.
Created attachment 119420 [details] squeeze absolute paths into canonical form
Jakub, I think performance is a huge deal! Especially since there has been a lot of work to improve compilation performance in gcc: I cannot imagine something that slows down compilation around 10% (or more) to ever get into mailine. People are mad enough over the creeping compile times. Walking up a directory tree and lsating for each .. seems to me to be a performance killer. Ouch!
I don't think gcc driver ever shows on the radar performance-wise. For a simple hello world program, GCC driver calls ~ 80 stat/lstat/access syscalls. If we cached the info, this could add another 20 or so, even if not, stat/lstat are fairly cheap when kernel has the dentry loaded (which it has most of the time). But from #9 it seems even what I was proposing wouldn't help to the customer. Collapsing disregarding symlinks is something completely else though, that is a clear behavioural change, not working around buggy filesystems. And I don't think that's desirable, at least not desirable by default. There could perhaps be a GCC switch that would request the different behaviour.
This issue is on Red Hat Engineering's list of planned work items for the upcoming Red Hat Enterprise Linux 4.4 release. Engineering resources have been assigned and barring unforeseen circumstances, Red Hat intends to include this item in the 4.4 release.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2006-0509.html