Re: Automake,cygwin: 'make clean' with libtool wrappers...

[Charles Wilson]

Alexandre Duret-Lutz wrote:

> BTW, what does the Automake 1.6.1 testsuite says under Cygwin?
> Are there some failing tests that this fix corrects?
> (subobj9.test maybe?)  Otherwise it would be nice to add a new
> testcase.

Without this patch, automake fails two tests:
  subobj9
  pr300-ltlib
With this patch, automake still fails both tests.

However, AFAICT, the reason is not related to the problem fixed by this 
patch (or, if this patch does fix a problem that would cause subobj9 to 
fail, it is being hidden by another bug that my patch doesn't address). 
  I think the subobj9 failure is caused by a bug in cygwin's cp.exe 
w.r.t. symlinks and permissions; I believe the bug in pr300-ltlib is 
caused by a bug in libtool.  Once those two problems are fixed, then 
perhaps we will *still* fail subobj9 (without this automake patch) -- 
but I'm not sure...

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.  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/../config.guess, it is owned by "root" (e.g. 
Administrator), not the user, the user is prevented from chown'ing 
new_name to 'Administrator'.

Fix: correct the behavior of cygwin's cp.exe...
Workaround: use 'automake -c'...blech.

I've report ed this problem with cygwin's cp.exe to the cygwin list, but 
so far have gotten no responses.

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?

I posted this bug report on the libtool list last week; so far no one 
has responded.

--Chuck