Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Message-ID: <003a01c254d5$8b3aa9c0$0100a8c0@wdg.uk.ibm.com> From: "Max Bowsher" To: Subject: Subtle permissions bug in interaction between Makefiles & libtool (Cygwin-specific) Date: Thu, 5 Sep 2002 13:10:49 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 I've located an awkward bug in the interaction between common-sense Makefile rules and Cygwin libtool. The package I was building at the time was libiconv, but the issue is common to any autoconf-libtool build system. The libiconv.la file is installed as data (i.e. 644) - which is correct. However the Cygwin specific postinstall_cmds in libtool use the same install command to install the DLL. This results in the DLL being installed without execute permission (on ntsec systems), and causes "The application failed to initialize properly (0xc0000022)." errors from dependent exes. As far as I can see, the fix would be to sed '-m 644' to '-m 755' in Cygwin's postinstall_cmds. The problem is how (whether?) to deal with 600, 640, etc. The same problem exists with automake in the build system (example package: gettext), for the same reason. Max. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/