This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: FW: MAX_PATH problems with mingw gcc

On Wed, Oct 16, 2013 at 6:45 PM, Vladimir Simonov
<> wrote:
> 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.
There is an issue on file system with symbolic link, like Linux
ext2/3. It could vitally change behavior of GCC. The issue is
described as following.

Given that on Linux you have following directory structure:

       level2-b (-> level1-a/level2-a)

level2-b is a symbolic link created by:
ln -s level1-a/level2-a level1-b

Now run "ls base/level2-b/.." you probably would expect it equal to
"ls base", as the logic in your patch implies. However, the actual
behavior is equal to "ls base/level1-a" instead, because
base/level2-b/.. == base/level1-a/level2-a/.. == base/level1-a

Such a logic cannot be deduced simple from the name string, so your
patch can do nothing about it.

For your patch IMHO the way out could be just define a real function
for DOS FS, and leave a blank function body otherwise. Like:
filename_normalize (char *fn)
#if DOS


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]