From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7451 invoked by alias); 10 Apr 2002 02:36:02 -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 7430 invoked by uid 71); 10 Apr 2002 02:36:01 -0000 Resent-Date: 10 Apr 2002 02:36:01 -0000 Resent-Message-ID: <20020410023601.7429.qmail@sources.redhat.com> Resent-From: gcc-gnats@gcc.gnu.org (GNATS Filer) Resent-To: nobody@gcc.gnu.org Resent-Cc: gcc-prs@gcc.gnu.org, gcc-bugs@gcc.gnu.org Resent-Reply-To: gcc-gnats@gcc.gnu.org, bob@photowriters.com Received:(qmail 29774 invoked by uid 61); 10 Apr 2002 02:28:05 -0000 Message-Id:<20020410022805.29773.qmail@sources.redhat.com> Date: Tue, 09 Apr 2002 19:36:00 -0000 From: bob@photowriters.com Reply-To: bob@photowriters.com To: gcc-gnats@gcc.gnu.org X-Send-Pr-Version:gnatsweb-2.9.3 (1.1.1.1.2.31) Subject: target/6242: linker deletes compiled files X-SW-Source: 2002-04/txt/msg00568.txt.bz2 List-Id: >Number: 6242 >Category: target >Synopsis: linker deletes compiled files >Confidential: no >Severity: serious >Priority: medium >Responsible: unassigned >State: open >Class: sw-bug >Submitter-Id: net >Arrival-Date: Tue Apr 09 19:36:01 PDT 2002 >Closed-Date: >Last-Modified: >Originator: Bob Wilson >Release: gcc version 2.95.2 19991024 (release) >Organization: >Environment: Windows98 >Description: I wasted three hours late last night trying to compile and run three programs, each of which compiled and ran perfectly after some small corrections to some typing errors. The programs were copied from Sams Teach Yourself C++ in 24 hours, Third Edition by Jesse Liberty. So, if they compiled and ran properly, what was the problem? In the interest of ease of identification later (i.e., self documentation of a program's purpose), I gave discriptive names to both the project files and the actual programs. Project File Name Associated Source File Name Passing Function Arguments by Pointer.dev Passing_Function_Arguments_by_Pointer.cpp* Passing Function Arguments by Reference.dev Passing_Function_Arguments_by_Reference.cpp* Passing Function Arguments by Value.dev Passing_Function_Arguments_by_Value.cpp* *The underline charcters were used between words rather than spaces because the Bloodshed environment does not allow a C++ program to have the same name as However, I was unable to produce more than two .exe files in the same directory, and if I built or compiled the same file twice, the other .exe file would disappear. When I shortened the names to: Project File Name Associated Source File Name Passing by Pointer.dev Passing_Function_Arguments_by_Pointer.cpp Passing by Reference.dev Passing_Function_Arguments_by_Reference.cpp Passing by Value.dev Passing_Function_Arguments_by_Value.cpp all three compiled and there were three .exe files in the directory. Executable File Name Passing by Pointer.exe Passing by Reference.exe Passing by Value.exe Earlier, Ioannis Varnos and I had exchanged emails about a problem I experienced with the Bloodshed programming environment, and she had recommended that I stay away from the project creation function of the Bloodshed environment and stick to creating and compiling non project related C++ programs. I discovered that the solution to my problem lay in making direct changes to the undocumented .dev or project file with the notepad, so I continued to work with projects. Eureka! I thought and searched the .dev files for a truncation of my long file names, but they were not truncated in the project files. With Ioannis' advice in mind, I closed the project file upon which I was working and brought the .cpp files listed above into the Bloodshed "shell" one at a time and compiled them. The results were the same. I was unable to produce more than two .exe files in the same directory, and if I built or compiled the same file twice, the other .exe file would disappear. Although it is not documented, at least I cannot find it, there must be a maximum length of a file name beyond which the compiler/linker combination throws away or disregards the rest of the file name. When the compiler/linker erased a previously existing .exe file of a different name, it always erased the oldest. That leads me to believe that it searches from the top until it finds a file that matches the compiler's target file name, at least to the limits of its file name space, it deletes, and writes a new one, or it overwrites it and changes the name in the file directory. My guess is that the some part of the compiler or linker does not support the full length of windows file names. If this is the case, it is a flaw that should be fixed. Ironically, the names of any .exe file compiled and linked was never truncated. Before someone goes on the "yer-files-names-are-too-damn-long" rampage, consider the fact that, unless a compiler is totally compatible with operating system conventions, it is not operating system compliant, and, as such, it is not as versatile or as useful as it could be. Any such limitations or variances should be well documented and internal error trapping routines should provide immediate warnings to the user if he/she exceeds a limit such as the allowed length of the file name allowed by the programming environment which will result in the type of problems documented above. I truly hope that someone will send me an email that points out how I either missed the obvious, i.e., the documentation, help screen, option, etc., but I don't hold out much hope of that. I would be interested in knowing any other things like this that others have discovered. Regards, Bob Wilson >How-To-Repeat: Change program to Passing_Function_Arguments_by_Pointers.ccp and Passing_Function_Arguments_by_Value.ccp and compile each individually in the same target directory. >Fix: Make it compliant with Windows file names or incorporate the suggested documentation and error trapping routines. >Release-Note: >Audit-Trail: >Unformatted: