From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24660 invoked by alias); 16 Nov 2002 03:26:01 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 24638 invoked by uid 71); 16 Nov 2002 03:26:00 -0000 Resent-Date: 16 Nov 2002 03:26:00 -0000 Resent-Message-ID: <20021116032600.24637.qmail@sources.redhat.com> Resent-From: gcc-gnats@gcc.gnu.org (GNATS Filer) Resent-Cc: gcc-prs@gcc.gnu.org, gcc-bugs@gcc.gnu.org Resent-Reply-To: gcc-gnats@gcc.gnu.org, Steven Overhauser Received: (qmail 24148 invoked from network); 16 Nov 2002 03:19:23 -0000 Received: from unknown (HELO purple.int.infinisim.com) (64.166.142.50) by sources.redhat.com with SMTP; 16 Nov 2002 03:19:23 -0000 Received: (from spo@localhost) by purple.int.infinisim.com (8.11.6/8.11.6) id gAG3JME32355; Fri, 15 Nov 2002 19:19:22 -0800 Message-Id: <200211160319.gAG3JME32355@purple.int.infinisim.com> Date: Fri, 22 Nov 2002 02:26:00 -0000 From: Steven Overhauser To: gcc-gnats@gcc.gnu.org X-Send-Pr-Version: 3.113 Subject: c/8597: Enhancement request X-SW-Source: 2002-11/txt/msg00815.txt.bz2 List-Id: >Number: 8597 >Category: c >Synopsis: gcov related files getting overwritten >Confidential: no >Severity: non-critical >Priority: low >Responsible: unassigned >State: open >Class: change-request >Submitter-Id: net >Arrival-Date: Fri Nov 15 19:26:00 PST 2002 >Closed-Date: >Last-Modified: >Originator: Steven Overhauser >Release: 3.2 >Organization: ngls.net >Environment: System: Linux purple 2.4.18 #2 Thu Mar 7 11:18:15 PST 2002 i686 unknown Architecture: i686 host: i686-pc-linux-gnu build: i686-pc-linux-gnu target: i686-pc-linux-gnu configured with: ../configure --prefix=/usr/local/dev/Linux_i686/gcc3.2 --enable-shared --enable-threads=posix --enable-version-specific-runtime-libs >Description: The gcov related files (*.bb, *.bbg, and *.da) end up in the current directory where the compilation actually took place. This is a problem if you build multiple architectures from the same spot. (As the make system I use does.) This also makes one very crowded directory when compiling an entire hierarchy of files from the root of the hierarchy. Also, there would be a problem with multiple source files with the same name in different directories. >How-To-Repeat: On a linux box: gcc -fprofile-arcs -ftest-coverage -g path/file.cpp -o srcPath/linux/file.o And on a solaris box in the same directory: gcc -fprofile-arcs -ftest-coverage -g path/file.cpp -o srcPath/solaris/file.o The solaris .bb and .bbg would have just overwritten the linux based files. >Fix: I believe it would make more sense to put these gcov files into the same directory as the object file that gets created. This would fix both the multiple architecture problem and the similarly named file problem mentioned above. I have tried to hack the source code myself, but haven't managed to get it to work yet. I've only been able to get the files to go into the "srcPath" directory (as in the above example) and not the object file's directory. By the way, my hack also included ignoring creating .bb and .bbg files for files whose paths started with "/usr" so that I did not get those files for all of the system header files. It seems to me that this should some sort of option. >Release-Note: >Audit-Trail: >Unformatted: