Presently, Crossworks outputs an object file name as defined by the Project property "Object File Name". This resultant filename is derived purely from the source file (without any paths).
For better or worse, some source code contains multiple files of the same name, which each file in a different directory. (An example would be the open source project x264, which has unique "cabac.c", "macroblock.c", and "set.c" in multiple directories.)
A straightforward sample project is attached that demonstrates the resultant problem in Crossworks when two source code files are both named "same.c". Crossworks compiles both source files and writes them to the same object file. If "Allow Multiple Symbol Definitions" is No, it displays a "multiple definitions" error message. If "Allow Multiple Symbol Definitions" is Yes, it is a race condition as to which source code file gets compiled first; only one set of symbols survive.
There could be multiple solutions to the problem. One would be to create subdirectories in the object file directory so that each object file is stored separately in a manner consistent with the source code. Another would be to escape characters in the relative filename path to create a longer unique object file filename. A third option might be to compute a message digest of the relative filename and use the resultant hash as the object file name. (A possible disadvantage of using the hash solely is that it would make it more difficult for the user to determine the file's origin if there were any linker errors/warnings.)
Please sign in to leave a comment.