Mail Archives: cygwin/2004/04/07/14:55:56
On Wed, Apr 07, 2004 at 03:57:59PM +0200, Gerrit P. Haase wrote:
> Hi Edward,
>
> >> Perhaps I'm missing something obvious but it seems to me that the real
> >> question is why automake is installing things with the incorrect
> >> permissions for you. Is there a reason you're not focused on this issue?
>
> > Well, as a quick workaround I am focused on this issue (I install my own hacked
> > version of automake) but there are two reasons why I think 777 perms is a bad policy
> > to follow:
>
> > 1) I think its going to be a hard issue to sell automake on the necessity
> > of making cygwin behave totally different from any other environment,
> > and make a kludge to have arguments to install for cygwin be 755
> > by default.
>
> Why? Different platforms always need their own special way to get
> things running. BTW, the default setting for executables should be 755
> as it is on Linux too, in the Windows world, also shared libs need this
> permission.
ok, I can buy that..
> I'm not sure if automake includes code for managing DLL installation at
> all, this is usually done via libtool.
As it is, automake defines an INSTALL_DATA macro which translates into install -m 644
which is then substituted in Makefile.in. This install macro puts files and dlls
inside of lib. Some programs use libtool, some don't. Here are some packages that
don't:
binutils
gawk
gcc
gettext
libiconv
sed
tar
I'll make a complete list when I'm done, but there's a good start. It might be that these
packages don't use libtool for historical reasons, or for dependency reasons.
> The tools should just work. If they do things wrong, then the tools
> need to be fixed.
Then - as it stands - either:
1) every single package that has an autogenerated file from automake needs
to change via patch (because 644 is right now a hardcoded value, and
what you are asking for is a contingent value based on OS)
2) libtool has to be added as a dependency for the above packages and the above
packages have to change their configuration process change to use libtool
3) automake && autoconf have to be changed and have to become part of the
standard install (ie: automake; autoconf; configure; make; make install)
4) cygwin needs to somehow make readable files with extensions auto-executable
(ie: complete hack)
#1 - #2 seem to be logistical nightmares; #3 seems more manageable, but will probably
be a ton of effort because not every package uses the same version of autoconf and
automake and so there would be a lot of cleanup required; #4 seems pretty damn ugly.
I guess I could go with #3, but I have a feeling that opens up a whole can of worms.
(eg - I just tried automake on make-3.80-1 and it warned me to get an older version of
automake and to use aclocal. aclocal works but it comes in two flavors, 1.4 and 1.7, so
who knows how deep that pool goes.)
In any case, its going to take a concerted effort on the part of other module
maintainers to make things build properly.. its not going to be a trivial fix unless
you go with the hack option.
Ed
--
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/
- Raw text -