FW: MAX_PATH problems with mingw gcc

[Vladimir Simonov]

Hi,

Resending filename-normalize patch to correct list gcc-patches@gcc.gnu.org.
All context, please, see below.

Regards
Vladimir Simonov

-----Original Message-----
From: Vladimir Simonov 
Sent: Wednesday, October 16, 2013 12:52 PM
To: 'Jiri Dobry'; 'gcc-help@gcc.gnu.org'
Subject: RE: MAX_PATH problems with mingw gcc

Hi all,

Sending new version of filename-normalize patch because people asking to make it public.

This version also fixes problems with gcov support of Linux binaries crosscompiled on Windows.
Problem: If you do crossbuild with gcov support, binaries refer gcda files like C:\Myproject\Mydir\Myobj.gcda.
After run on Linux files with names  like "C:\Myproject\Mydir\Myobj.gcda" are created.
No any directory tree.
The last chunk of new patch fixes this.

Best regards
Vladimir Simonov

-----Original Message-----
From: Simonov, Vladimir 
Sent: Monday, May 27, 2013 8:15 PM
To: gcc-help@gcc.gnu.org
Subject: MAX_PATH problems with mingw gcc

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: gcc-4.8.1-filename-normalize.patch
Type: application/octet-stream
Size: 4354 bytes
Desc: gcc-4.8.1-filename-normalize.patch
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20131016/af227730/attachment.obj>