Custom Query (245 matches)

The behavior of realpath() and stat() for paths containing path rewrite components is inconsistent.

In particular, realpath() behaves as if such components were symlinks. However stat() doesn't recognize them as symlinks and will not report the S_IFLINK mode bit for them.

For example, calling reaplath("/@unixroot/usr") will give you C:/usr (if UNIXROOT is set to C:). Given this, one might expect that "/@unixroot" is a symlink but apparentlystat("/@unixroot")shows that this is a false assumption.

This is not only a theoretical question. There is at least one program that is broken because of that: Python (at least the version hosted ​here and distributed in our RPM that supports symlinks and therefore makes a difference between abspath and realpath).

Its os.path.realpath function is implemented not as a call to the libc realpath() function (as one might expect) but as a loop that walks over individual path components and calls readlink on those of them for which islink returns true. However islink (eventually backed up by stat()) returns false for paths like /@unixroot. First of all, it will return false because stat() itself will fail (see #283) but even if we imagine that that failure is fixed and stat() starts to work, it will simply return 0 in the S_IFLINK so that islink will still return false.

Such a behavior of islink completely breaks os.path.realpath functionality for paths containing /@unixroot and similar. in such cases realpath will just return the same value as os.path.abspath.

I discovered this problem when I was trying to fix the Python's ​virtualenv script (used to create directory-local python environments on the fly). Virtualenv does some path rebasing which fails on OS/2 for Python installed from RPM because it can't detect that C:/usr and /@unixroot/usr is the same thing. In virtualenv they originally do path comparison after calling os.path.abspath. Replacing that with os.path.realpath would let us fix the problem but we can't do that since realpath itself doesn't work.

Hi/2.

When setting gcc env up with gccenv.cmd, path for cc1 and cc1plus is missing.

If you set path for emx, you could not relize this. Because gcc335 called cc1 of emx not its companion cc1.

ld crashes when map file name differs from module name, because of wrong memory allocation.

Index: src/ld/ld.c
===================================================================
--- src/ld/ld.c	(revision 2508)
+++ src/ld/ld.c	(working copy)
@@ -3984,7 +3984,7 @@
 	{
 	  if (map_filename == NULL)
 	    {
-	      freeav[j++] = map_filename = ALLOCA (strlen (output_filename) + 5);
+	      freeav[j++] = map_filename = ALLOCA (strlen (exe_filename) + 5);
               strcpy (map_filename, exe_filename);
 	      _remext (map_filename);
 	      strcat (map_filename, ".map");