This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: coreutils: install transparent_exe issues?
- From: Corinna Vinschen <corinna-cygwin at cygwin dot com>
- To: cygwin at cygwin dot com
- Date: Mon, 30 Mar 2009 13:15:23 +0200
- Subject: Re: coreutils: install transparent_exe issues?
- References: <49D04B74.9090000@users.sourceforge.net>
- Reply-to: cygwin at cygwin dot com
On Mar 29 23:32, Yaakov S wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Eric,
>
> With cygwin-1.7.0-44 and coreutils-7.0-2, install(1) no longer appends
> '.exe' to the destination filename. STC:
>
> ### in a clean directory
> $ echo -e '#include <stdio.h>\nint main(void) { printf("Hello
> World!\\n"); }' > hello.c
>
> $ echo 'all: hello' > Makefile
>
> $ make
> cc hello.c -o hello
>
> $ mkdir -p d1
>
> $ install hello d1
>
> $ find . -type f
> ./d1/hello
> ./hello.c
> ./hello.exe
> ./Makefile
>
> This breaks non-autotoolized makefiles which don't account for EXEEXT.
> Interestingly, though, strip(1) will still add an .exe:
>
> $ strip d1/hello
>
> $ find d1 -type f
> d1/hello.exe
And if you call `install -s hello d1' you'll get a .exe suffix as well.
The problem is that the .exe suffix is added based on a heuristic in
the rename(2) system call. When strip strips the file it creates a
temporary file and renames it to the original filename afterwards.
This rename operation adds the exe suffix, seeing the original file
is an excutable.
Install OTOH just creates a file "d1/hello" and copies over the content.
There's no heuristic figuring out that the data is a valid executable
header and then renaming it on the fly. Thus, install as well as cp
still need their own `attach .exe suffix' code.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/