RE: not updating unwritable cache ../config.cache

[Bernard Dautrevaux <DAUTREVAUX at microprocess dot com>]

Title: RE: not updating unwritable cache ../config.cache

> -----Original Message-----
> From: Kai Henningsen [mailto:kai@cats.ms]
> Sent: Thursday, October 07, 1999 10:35 AM
> To: Kai Henningsen; Corinna Vinschen
> Cc: cygwin@sourceware.cygnus.com
> Subject: Re: not updating unwritable cache ../config.cache
>
>
> On 6 Oct 99, at 17:03, Corinna Vinschen wrote:
>
> > Kai Henningsen wrote:
> > >
> > > On 5 Oct 99, at 20:51, Corinna Vinschen wrote:
> > >
> > > > And last but not least:
> > > > - Constructive feedback always welcome.
> > > > - Patches are gratefully accepted.
> > >
> > > Well, here's at least _some_ feedback. Excerpt from building gcc:
> > >
> > > ----r-xr-x   1 administ Kein       160630 Oct  6 10:15
> genattrtab.o*
> > > ----r-xr-x   1 administ Kein       253372 Oct  6 10:15
> genattrtab.exe*
> > > -rw-r--r--   1 kai      Kein       106514 Oct  6 10:15
> insn-attrtab.c
> > > -rw-r--r--   1 kai      Kein            0 Oct  6 10:15 s-attrtab
> > > ----r-xr-x   1 administ Kein       167908 Oct  6 10:15
> insn-attrtab.o*
> > > ----r-xr-x   1 administ Kein       167214 Oct  6 10:15 i386.o*
> > > ----r-xr-x   1 administ Kein         8187 Oct  6 10:15 getpwd.o*
> >
> > Looks like as if you have edited with ntsec but compiled without it.
> > Would you be so kind to check this out?
>
> All of these were created from the same "make bootstrap" run.
> That's what I find so confusing.

Hummm... just a thought:
   genattrtab.o, genattrtab.exe, i386.o, getpwd.o were all created by compiling with some version of gcc installed on your NT box

   insn-attrtab.c is generated by genattrtab.exe, but I think the make rule is like "genattrtab > insn-attrtab.c", so the fact is in fact created by bash (or ash)

   s-attrtab is created by "touch s-attrtab" so is created also by bash/ash (or even directly by make perhaps).

What I'm wondering is that perhaps bash/ash is doing some special things to ensure that the generated files are correctly owned by the effective user, but that other programs may be fooled and attribute rights to the administrator?

>
> > Another one: Are you sure to have only one cygwin1.dll in $PATH
> > search path?
>
> Well, I have some cygwin1.dll.something in the same directory as
> the one to use, but I wouldn't expect those to be used.
>
> (check environment)
>
> And yes, it's exported (actually set by the .bat that starts bash).
>
> Hmm. Maybe someone there clobbers the CYGWIN variable? <find
> | xargs grep -w CYGWIN> Nope, at least nothing obvious.

Could it be that make do not re-export everything that's passed in the environment? I've header that some versions of gnu-make make some non-usual things in this area.

>
> Oh! Silly of me. Of _course_. It's the mingw gcc. Obviously, it won't
> care about ntsec.

Why? mingw gcc is compiled and run in the cygwin environment I think, so go through cygwin1.dll that handles ntsec.

>
> Regards - Kai Henningsen
>
> --
> http://www.cats.ms
> Spuentrup CTI       Fon: +49 251 322311 0 
> Windbreede 12       Fax: +49 251 322311 99
> D-48157 Münster     Mob: +49 161 3223111
> Germany             GSM: +49 171 7755060
>
> --
> Want to unsubscribe from this list?
> Send a message to cygwin-unsubscribe@sourceware.cygnus.com
>

--------------------------------------------
Bernard Dautrevaux
Microprocess Ingéniérie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:    +33 (0) 1 47 68 80 80
Fax:    +33 (0) 1 47 88 97 85
e-mail: dautrevaux@microprocess.com
                b.dautrevaux@usa.net
--------------------------------------------