Re: [PATCH v3 2/2] x86_64/i386 fenv: Replace symlink with include fenv_stub.c
Joel Sherrill <[email protected]>
| Newsgroups | gmane.comp.lib.newlib |
|---|---|
| Message-ID | <CAF9ehCXuYcnwbjp94WMVFqOg=JMkfA-nPsJu7o5=uODVqLj34w@mail.gmail.com> |
On Thu, Feb 20, 2020 at 8:10 AM Corinna Vinschen <[email protected]> wrote: > On Feb 20 07:54, Joel Sherrill wrote: > > On Thu, Feb 20, 2020 at 3:01 AM Corinna Vinschen <[email protected]> > > 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? > It is. :) Patch coming. --joel > > > Thanks, > Corinna > > -- > Corinna Vinschen > Cygwin Maintainer > Red Hat >