Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Message-ID: <3CD16E89.6040002@ece.gatech.edu>
Date: Thu, 02 May 2002 12:51:21 -0400
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: automake tests reveal other bugs... cp.exe and libtool
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

So I was building automake-1.6.1 and ran its self tests, which uncovered 
bugs in libtool-devel-20020316 and in cp.exe.  I'll report the libtool 
bug to that list as well, but the cp.exe bug needs fixin'...

Two unexpected failures:
   pr300-ltlib  (libtool bug)
   subobj9      (cp.exe bug -- or cygwin kernel?)

--Chuck

--------- cp.exe bug ------------------
subobj9:
   Fails in 'make distcheck' (actually during the distdir: target)
   because non-root is not allowed to preserve ownership on the
   target file: config.guess.  Okay, config.guess is a symlink to
   the "real" one in /usr/autotool/devel/...  The "real" one is
   owned by Administrator.  'cp -p' follows the link, and tries to
   set the ownership of the new copy to 'Administrator' -- which
   fails, of course.
     On linux, 'cp -p the_symlink destination/new_name' behaves thus,
	 where 'the_symlink' points to 'the_target'.
     1) new_name is created as an actual file, not a symlink
        (so does cygwin)
     2) file permissions from the_target are replicated on new_name.
     3) NO adjustments are made to the ownership or group of new_name.
        Those are not replicated from new_name's owner/group, NOR
        from the_symlink's owner/group.

     On cygwin, all of the attributes from the_target are applied
     to the new copy, including the_target's owner and group.
     Except that normal users aren't allowed to change ownership
     or change group to a group they are not a member of.  Since
     the_target is /usr/autotool/devel/...

   Fix: correct the behavior of cygwin's cp.exe to be more like linux.

--------- libtool bug ------------------
pr300-ltlib:
   Fails in 'make install-strip' because 'strip --strip-debug' on a
   static library goes berzerk when the library contains two copies
   of the same object file.  Due to a bug in libtool-20020316,
   the test statlib DOES contain two copies of "a.o":
     ar cru subdir/.libs/libb.a  .libs/a.o   a.o
   The fix is to correct libtool so that it doesn't include bot
   PIC and nonPIC object files...or to make 'strip.exe' tolerant
   of the problem.
     How strip fails: it unpacks the static archive into a
   temporary directory.  However, somehow during the process, because
   there are two files with the same name (pathnames are not
   preserved), the unpacked object file gets created without a
   security descriptor -- and "permission denied" to even ls the
   file...
     I think the problem in libtool is here: line 4259 in
   ltmain.in (4758 in libtool):
     oldobjs="$oldobjs$old_deplibs $non_pic_objects"
   well, $non_pic_objects=a.o, but $oldobjs=.libs/a.o
   so both object files get ar'ed into the static lib.  I'm not sure
   what the problem is: should we prevent .libs/a.o (the PIC object)
   from getting added to $oldobjs, or should this line actually read:
     oldobjs="$non_pic_objects"
   and nothing else?


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