Re: [PATCH] libc: Replace i386/sys/fenv.h symlink with an #include shim

On Mon, Mar 8, 2021 at 11:00 AM Corinna Vinschen <[email protected]> wrote:
> This doesn't work.  The machine-specific header will get installed to
> $DESTDIR/usr/include/sys/fenv.h, and it will now include a non-existing
> file.  We have to keep the symlink or to duplicate the file.

How come the newlib/libm/machine/i386/fenv.c non-symlink works?  Is it
installed differently?

Coincidentally, is newlib/libc/machine/ft32/stpcmp.S file correct?

> However, I'm not aware that we still support a development platform not
> supporting symlinks.  Even WIndows supports them for ages now.

In the commit, I only mentioned "proper" symlink support for brevity,
but there's a lot in that word.  The differences are summarized for
example in https://github.com/git-for-windows/git/wiki/Symbolic-Links#background.
Due to these incompatibilities, if we want to handle symlinks on
Windows we only have bad options.

MSYS2 is keeping its traditional approach of making copies instead of
symlinks (which could probably be re-evaluated) and that leads to the
extraction issue described.  Git for Windows seems to just create
regular text files containing the link path by default.  Multiple
programs I use just skip the symlink when extracting.  Microsoft's
build of bsdtar (and probably Cygwin with winsymlinks:native) extracts
a symlink successfully, but then it's fixed as a file symlink.  None
of the three other Cygwin's methods (default, .lnk, WSL symlink) are
compatible with regular Win32 programs IIRC.  I think by now you can
see why I'm leaning towards not using symlinks unless unavoidable or
portability is out of question.

-- 
David Macek