Community
Participate
Working Groups
GCC C Linker property - Other Objects when adding other objects in the following way to project properties: "${workspace_loc:/path1/path2/path3/B_baseAmplitude_StandardGate.o}" under Windows it is tranlated in a way gcc seems not to agree: Building target: inProva1Debug.exe Invoking: GCC C Linker gcc -o"inProva1Debug.exe" ./csrc/B_ProvainProva1_Application.o ./csrc/B_ProvainProva1_Configuration.o ./csrc/B_ProvainProva1_SoftwareUnit.o ./csrc/B_ProvainProva1_StandardGate.o ./csrc/RProd_ProvainProva1_SoftwareUnit.o ./csrc/R_ProvainProva1_StandardGate.o ./crunner/CRunner_inProva1_Application.o E:\Eclipse-Workspaces\DSPE-Workspace\path1\path2\path3\B_baseAmplitude_StandardGate.o -lpthreadGC2 gcc.exe: E:Eclipse-WorkspacesDSPE-Workspacepath1path2path3B_baseAmplitude_StandardGate.o: No such file or directory make: *** [inProva1Debug.exe] Error 1 make: Target `all' not remade because of errors. Build complete for project Prova_c
Further clarified this Bug: The same problem is available if other objects are specified with absolute path in the form: "C:\path1\path2\path3\B_baseAmplitude_StandardGate.o" Both described ways to specify other objects paths, are used automatically by buttons "Workspace.." and "FileSystem.." in properties editor under Win ! if the absolute path is added instead in the same way as on the Linux Platform: "C:/path1/path2/path3/B_baseAmplitude_StandardGate.o" everything work has it should. There's a further notice to this bug: if PATH to e.g. a .dll is added with the relative to workspace form "${workspace_loc:/path1/path2/path3/B_baseAmplitude_StandardGate.o}" but the .dll does not exists in the specified location, nothing at all is generated in the makefile. This could be really confusing, I think it is always better to generate the specified path and let GCC tell us about the problem of missing file.
Which version of gcc are you using? cygwin? mingw? I think this should work with mingw since it understands Windows paths. New cygwin versions do not.
I don't it matters, but we're using g++ 3.4.4. Things fall apart in the (emulated) shell that launches the linker. The backslashes (\) are interpreted by that shell and disappear before the linker is executed. The macro definition is serving double-duty: it is used in the list of prerequisites of the link rule and it is used on the link command line. These are really two different languages. Expressing the paths with forward slashes (/) works for make (and would be consistent with the treatment given other paths like those that arise from specifying references to libraries). Using forward slashes also works for (nearly?) every linker I've encountered, but I'm sure there are those that will insist on backslashes.
Hi Doug, the compiler we were using when I reported the Bug were the C compiler from MinGW. We still have a workaround to the problem, please let me know if the behaviuor changes in order that I may remove the workaround and retest the feature. We produce code with a generator and the information is filled automatically. Best Regards Tiz
Created attachment 88478 [details] proposed patch Here's a patch that makes the slashes go forward as I suggested.
I should have noted that it would be desirable to have this in the 4.0.x stream as well as in head.
I'll take a loook.
Created attachment 89510 [details] proposed patch Patch updated: must change slashes before call to ensurePathIsGNUMakeTargetRuleCompatibleSyntax().
Applied to 4.0.3 and HEAD. Thanks Keith.
