Mail Archives: cygwin/2002/05/02/12:51:25
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/
- Raw text -