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

Joel Sherrill joel@rtems.org
Tue Feb 25 13:38:00 GMT 2020


On Thu, Feb 20, 2020 at 8:10 AM Corinna Vinschen <vinschen@redhat.com>
wrote:

> 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?
>

It is. :)

Patch coming.

--joel


>
>
> Thanks,
> Corinna
>
> --
> Corinna Vinschen
> Cygwin Maintainer
> Red Hat
>



More information about the Newlib mailing list