Re: [PATCH] libc: Replace i386/sys/fenv.h symlink with an #include shim
Corinna Vinschen via Newlib <[email protected]>
| Newsgroups | gmane.comp.lib.newlib |
|---|---|
| Message-ID | <[email protected]> |
On Mar 7 16:03, David Macek via Newlib wrote: > As in fbaa096772f77be664864d80508906ad018cc23b: > > Having symlinks leads to issue unpacking the sources on platforms without proper > symlink support. These platforms mostly extract symlinks from the archive 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 symbolic link problem. > > Signed-off-by: David Macek <[email protected]> > --- > > Excuse my ignorance, but is this acceptable? I'm not sure > what actually happens with these files, but it'd be nice to > get rid of the last symlink in the repo. 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. However, I'm not aware that we still support a development platform not supporting symlinks. Even WIndows supports them for ages now. Corinna