https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878
--- Comment #36 from Tamar Christina <tnfchris at gcc dot gnu.org> --- > That seems like a big hammer though and I'm not sure other Ada maintainers > will really be thrilled with it... Can't we devise a kludge in the gnattools > dir? > IMO it would have a far better chance of being accepted than this. You mean the use of translate_paths? So the problem is that if we look at GCC_LINK=$(CXX) $(GCC_LINK_FLAGS) $(ADA_INCLUDES) $(LDFLAGS) Most of the paths come from $(CXX) which is normally fine as you'd use $(CXX) normally as a command, e.g. $(CXX) <files and options>. When you do this the same thing happens, xgcc is a native program so it's paths get translated. You have `fix_srcfile_path` that can translate a single path, but this won't recognize multiple paths in a string, or paths to options, such as -L<path>, so even splitting GCC_LINK by spaces and iterating over them calling fix_srcfile_path won't work. One way to fix this without needing any second program is to change how gnatlink consumes arguments, e.g. instead of --LINK="<paths>" use --LINK <paths> -- or similar. E.g. an explicit start and end marker so the options don't have to be quoted. (same for --GCC). This would also have the side benefit of allowing support for paths with spaces in them since you can now quote "" individual paths. Would this be a better approach? Or did you mean make translate_paths and put it in the "tools" folder when ../stamp-tools is created? That would probably work too.
