Hi all, Constructions #include "../../some_module/some_header.h" are quite popular in our project. They lead to funny for Linux user problem which becomes real headache when we build the project by mingw based cross gcc. Several levels of such "include" may easy exceed Windows MAX_PATH limitation for file I/O functions (260 symbols). For example g:/w/project1/product1/bundle/console/mv_system/centralized/dialogs/selectors/../../../../machines/dialogs/selectors/../../../components/machines/browsers/tree_based_group_browser/../../../hierarchy_model_browser/hierarchy_model_browser.h:37:61: fatal error: ../../remote/async_invokers/client/async_action.h: No such file or directory #include "../../remote/async_invokers/client/async_action.h" As you see gcc tries to open g:/w/project1/product1/bundle/console/mv_system/centralized/dialogs/selectors/../../../../machines/dialogs/selectors/../../../components/machines/browsers/tree_based_group_browser/../../../hierarchy_model_browser/../../remote/async_invokers/client/async_action.h which length is 263 symbols. IMO the best solution would be to switch on Unicode version of file IO functions in libiberty but it is quite radical change. Attaching patch which works for me many years and illustrates another approach. Its main idea is to simplify paths in some key places working with filenames (libcpp, parse_include in directives.c and find_file_in_dir in files.c). With this patch code above compiles OK. There are many pro and contras, i.e. it adds additional, probably unnecessary work on Linux time but makes filenames shorter, it affects libiberty which is shared between gcc/binutils/gdb, but it may be useful in other packages, etc., etc. Anyway I'll be glad to hear any comments and may be to see some fix for above problem in gcc code. Best regards Vladimir Simonov
Attachment:
gcc-4.8.0-filename-normalize.patch
Description: gcc-4.8.0-filename-normalize.patch
