[PATCH v3 2/2] x86_64/i386 fenv: Replace symlink with include fenv_stub.c

[Corinna Vinschen]

On Feb 20 07:54, Joel Sherrill wrote:
> On Thu, Feb 20, 2020 at 3:01 AM Corinna Vinschen <vinschen@redhat.com>
> wrote:
> 
> > Hey Joel,
> >
> > the patch itself is fine, but I'm puzzeling over the commit message.
> >
> [...]
> Yeah. It is an issue with tar. Apparently you can't create symlinks
> to non-existent files at least with bsdtar. If the link is in the tar file
> before
> the real file, it fails to create the file. Maybe GNU tar covers this
> up.
> [...]
> Here is the thread. It is a few messages in before investigation shows it
> is a tar file issue.
> 
> https://lists.rtems.org/pipermail/devel/2020-February/057184.html
> 
> The RTEMS ticket is here:
> 
> https://devel.rtems.org/ticket/3868
> 
> I know this is an odd one.

In that case I'd like to change the commit message to something along
these lines:

---
Having symlinks for these files led to an issue reported to the RTEMS
Project that showed up using some tar for native Windows to unpack the
newlib sources.  It creates symlinks in the tar file as copies of the
files the symlinks point to.  If the links appear in the tar file before 
the source exists, it cannot copy the file.

The solution in this patch is to convert the files that are symbolic
links into simple files which include the file they were linked to.
This should be more portable and avoids the symbolinc link problem.
---

This doesn't point to MSYS2 or "recet" Windows versions as the culprit.


That ok with you?


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/newlib/attachments/20200220/c65fb274/attachment.sig>