* Re: MSYS mode (continue) [not found] ` <20130704163612.GA4729@ednor.casa.cgf.cx> @ 2013-07-05 9:07 ` Corinna Vinschen 2013-07-05 16:42 ` Christopher Faylor 0 siblings, 1 reply; 52+ messages in thread From: Corinna Vinschen @ 2013-07-05 9:07 UTC (permalink / raw) To: cygwin-developers On Jul 4 12:36, Christopher Faylor wrote: > On Thu, Jul 04, 2013 at 02:16:17PM +0200, Corinna Vinschen wrote: > >On Jul 4 13:45, Alexey Pavlov wrote: > >> 2013/7/4 Corinna Vinschen: > >> > On Jul 4 14:23, Alexey Pavlov wrote: > >> >> 2013/7/4 Corinna Vinschen: > >> >> > On Jul 4 12:37, Alexey Pavlov wrote: > >> >> >> 2013/7/4 Corinna Vinschen: > >> >> >> > On Jul 4 13:09, Alexey Pavlov wrote: > >> >> >> >> struct utsname > >> >> >> >> { > >> >> >> >> - char sysname[20]; > >> >> >> >> + char sysname[21]; > >> >> >> > > >> >> >> > We can't do that. struct utsname is a publically facing structure. > >> >> >> > If you change the size, you're breaking compatibility with existing > >> >> >> > applications. > >> >> >> > > >> >> >> > You should better drop some character from the string you want to enter > >> >> >> > here. > >> >> >> > > >> >> >> > >> >> >> I can't drop any symbol from "MINGW32" word :) > >> >> > > >> >> > That's not 20 chars long. > >> >> > > >> >> Yes. But not only this need to be in 20 symbols. On cygwin 20 symbols is: > >> >> > >> >> CYGWIN_NT-6.1-WOW64\0 > >> >> > >> >> But > >> >> > >> >> MINGW32_NT-6.1-WOW64\0 > >> >> > >> >> is 21 symbol. > >> > > >> > Then drop the dash between "NT" and "6.1". Or let's drop the WOW64 > >> > since it's redundant anyway, given the content of "machine". > >> > > >> > >> Let's drop it! > > > >I'm ok with that, but I think we should drop the "32" from MINGW in > >the first place. > > > >Does anybody rely on the "WOW64" in uname -s output? I just checked > >the scripts in /bin in my installation and none of it seems to check > >for that info. > > > >And then again, it *is* redundant, given the uname -m output... > > Can we back up a moment and discuss whether, regardless of string > length, this is the right approach? This isn't what I'd envisioned > when I said "hooks". I don't think hooks make sense for such simple, nonintrusive stuff. This may be different for bigger things like the weird "copy symlinks" stuff, of course. Also, you didn't so far define how these hooks are supposed to work. A detailed description of your idea would be useful for the discussion. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: MSYS mode (continue) 2013-07-05 9:07 ` MSYS mode (continue) Corinna Vinschen @ 2013-07-05 16:42 ` Christopher Faylor 2013-07-11 11:17 ` Corinna Vinschen 0 siblings, 1 reply; 52+ messages in thread From: Christopher Faylor @ 2013-07-05 16:42 UTC (permalink / raw) To: cygwin-developers On Fri, Jul 05, 2013 at 11:07:04AM +0200, Corinna Vinschen wrote: >On Jul 4 12:36, Christopher Faylor wrote: >> On Thu, Jul 04, 2013 at 02:16:17PM +0200, Corinna Vinschen wrote: >> >On Jul 4 13:45, Alexey Pavlov wrote: >> >> 2013/7/4 Corinna Vinschen: >> >> > On Jul 4 14:23, Alexey Pavlov wrote: >> >> >> 2013/7/4 Corinna Vinschen: >> >> >> > On Jul 4 12:37, Alexey Pavlov wrote: >> >> >> >> 2013/7/4 Corinna Vinschen: >> >> >> >> > On Jul 4 13:09, Alexey Pavlov wrote: >> >> >> >> >> struct utsname >> >> >> >> >> { >> >> >> >> >> - char sysname[20]; >> >> >> >> >> + char sysname[21]; >> >> >> >> > >> >> >> >> > We can't do that. struct utsname is a publically facing structure. >> >> >> >> > If you change the size, you're breaking compatibility with existing >> >> >> >> > applications. >> >> >> >> > >> >> >> >> > You should better drop some character from the string you want to enter >> >> >> >> > here. >> >> >> >> > >> >> >> >> >> >> >> >> I can't drop any symbol from "MINGW32" word :) >> >> >> > >> >> >> > That's not 20 chars long. >> >> >> > >> >> >> Yes. But not only this need to be in 20 symbols. On cygwin 20 symbols is: >> >> >> >> >> >> CYGWIN_NT-6.1-WOW64\0 >> >> >> >> >> >> But >> >> >> >> >> >> MINGW32_NT-6.1-WOW64\0 >> >> >> >> >> >> is 21 symbol. >> >> > >> >> > Then drop the dash between "NT" and "6.1". Or let's drop the WOW64 >> >> > since it's redundant anyway, given the content of "machine". >> >> > >> >> >> >> Let's drop it! >> > >> >I'm ok with that, but I think we should drop the "32" from MINGW in >> >the first place. >> > >> >Does anybody rely on the "WOW64" in uname -s output? I just checked >> >the scripts in /bin in my installation and none of it seems to check >> >for that info. >> > >> >And then again, it *is* redundant, given the uname -m output... >> >> Can we back up a moment and discuss whether, regardless of string >> length, this is the right approach? This isn't what I'd envisioned >> when I said "hooks". > >I don't think hooks make sense for such simple, nonintrusive stuff. >This may be different for bigger things like the weird "copy symlinks" >stuff, of course. > >Also, you didn't so far define how these hooks are supposed to work. >A detailed description of your idea would be useful for the discussion. http://cygwin.com/ml/cygwin/2013-06/msg00515.html I thought it was clear that this would be a general mechanism which could be used to modify Cygwin's behavior. So, in this scenario, you would: callout (CO_UNAME, &name); We would provide a cygwin_internal method for setting up the callout hook. If that wasn't set up then obviously callout would be a no-op. I don't think that it makes sense for there to be two mechanisms to accomplish the goal of allowing another DLL to modify Cygwin's behavior. Obviously a MSYS helper DLL would have to do the setup early, maybe in its DLL initialization. ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: MSYS mode (continue) 2013-07-05 16:42 ` Christopher Faylor @ 2013-07-11 11:17 ` Corinna Vinschen 2013-07-25 11:06 ` Alexey Pavlov 2013-07-25 13:11 ` Charles Wilson 0 siblings, 2 replies; 52+ messages in thread From: Corinna Vinschen @ 2013-07-11 11:17 UTC (permalink / raw) To: cygwin-developers On Jul 5 12:42, Christopher Faylor wrote: > On Fri, Jul 05, 2013 at 11:07:04AM +0200, Corinna Vinschen wrote: > >I don't think hooks make sense for such simple, nonintrusive stuff. > >This may be different for bigger things like the weird "copy symlinks" > >stuff, of course. > > > >Also, you didn't so far define how these hooks are supposed to work. > >A detailed description of your idea would be useful for the discussion. > > http://cygwin.com/ml/cygwin/2013-06/msg00515.html > > I thought it was clear that this would be a general mechanism which > could be used to modify Cygwin's behavior. > > So, in this scenario, you would: > > callout (CO_UNAME, &name); > > We would provide a cygwin_internal method for setting up the callout > hook. If that wasn't set up then obviously callout would be a no-op. > > I don't think that it makes sense for there to be two mechanisms to > accomplish the goal of allowing another DLL to modify Cygwin's behavior. > > Obviously a MSYS helper DLL would have to do the setup early, maybe > in its DLL initialization. The hooking itself is the lesser problem. What I'm rather wondering about is how the MSYS helper DLL comes into action. Ideally, MSYS executables would actually be Cygwin executables, linked against the Cygwin DLL. The advantage being that the executable could run in an MSYS and a Cygwin environment, whatever it happens to be dropped into. The MSYS DLL could be loaded from an MSYS specific crt0.o, which tries to load the MSYS DLL dynamically. Either loading the MSYS DLL works or it doesn't, but if it works, it could just call cygwin_internal in it's dll_entry function to set up the hooking mechanism. If it fails, the executable works as a plain Cygwin executable. Alternatively, MSYS crt0.o itself provides all the necessary functionality, which might be a lot easier to implement. It could call cygwin_internal and provide the necessary callbacks and it would be linked against the Cygwin DLL "just so". Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: MSYS mode (continue) 2013-07-11 11:17 ` Corinna Vinschen @ 2013-07-25 11:06 ` Alexey Pavlov 2013-07-25 11:11 ` Corinna Vinschen 2013-07-25 13:11 ` Charles Wilson 1 sibling, 1 reply; 52+ messages in thread From: Alexey Pavlov @ 2013-07-25 11:06 UTC (permalink / raw) To: cygwin-developers Is this thread is interesting yet or we can leave all as is? Regards, Alexey. ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: MSYS mode (continue) 2013-07-25 11:06 ` Alexey Pavlov @ 2013-07-25 11:11 ` Corinna Vinschen 0 siblings, 0 replies; 52+ messages in thread From: Corinna Vinschen @ 2013-07-25 11:11 UTC (permalink / raw) To: cygwin-developers On Jul 25 15:06, Alexey Pavlov wrote: > Is this thread is interesting yet or we can leave all as is? This is of course interesting. That's why I sent my mail on the 11th. A reply to the points raised and further discussion would help a lot. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: MSYS mode (continue) 2013-07-11 11:17 ` Corinna Vinschen 2013-07-25 11:06 ` Alexey Pavlov @ 2013-07-25 13:11 ` Charles Wilson 2013-07-25 15:02 ` Corinna Vinschen 1 sibling, 1 reply; 52+ messages in thread From: Charles Wilson @ 2013-07-25 13:11 UTC (permalink / raw) To: cygwin-developers On 7/11/2013 7:17 AM, Corinna Vinschen wrote: > The hooking itself is the lesser problem. What I'm rather wondering > about is how the MSYS helper DLL comes into action. > > Ideally, MSYS executables would actually be Cygwin executables, linked > against the Cygwin DLL. The advantage being that the executable could > run in an MSYS and a Cygwin environment, whatever it happens to be > dropped into. > > The MSYS DLL could be loaded from an MSYS specific crt0.o, which tries > to load the MSYS DLL dynamically. Either loading the MSYS DLL works or > it doesn't, but if it works, it could just call cygwin_internal in it's > dll_entry function to set up the hooking mechanism. If it fails, the > executable works as a plain Cygwin executable. I dunno. Back in 2009, I (re)built and updated to then-current EVERY single element of MinGW.org's msys distribution. There were a LOT of patches required, which were not required on cygwin. Some, to be sure, were because both cygwin and the app in question had progressed since the msys fork circa cygwin 1.3.x -- for instance, OpenSSH. As cygwin itself gained new capabilities, the OpenSSH code adapted -- eliminating certain workarounds it had previously implemented which were no longer necessary on newer cygwin. However, as MSYS was frozen in time, those workarounds had to be manually patched back in. In the cygwin-as-msys scenario, *those* sorts of things would not be necessary, because cygwin-as-msys would be just as "current" as regular cygwin; in fact, sharing the same cygwin1.dll. However, many of the patches were to handle differences inherent in the environment. For example, msys-make kept the "allow X:/foo/bar paths in rules" patch, which cgf long ago removed from cygwin-make. The reason for that change is obvious; msys is intended to make compiling with native mingw[64,.org] compilers easier, and so you run into dos-style paths a lot more often, even when you are nominally on the "unix" side of the fence as with (msys-)make. Or, as an example, I suspect msys users would prefer a "native windowing" tcl/tk -> gdb/insight, not the X11-windowing version we now ship. However, we (cygwin) long ago made the decision that we would not muck with our X11 tcl/tk's directory structure to accomodate a side-by-side GDI version simultaneously installed. So "we" can't actually provide both (one X11 that is probably preferred by "real" cygwin users, and one GDI that the cygwin-as-msys users would prefer), without a lot of rework in our existing tcl/tk offerings. A final example: msys (and, I presume, cygwin-as-msys) deliberate dumbs down the permission model to the old mechanism used by cygwin on FAT: everything is owned by $current-user, every file is always readable by everybody. Every directory is rx by everybody. The DOS read-only flag is used to control +w/-w for all users. But some apps (and our config-foo scripts!) check those settings; for instance, ssh.exe wants to ensure that ~/.ssh is not writable by anybody except the owner. That stuff had to be patched out, to work on msys. Well, we don't want $real-cygwin's ssh.exe to act in such an insecure manner, but then cygwin-as-msys users lose out, unless then only use the ssh.exe from their parallel installation of $real-cygwin. > Alternatively, MSYS crt0.o itself provides all the necessary functionality, > which might be a lot easier to implement. It could call cygwin_internal > and provide the necessary callbacks and it would be linked against the > Cygwin DLL "just so". I think you would actually need an entirely separate distribution of tools, each compiled specifically for the "new" platform -- so they could directly link against the msys-modifier DLL (as well as cygwin1.dll). The good news is, there's already a project out there to handle distributing and maintaining a collection of msys ports -- "we" don't have to do it. -- Chuck ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: MSYS mode (continue) 2013-07-25 13:11 ` Charles Wilson @ 2013-07-25 15:02 ` Corinna Vinschen 2013-07-25 18:21 ` Charles Wilson 0 siblings, 1 reply; 52+ messages in thread From: Corinna Vinschen @ 2013-07-25 15:02 UTC (permalink / raw) To: cygwin-developers On Jul 25 09:11, Charles Wilson wrote: > On 7/11/2013 7:17 AM, Corinna Vinschen wrote: > >The hooking itself is the lesser problem. What I'm rather wondering > >about is how the MSYS helper DLL comes into action. > > > >Ideally, MSYS executables would actually be Cygwin executables, linked > >against the Cygwin DLL. The advantage being that the executable could > >run in an MSYS and a Cygwin environment, whatever it happens to be > >dropped into. > > > >The MSYS DLL could be loaded from an MSYS specific crt0.o, which tries > >to load the MSYS DLL dynamically. Either loading the MSYS DLL works or > >it doesn't, but if it works, it could just call cygwin_internal in it's > >dll_entry function to set up the hooking mechanism. If it fails, the > >executable works as a plain Cygwin executable. > > I dunno. Back in 2009, I (re)built and updated to then-current EVERY > single element of MinGW.org's msys distribution. There were a LOT > of patches required, which were not required on cygwin. > [...] In how far does this affect us today? The idea to have a Cygwin DLL underneath and just add the MSYS functionality by linking one way or the other allows to get rid of lots of old workarounds. There's no reason to stick with the old ways. > However, many of the patches were to handle differences inherent in > the environment. For example, msys-make kept the "allow X:/foo/bar > paths in rules" patch, which cgf long ago removed from cygwin-make. > [...] This isn't relevant. The idea is to have a different crt0.o which allows to get the MSYS specific functionaily by building an application. against it. This does not reduce the necessity to patch applications which require special functionality like a DOS-path-resistant make. > But some apps (and our config-foo scripts!) check those settings; > for instance, ssh.exe wants to ensure that ~/.ssh is not writable by > anybody except the owner. That stuff had to be patched out, to work > on msys. Which is bad. I removed some older code from ssh specificially per the request from the upstream devs since they thought it's too unsecure. It's kind of frustrating having others adding this stuff back in just to stay happily unsecure. Windows 95 is long gone. > Well, we don't want $real-cygwin's ssh.exe to act in such an > insecure manner, but then cygwin-as-msys users lose out, unless then > only use the ssh.exe from their parallel installation of > $real-cygwin. And the disadvantage is...? The whole idea is to be able to stick to full-fledged Cygwin functionalitiy, except for the cases where it revolves around building native applications and DOS path handling. There's no good reason to duplicate everything in an incompatible way. > >Alternatively, MSYS crt0.o itself provides all the necessary functionality, > >which might be a lot easier to implement. It could call cygwin_internal > >and provide the necessary callbacks and it would be linked against the > >Cygwin DLL "just so". > > I think you would actually need an entirely separate distribution of > tools, That was the point, Chuck. The idea was to have an MSYS distro with tools linked against the special crt0.o to get the aforementioned extra functionality. But underlying there's still a normal Cygwin DLL and most tools could just be copied verbatim since they don't need this extra functionality. You could have your cake *and* eat it. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: MSYS mode (continue) 2013-07-25 15:02 ` Corinna Vinschen @ 2013-07-25 18:21 ` Charles Wilson 2013-07-25 18:33 ` Charles Wilson 2013-07-25 20:53 ` Christopher Faylor 0 siblings, 2 replies; 52+ messages in thread From: Charles Wilson @ 2013-07-25 18:21 UTC (permalink / raw) To: cygwin-developers On 7/25/2013 11:02 AM, Corinna Vinschen wrote: > On Jul 25 09:11, Charles Wilson wrote: >> On 7/11/2013 7:17 AM, Corinna Vinschen wrote: >>> The hooking itself is the lesser problem. What I'm rather wondering >>> about is how the MSYS helper DLL comes into action. >>> >>> Ideally, MSYS executables would actually be Cygwin executables, linked >>> against the Cygwin DLL. The advantage being that the executable could >>> run in an MSYS and a Cygwin environment, whatever it happens to be >>> dropped into. >>> >>> The MSYS DLL could be loaded from an MSYS specific crt0.o, which tries >>> to load the MSYS DLL dynamically. Either loading the MSYS DLL works or >>> it doesn't, but if it works, it could just call cygwin_internal in it's >>> dll_entry function to set up the hooking mechanism. If it fails, the >>> executable works as a plain Cygwin executable. >> >> I dunno. Back in 2009, I (re)built and updated to then-current EVERY >> single element of MinGW.org's msys distribution. There were a LOT >> of patches required, which were not required on cygwin. >> [...] > > In how far does this affect us today? The idea to have a Cygwin DLL > underneath and just add the MSYS functionality by linking one way or > the other allows to get rid of lots of old workarounds. There's no > reason to stick with the old ways. Right, that's what the paragraph you snipped was about. >> However, many of the patches were to handle differences inherent in >> the environment. For example, msys-make kept the "allow X:/foo/bar >> paths in rules" patch, which cgf long ago removed from cygwin-make. >> [...] > > This isn't relevant. The idea is to have a different crt0.o which > allows to get the MSYS specific functionaily by building an application. > against it. This does not reduce the necessity to patch applications > which require special functionality like a DOS-path-resistant make. Ah, but you're assuming that the app itself is *recompiled* so that it links a different crt0.o. I interpreted your statement: "The advantage being that the executable could run in an MSYS and a Cygwin environment, whatever it happens to be dropped into." to mean "the exact same binary". That misunderstanding is what led to most of the confusion below. My point is, I don't think *that* would work, for all the reasons I detailed. >> But some apps (and our config-foo scripts!) check those settings; >> for instance, ssh.exe wants to ensure that ~/.ssh is not writable by >> anybody except the owner. That stuff had to be patched out, to work >> on msys. > > Which is bad. I removed some older code from ssh specificially per the > request from the upstream devs since they thought it's too unsecure. > It's kind of frustrating having others adding this stuff back in just > to stay happily unsecure. Windows 95 is long gone. Of course it's bad. MSYS(current version), based on cygwin-1.3.x AND with an even more broken security model than 1.3.x had, sux when compared to modern day cygwin. However...a LOT of people don't care about file security when operating in a network environment that is deemed "protected" from outside interference. E.g. network shares on an internal lab network, etc. At $dayjob, I've seen folks get really annoyed by the issues that crop up when trying to mix native tools and cygwin's security model [1]. [1] the magic ----------+ 1 me mygroup 1.4M Jul 25 11:51 some-file permssion settings you get when some-file was created using win32 tools. So, they prefer MSYS no-security model, because in a protected network, they just want to get their job done, and not spend time chmod'ing stuff (or, in severe cases you can get yourself into a jam where you don't even have permission to "fix" it, and you have to get some IT support guy with Local Administrator privilege to do it. "And how did you create this file? What where you doing?"). So...if your msys-on-cygwin implements $dumb-security, then...no ssh at all? (Geez, I've seen people store their ~/.ssh on a network share, which is...counterindicated, at best. But it's still done.) >> Well, we don't want $real-cygwin's ssh.exe to act in such an >> insecure manner, but then cygwin-as-msys users lose out, unless then >> only use the ssh.exe from their parallel installation of >> $real-cygwin. > > And the disadvantage is...? The whole idea is to be able to stick to > full-fledged Cygwin functionalitiy, except for the cases where it > revolves around building native applications and DOS path handling. > There's no good reason to duplicate everything in an incompatible > way. I thought the "whole idea" was to replicate the existing msys toolkit (which currently includes rsh, ssh, and an extremely limited subset of the cygwin universe), only with a better, more maintainable core msys dll (which is actually cygwin1.dll + the extra hook-impl-providing msys thingy). >>> Alternatively, MSYS crt0.o itself provides all the necessary functionality, >>> which might be a lot easier to implement. It could call cygwin_internal >>> and provide the necessary callbacks and it would be linked against the >>> Cygwin DLL "just so". >> >> I think you would actually need an entirely separate distribution of >> tools, > > That was the point, Chuck. The idea was to have an MSYS distro with > tools linked against the special crt0.o to get the aforementioned extra > functionality. Ah, so you're not talking about dropping in "the same executable" into the MSYS arena and expecting its behavior to magically change. C:\cygwin-msys\bin\make.exe is a different binary than C:\cygwin\bin\make.exe. OK so far. > But underlying there's still a normal Cygwin DLL and > most tools could just be copied verbatim since they don't need this > extra functionality. And that's the bit where I disagree. Sure, some scripting tools might not need adjustment, so long as their interpreter was $MSYS-enabled (e.g. automake -> msys-perl, msys-bash) -- because the script will "see" dos-style paths, so its interpreter better be able to handle them. But unless you restrict yourself to only passing around relative paths (or god forbid, that old "unity mount" idea), any .exe will need to live in one world or the other. Otherwise, how would paths be interpreted? Using which tools' mount table? Naturally from the command line I can compensate: msys$ /c/cygwin/bin/foobar.exe $(/c/cygwin/bin/cygpath.exe -u $(cygpath -d /msys/mount/table/path) ) but yee gods that'd be annoying in any automated setting. -- Chuck ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: MSYS mode (continue) 2013-07-25 18:21 ` Charles Wilson @ 2013-07-25 18:33 ` Charles Wilson 2013-07-25 20:53 ` Christopher Faylor 1 sibling, 0 replies; 52+ messages in thread From: Charles Wilson @ 2013-07-25 18:33 UTC (permalink / raw) To: cygwin-developers On 7/25/2013 2:20 PM, Charles Wilson wrote: > On 7/25/2013 11:02 AM, Corinna Vinschen wrote: >> This isn't relevant. The idea is to have a different crt0.o which >> allows to get the MSYS specific functionaily by building an application. >> against it. This does not reduce the necessity to patch applications >> which require special functionality like a DOS-path-resistant make. > > Ah, but you're assuming that the app itself is *recompiled* so that it > links a different crt0.o. I interpreted your statement: > "The advantage being that the executable could run in > an MSYS and a Cygwin environment, whatever it happens > to be dropped into." > to mean "the exact same binary". That misunderstanding is what led to > most of the confusion below. > > My point is, I don't think *that* would work, for all the reasons I > detailed. Wait, ignore the rest of the previous message. I think I get where you're going now, but I'll need to think on it some more. Going to be AFK for a day or so, tho... -- Chuck ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: MSYS mode (continue) 2013-07-25 18:21 ` Charles Wilson 2013-07-25 18:33 ` Charles Wilson @ 2013-07-25 20:53 ` Christopher Faylor 2013-07-25 21:08 ` LRN 2013-07-26 8:15 ` Corinna Vinschen 1 sibling, 2 replies; 52+ messages in thread From: Christopher Faylor @ 2013-07-25 20:53 UTC (permalink / raw) To: cygwin-developers On Thu, Jul 25, 2013 at 02:20:50PM -0400, Charles Wilson wrote: >> But underlying there's still a normal Cygwin DLL and >> most tools could just be copied verbatim since they don't need this >> extra functionality. > >And that's the bit where I disagree. Sure, some scripting tools might >not need adjustment, so long as their interpreter was $MSYS-enabled >(e.g. automake -> msys-perl, msys-bash) -- because the script will "see" >dos-style paths, so its interpreter better be able to handle them. > >But unless you restrict yourself to only passing around relative paths >(or god forbid, that old "unity mount" idea), any .exe will need to live >in one world or the other. Otherwise, how would paths be interpreted? >Using which tools' mount table? > >Naturally from the command line I can compensate: > >msys$ /c/cygwin/bin/foobar.exe $(/c/cygwin/bin/cygpath.exe -u $(cygpath >-d /msys/mount/table/path) ) > >but yee gods that'd be annoying in any automated setting. I don't know if this helps but the vague plan is to now have two DLLs where before you only had one. You'd still be providing "MSYS" binaries which relied on "MSYS.dll" but, under the hood, MSYS.dll would be only a small dll which relied on cygwin1.dll for all of the heavy lifting. You'd still have a normal MSYS distribution and it would still, in theory, support everything (with the possible exception of very lax security) that the old MSYS did. An MSYS release would consist of MSYS*.dll, cygwin1.dll, bash, etc. I don't think anyone was proposing seamless interoperation between MSYS and cygwin. The reason that this came about was because someone was proposing an MSYS2 so, rather than take another copy of the cygwin source code and hack on it again, Corinna thought maybe we could do something to minimize the fork. cgf ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: MSYS mode (continue) 2013-07-25 20:53 ` Christopher Faylor @ 2013-07-25 21:08 ` LRN 2013-07-25 21:31 ` Larry Hall (Cygwin Developers) 2013-07-26 8:15 ` Corinna Vinschen 1 sibling, 1 reply; 52+ messages in thread From: LRN @ 2013-07-25 21:08 UTC (permalink / raw) To: cygwin-developers -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 26.07.2013 00:53, Christopher Faylor wrote: > On Thu, Jul 25, 2013 at 02:20:50PM -0400, Charles Wilson wrote: >>> But underlying there's still a normal Cygwin DLL and >>> most tools could just be copied verbatim since they don't need this >>> extra functionality. >> >> And that's the bit where I disagree. Sure, some scripting tools might >> not need adjustment, so long as their interpreter was $MSYS-enabled >> (e.g. automake -> msys-perl, msys-bash) -- because the script will "see" >> dos-style paths, so its interpreter better be able to handle them. >> >> But unless you restrict yourself to only passing around relative paths >> (or god forbid, that old "unity mount" idea), any .exe will need to live >> in one world or the other. Otherwise, how would paths be interpreted? >> Using which tools' mount table? >> >> Naturally from the command line I can compensate: >> >> msys$ /c/cygwin/bin/foobar.exe $(/c/cygwin/bin/cygpath.exe -u $(cygpath >> -d /msys/mount/table/path) ) >> >> but yee gods that'd be annoying in any automated setting. > > I don't know if this helps but the vague plan is to now have two DLLs > where before you only had one. You'd still be providing "MSYS" binaries > which relied on "MSYS.dll" but, under the hood, MSYS.dll would be only a > small dll which relied on cygwin1.dll for all of the heavy lifting. > > You'd still have a normal MSYS distribution and it would still, in theory, > support everything (with the possible exception of very lax security) that > the old MSYS did. An MSYS release would consist of MSYS*.dll, cygwin1.dll, > bash, etc. Out of curiosity: why do you insist on having MSYS functionality in a separate dll, when it could be just part of cygwin1.dll (disableable and enableable in the same way other Cygwin features are disabled/enabled - via CYGWIN envvar)? What advantage would that give, that justifies the increase in implementation complexity (hooking up the dll, etc)? Was that justified earlier in this thread and i just neglected to read that far back? Also, i'm planning on building experimental cygwin dll that doesn't use NO_ACL on mounts by default (msys2 always uses NO_ACL on mounts by default) and see if it works for me. If it does, that'll remove yet another item from the list of msys vs cygwin differences, at least for me. - -- O< ascii ribbon - stop html email! - www.asciiribbon.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) iQEcBAEBAgAGBQJR8ZOtAAoJEOs4Jb6SI2CwUSgIAJdl3w68YM9QQ+W4/HC4cWnj 7Nup127y2LI31ZaNKsr29XVfk9PaGCDYx/Ueoi5CCaOmZCaRmeAWGnaS6ftXjstf KM1/ph/dIOx7nT2jHP3eWRp1IJh1DIHUOS0ZuTilgHWZzbpteKwdyq+WOuF1dT0J c11ue23sYPSJ2QyXGYBuOfCjok+HCGCnfX305DKhWNwriw57xcixU8pU8TaGRDM8 zUlC2VJ3NO7e3Es2JDIq4uqVkh/JFdUZ+2W63W+xyTQyRJgLzA7egnq+8fpoX2HN qM70cvmv2wD0AhS2tAHYPOPCGlfwoayd+dAJCVyy/cgs1qCnS/3N0yy6xTGkXGg= =bHcW -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: MSYS mode (continue) 2013-07-25 21:08 ` LRN @ 2013-07-25 21:31 ` Larry Hall (Cygwin Developers) 2013-07-26 1:55 ` Christopher Faylor 0 siblings, 1 reply; 52+ messages in thread From: Larry Hall (Cygwin Developers) @ 2013-07-25 21:31 UTC (permalink / raw) To: cygwin-developers On 7/25/2013 5:07 PM, LRN wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 26.07.2013 00:53, Christopher Faylor wrote: >> On Thu, Jul 25, 2013 at 02:20:50PM -0400, Charles Wilson wrote: >>>> But underlying there's still a normal Cygwin DLL and >>>> most tools could just be copied verbatim since they don't need this >>>> extra functionality. >>> >>> And that's the bit where I disagree. Sure, some scripting tools might >>> not need adjustment, so long as their interpreter was $MSYS-enabled >>> (e.g. automake -> msys-perl, msys-bash) -- because the script will "see" >>> dos-style paths, so its interpreter better be able to handle them. >>> >>> But unless you restrict yourself to only passing around relative paths >>> (or god forbid, that old "unity mount" idea), any .exe will need to live >>> in one world or the other. Otherwise, how would paths be interpreted? >>> Using which tools' mount table? >>> >>> Naturally from the command line I can compensate: >>> >>> msys$ /c/cygwin/bin/foobar.exe $(/c/cygwin/bin/cygpath.exe -u $(cygpath >>> -d /msys/mount/table/path) ) >>> >>> but yee gods that'd be annoying in any automated setting. >> >> I don't know if this helps but the vague plan is to now have two DLLs >> where before you only had one. You'd still be providing "MSYS" binaries >> which relied on "MSYS.dll" but, under the hood, MSYS.dll would be only a >> small dll which relied on cygwin1.dll for all of the heavy lifting. >> >> You'd still have a normal MSYS distribution and it would still, in theory, >> support everything (with the possible exception of very lax security) that >> the old MSYS did. An MSYS release would consist of MSYS*.dll, cygwin1.dll, >> bash, etc. > > Out of curiosity: why do you insist on having MSYS functionality in a > separate dll, when it could be just part of cygwin1.dll (disableable and > enableable in the same way other Cygwin features are disabled/enabled - > via CYGWIN envvar)? What advantage would that give, that justifies the > increase in implementation complexity (hooking up the dll, etc)? Was > that justified earlier in this thread and i just neglected to read that > far back? Yes, it was mentioned. The idea is to keep the MSYS-specific stuff separate so Cygwin functionality isn't impacted by what MSYS wants. This reduces the complexity of the Cygwin code at least. -- Larry ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: MSYS mode (continue) 2013-07-25 21:31 ` Larry Hall (Cygwin Developers) @ 2013-07-26 1:55 ` Christopher Faylor 2013-07-26 4:03 ` LRN 0 siblings, 1 reply; 52+ messages in thread From: Christopher Faylor @ 2013-07-26 1:55 UTC (permalink / raw) To: cygwin-developers On Thu, Jul 25, 2013 at 05:30:57PM -0400, Larry Hall (Cygwin Developers) wrote: >On 7/25/2013 5:07 PM, LRN wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 26.07.2013 00:53, Christopher Faylor wrote: >>> On Thu, Jul 25, 2013 at 02:20:50PM -0400, Charles Wilson wrote: >>>>> But underlying there's still a normal Cygwin DLL and >>>>> most tools could just be copied verbatim since they don't need this >>>>> extra functionality. >>>> >>>> And that's the bit where I disagree. Sure, some scripting tools might >>>> not need adjustment, so long as their interpreter was $MSYS-enabled >>>> (e.g. automake -> msys-perl, msys-bash) -- because the script will "see" >>>> dos-style paths, so its interpreter better be able to handle them. >>>> >>>> But unless you restrict yourself to only passing around relative paths >>>> (or god forbid, that old "unity mount" idea), any .exe will need to live >>>> in one world or the other. Otherwise, how would paths be interpreted? >>>> Using which tools' mount table? >>>> >>>> Naturally from the command line I can compensate: >>>> >>>> msys$ /c/cygwin/bin/foobar.exe $(/c/cygwin/bin/cygpath.exe -u $(cygpath >>>> -d /msys/mount/table/path) ) >>>> >>>> but yee gods that'd be annoying in any automated setting. >>> >>> I don't know if this helps but the vague plan is to now have two DLLs >>> where before you only had one. You'd still be providing "MSYS" binaries >>> which relied on "MSYS.dll" but, under the hood, MSYS.dll would be only a >>> small dll which relied on cygwin1.dll for all of the heavy lifting. >>> >>> You'd still have a normal MSYS distribution and it would still, in theory, >>> support everything (with the possible exception of very lax security) that >>> the old MSYS did. An MSYS release would consist of MSYS*.dll, cygwin1.dll, >>> bash, etc. >> >> Out of curiosity: why do you insist on having MSYS functionality in a >> separate dll, when it could be just part of cygwin1.dll (disableable and >> enableable in the same way other Cygwin features are disabled/enabled - >> via CYGWIN envvar)? What advantage would that give, that justifies the >> increase in implementation complexity (hooking up the dll, etc)? Was >> that justified earlier in this thread and i just neglected to read that >> far back? > >Yes, it was mentioned. The idea is to keep the MSYS-specific stuff separate >so Cygwin functionality isn't impacted by what MSYS wants. This reduces >the complexity of the Cygwin code at least. Right. Thanks Larry. The bottom line is that we don't want there to be a bunch of "if (is_msys)"'s in the code. We don't want to have to worry about how msys does things. I don't want to have to inspect msys patches, except for requests for a new hook. A hook will be a fast no-op in the pure cygwin cases. There would be very little "implementation complexity". cgf ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: MSYS mode (continue) 2013-07-26 1:55 ` Christopher Faylor @ 2013-07-26 4:03 ` LRN 2013-07-26 5:46 ` Christopher Faylor 0 siblings, 1 reply; 52+ messages in thread From: LRN @ 2013-07-26 4:03 UTC (permalink / raw) To: cygwin-developers [-- Attachment #1: Type: text/plain, Size: 3835 bytes --] -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 26.07.2013 05:55, Christopher Faylor wrote: > On Thu, Jul 25, 2013 at 05:30:57PM -0400, Larry Hall (Cygwin Developers) wrote: >> On 7/25/2013 5:07 PM, LRN wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> On 26.07.2013 00:53, Christopher Faylor wrote: >>>> On Thu, Jul 25, 2013 at 02:20:50PM -0400, Charles Wilson wrote: >>>>>> But underlying there's still a normal Cygwin DLL and >>>>>> most tools could just be copied verbatim since they don't need this >>>>>> extra functionality. >>>>> >>>>> And that's the bit where I disagree. Sure, some scripting tools might >>>>> not need adjustment, so long as their interpreter was $MSYS-enabled >>>>> (e.g. automake -> msys-perl, msys-bash) -- because the script will "see" >>>>> dos-style paths, so its interpreter better be able to handle them. >>>>> >>>>> But unless you restrict yourself to only passing around relative paths >>>>> (or god forbid, that old "unity mount" idea), any .exe will need to live >>>>> in one world or the other. Otherwise, how would paths be interpreted? >>>>> Using which tools' mount table? >>>>> >>>>> Naturally from the command line I can compensate: >>>>> >>>>> msys$ /c/cygwin/bin/foobar.exe $(/c/cygwin/bin/cygpath.exe -u $(cygpath >>>>> -d /msys/mount/table/path) ) >>>>> >>>>> but yee gods that'd be annoying in any automated setting. >>>> >>>> I don't know if this helps but the vague plan is to now have two DLLs >>>> where before you only had one. You'd still be providing "MSYS" binaries >>>> which relied on "MSYS.dll" but, under the hood, MSYS.dll would be only a >>>> small dll which relied on cygwin1.dll for all of the heavy lifting. >>>> >>>> You'd still have a normal MSYS distribution and it would still, in theory, >>>> support everything (with the possible exception of very lax security) that >>>> the old MSYS did. An MSYS release would consist of MSYS*.dll, cygwin1.dll, >>>> bash, etc. >>> >>> Out of curiosity: why do you insist on having MSYS functionality in a >>> separate dll, when it could be just part of cygwin1.dll (disableable and >>> enableable in the same way other Cygwin features are disabled/enabled - >>> via CYGWIN envvar)? What advantage would that give, that justifies the >>> increase in implementation complexity (hooking up the dll, etc)? Was >>> that justified earlier in this thread and i just neglected to read that >>> far back? >> >> Yes, it was mentioned. The idea is to keep the MSYS-specific stuff separate >> so Cygwin functionality isn't impacted by what MSYS wants. This reduces >> the complexity of the Cygwin code at least. > > Right. Thanks Larry. > > The bottom line is that we don't want there to be a bunch of "if > (is_msys)"'s in the code. We don't want to have to worry about how msys > does things. I don't want to have to inspect msys patches, except for > requests for a new hook. > > A hook will be a fast no-op in the pure cygwin cases. There would be > very little "implementation complexity". OK. I've attached the patch that alexey gave me recently, if pointless cygwin->msys renames are removed from msys2, this is what msys2 boils down to. Please specify how the hooks will look, now that you know which points of the code need to be hooked up. - -- O< ascii ribbon - stop html email! - www.asciiribbon.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) iQEcBAEBAgAGBQJR8fTZAAoJEOs4Jb6SI2CwoU0H/1YQSxBz9NisJcCj6wUfo07u yE7uqieB4sxv3dEJAigBHNVYMbEEqDehY/TVFqMoRIw9SXBSpBWFMla49w8aRHeA 7JUP3+5/cyQYJHXSLBMZBAxdYmSe61PrZVXaH/fMHVuuv31457/He/GaNrM+mos+ q6QqvB2S+lVDIBfZALPyYdS+VZ7jgDVKC2Eb5oFyrEV3EOBnkOFu/PjLUzm1ewMH X5bn9HHiqHKHUxsss2LBbtZLO75ptLdFPBF+TY83H1TJDHDb3byFGSSGtXhB9+iB q0j6fhXEqGT+0nCaXangHtt02zx9fvUMLb6bPJ36JTrhv3F/nxEPOjnUtq7Hzm0= =DGCV -----END PGP SIGNATURE----- [-- Attachment #2: cygwin-msys.patch --] [-- Type: text/plain, Size: 26590 bytes --] diff -Naur curr_cyg/winsup/cygwin/environ.cc curr_msys/winsup/cygwin/environ.cc --- curr_cyg/winsup/cygwin/environ.cc 2013-07-21 23:30:19.000000000 +0400 +++ curr_msys/winsup/cygwin/environ.cc 2013-07-22 06:34:55.000000000 +0400 @@ -999,7 +1021,7 @@ prior to placing them in the string. */ char ** __reg3 build_env (const char * const *envp, PWCHAR &envblock, int &envc, - bool no_envblock) + bool no_envblock, bool keep_posix) { int len, n; const char * const *srcp; @@ -1024,6 +1046,9 @@ for (srcp = envp, dstp = newenv, pass_dstp = pass_env; *srcp; srcp++) { bool calc_tl = !no_envblock; + /* Don't pass timezone environment to non-msys applications */ + if (!keep_posix && ascii_strncasematch(*srcp, "TZ=", 3)) + goto next1; /* Look for entries that require special attention */ for (unsigned i = 0; i < SPENVS_SIZE; i++) if (!saw_spenv[i] && (*dstp = spenvs[i].retrieve (no_envblock, *srcp))) @@ -1104,6 +1129,13 @@ conv = getwinenv (*srcp, rest, &temp); if (conv) p = conv->native; /* Use win32 path */ + else if (!keep_posix) { + char *win_arg = arg_heuristic(*srcp); + debug_printf("WIN32_PATH is %s", win_arg); + p = cstrdup1(win_arg); + if (win_arg != *srcp) + free (win_arg); + } else p = *srcp; /* Don't worry about it */ diff -Naur curr_cyg/winsup/cygwin/environ.h curr_msys/winsup/cygwin/environ.h --- curr_cyg/winsup/cygwin/environ.h 2013-07-21 23:30:19.000000000 +0400 +++ curr_msys/winsup/cygwin/environ.h 2013-07-22 06:34:55.000000000 +0400 @@ -45,6 +45,6 @@ extern "C" char __stdcall **cur_environ (); #endif char ** __reg3 build_env (const char * const *envp, PWCHAR &envblock, - int &envc, bool need_envblock); + int &envc, bool need_envblock, bool keep_posix); #define ENV_CVT -1 diff -Naur curr_cyg/winsup/cygwin/external.cc curr_msys/winsup/cygwin/external.cc --- curr_cyg/winsup/cygwin/external.cc 2013-07-21 23:30:19.000000000 +0400 +++ curr_msys/winsup/cygwin/external.cc 2013-07-22 06:34:55.000000000 +0400 @@ -137,7 +137,7 @@ { int unused_envc; PWCHAR envblock = NULL; - char **envp = build_env (env ?: cur_environ (), envblock, unused_envc, false); + char **envp = build_env (env ?: cur_environ (), envblock, unused_envc, false, true); PWCHAR p = envblock; if (envp) diff -Naur curr_cyg/winsup/cygwin/globals.cc curr_msys/winsup/cygwin/globals.cc --- curr_cyg/winsup/cygwin/globals.cc 2013-07-21 23:30:19.000000000 +0400 +++ curr_msys/winsup/cygwin/globals.cc 2013-07-22 06:34:55.000000000 +0400 @@ -68,7 +68,7 @@ /* Some CYGWIN environment variable variables. */ bool allow_glob = true; bool ignore_case_with_glob = false; -bool dos_file_warning = true; +bool dos_file_warning = false; winsym_t allow_winsymlinks = WSYM_sysfile; bool reset_com = false; bool pipe_byte = false; diff -Naur curr_cyg/winsup/cygwin/include/sys/cygwin.h curr_msys/winsup/cygwin/include/sys/cygwin.h --- curr_cyg/winsup/cygwin/include/sys/cygwin.h 2013-07-21 23:30:19.000000000 +0400 +++ curr_msys/winsup/cygwin/include/sys/cygwin.h 2013-07-22 06:34:55.000000000 +0400 @@ -81,6 +81,8 @@ to one of the above values, or to ENOMEM if malloc fails. */ extern void *cygwin_create_path (cygwin_conv_path_t what, const void *from); +extern char * arg_heuristic (char const * const); + extern pid_t cygwin_winpid_to_pid (int); extern int cygwin_posix_path_list_p (const char *); extern void cygwin_split_path (const char *, char *, char *); diff -Naur curr_cyg/winsup/cygwin/mount.cc curr_msys/winsup/cygwin/mount.cc --- curr_cyg/winsup/cygwin/mount.cc 2013-07-21 23:30:19.000000000 +0400 +++ curr_msys/winsup/cygwin/mount.cc 2013-07-22 06:34:55.000000000 +0400 @@ -458,13 +456,13 @@ sys_wcstombs (native_root, PATH_MAX, root); assert (*native_root != '\0'); if (add_item (native_root, "/", - MOUNT_SYSTEM | MOUNT_BINARY | MOUNT_IMMUTABLE | MOUNT_AUTOMATIC) + MOUNT_SYSTEM | MOUNT_BINARY | MOUNT_IMMUTABLE | MOUNT_AUTOMATIC | MOUNT_NOACL) < 0) api_fatal ("add_item (\"%s\", \"/\", ...) failed, errno %d", native_root, errno); /* Create a default cygdrive entry. Note that this is a user entry. This allows to override it with mount, unless the sysadmin created a cygdrive entry in /etc/fstab. */ - cygdrive_flags = MOUNT_BINARY | MOUNT_NOPOSIX | MOUNT_CYGDRIVE; + cygdrive_flags = MOUNT_BINARY | MOUNT_NOPOSIX | MOUNT_CYGDRIVE | MOUNT_NOACL; strcpy (cygdrive, CYGWIN_INFO_CYGDRIVE_DEFAULT_PREFIX "/"); cygdrive_len = strlen (cygdrive); } @@ -1125,8 +1117,17 @@ if (!*c) return true; cend = find_ws (c); - *cend = '\0'; posix_path = conv_fstab_spaces (c); + if (!*cend) + { + unsigned mount_flags = MOUNT_SYSTEM | MOUNT_BINARY | MOUNT_NOPOSIX | MOUNT_NOACL; + + int res = mount_table->add_item (native_path, posix_path, mount_flags); + if (res && get_errno () == EMFILE) + return false; + return true; + } + *cend = '\0'; /* Third field: FS type. */ c = skip_ws (cend + 1); if (!*c) diff -Naur curr_cyg/winsup/cygwin/path.cc curr_msys/winsup/cygwin/path.cc --- curr_cyg/winsup/cygwin/path.cc 2013-07-21 23:30:19.000000000 +0400 +++ curr_msys/winsup/cygwin/path.cc 2013-07-22 06:34:55.000000000 +0400 @@ -1487,6 +1486,86 @@ /********************** Symbolic Link Support **************************/ +/* + Create a deep copy of src as dst, while avoiding descending in origpath. +*/ +static int +recursiveCopy (char * src, char * dst, const char * origpath) +{ + WIN32_FIND_DATA dHfile; + HANDLE dH; + BOOL findfiles; + int srcpos = strlen (src); + int dstpos = strlen (dst); + int res = -1; + + debug_printf("recursiveCopy (%s, %s)", src, dst); + + /* Create the destination directory */ + if (!CreateDirectoryEx (src, dst, NULL)) + { + debug_printf("CreateDirectoryEx(%s, %s, 0) failed", src, dst); + __seterrno (); + goto done; + } + /* Descend into the source directory */ + if (srcpos + 2 >= MAX_PATH || dstpos + 1 >= MAX_PATH) + { + set_errno (ENAMETOOLONG); + goto done; + } + strcat (src, "\\*"); + strcat (dst, "\\"); + dH = FindFirstFile (src, &dHfile); + debug_printf("dHfile(1): %s", dHfile.cFileName); + findfiles = FindNextFile (dH, &dHfile); + debug_printf("dHfile(2): %s", dHfile.cFileName); + findfiles = FindNextFile (dH, &dHfile); + while (findfiles) + { + /* Append the directory item filename to both source and destination */ + int filelen = strlen (dHfile.cFileName); + debug_printf("dHfile(3): %s", dHfile.cFileName); + if (srcpos + 1 + filelen >= MAX_PATH || + dstpos + 1 + filelen >= MAX_PATH) + { + set_errno (ENAMETOOLONG); + goto done; + } + strcpy (&src[srcpos+1], dHfile.cFileName); + strcpy (&dst[dstpos+1], dHfile.cFileName); + debug_printf("%s -> %s", src, dst); + if (dHfile.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY) + { + /* Recurse into the child directory */ + debug_printf("%s <-> %s", src, origpath); + if (strcmp (src, origpath)) // avoids endless recursion + if (recursiveCopy (src, dst, origpath)) + goto done; + } + else + { + /* Just copy the file */ + if (!CopyFile (src, dst, FALSE)) + { + __seterrno (); + goto done; + } + } + findfiles = FindNextFile (dH, &dHfile); + } + if (GetLastError() != ERROR_NO_MORE_FILES) + { + __seterrno (); + goto done; + } + res = 0; + +done: + + return res; +} + /* Create a symlink from FROMPATH to TOPATH. */ extern "C" int @@ -1891,6 +1970,73 @@ } else { + path_conv src_path; + src_path.check (oldpath, PC_SYM_NOFOLLOW, stat_suffixes); + if (src_path.error) + { + set_errno (src_path.error); + goto done; + } + if (!src_path.isdevice () && !src_path.is_fs_special ()) + { + /* MSYS copy file instead make symlink */ + + char * real_oldpath; + if (isabspath (oldpath)) + strcpy (real_oldpath = tp.c_get (), oldpath); + else + /* Find the real source path, relative + to the directory of the destination */ + { + /* Determine the character position of the last path component */ + int pos = strlen (newpath); + while (--pos >= 0) + if (isdirsep (newpath[pos])) + break; + /* Append the source path to the directory + component of the destination */ + if (pos+1+strlen(oldpath) >= MAX_PATH) + { + set_errno(ENAMETOOLONG); + goto done; + } + strcpy (real_oldpath = tp.c_get (), newpath); + strcpy (&real_oldpath[pos+1], oldpath); + } + + /* As a MSYS limitation, the source path must exist. */ + path_conv win32_oldpath; + win32_oldpath.check (real_oldpath, PC_SYM_NOFOLLOW, stat_suffixes); + if (!win32_oldpath.exists ()) + { + set_errno (ENOENT); + goto done; + } + + char *w_newpath; + char *w_oldpath; + stpcpy (w_newpath = tp.c_get (), win32_newpath.get_win32()); + stpcpy (w_oldpath = tp.c_get (), win32_oldpath.get_win32()); + if (win32_oldpath.isdir()) + { + char *origpath; + strcpy (origpath = tp.c_get (), w_oldpath); + res = recursiveCopy (w_oldpath, w_newpath, origpath); + } + else + { + if (!CopyFile (w_oldpath, w_newpath, FALSE)) + { + __seterrno (); + } + else + { + res = 0; + } + } + goto done; + } + /* Default technique creating a symlink. */ buf = tp.t_get (); cp = stpcpy (buf, SYMLINK_COOKIE); @@ -3182,6 +3328,488 @@ return res; } +static bool +isabswinpath (const char * path) +{ + int plen = strlen (path); + bool p0alpha = isalpha (path[0]) != 0; + bool p1colon = (plen > 1 && path[1] == ':'); + bool rval = + ( ((plen == 2) && p0alpha && p1colon) + || ( (plen > 2) + && p0alpha + && p1colon + && (strchr (&path[2], ':') == (char *)NULL) + ) + || ( plen > 3 + && path[0] == '\\' + && path[1] == '\\' + && path[3] == '\\' + ) + ); + return rval; +} + +static char * +ScrubRetpath (char * const retpath) +{ + char * sspath = (char *)retpath; + // + // Check for null path because Win32 doesn't like them. + // I.E.: Path lists of c:/foo;;c:/bar need changed to + // c:/foo;c:/bar. + // + // This need be executed only if we actually converted the path. + // + while (*sspath) + { + if (*sspath == ';' && sspath[1] == ';') + for (char *i = sspath; *i; i++) + *i = *(i + 1); + else + sspath++; + } + if (*(sspath - 1) == ';') + *(sspath - 1) = '\0'; + + // + // If we modified the path then convert all / to \ if we have a path list + // else convert all \ to /. + // + if ((strchr (retpath, ';'))) + { + backslashify (retpath, retpath, 0); + } else + { + slashify (retpath, retpath, 0); + } + debug_printf("returning: %s", retpath); + return retpath; +} + +// +// The returned pointer should be freed with free unless, +// as it turns out, it is equal to the input pointer. +// +extern "C" char * +arg_heuristic (char const * const arg) +{ + + int arglen = (arg ? strlen (arg): 0); + + if (arglen == 0) + { + char *retpath = (char *)malloc (sizeof (char)); + memset (retpath, 0, sizeof (char)); + return retpath; + } + + debug_printf("Input value: (%s)", arg); + + // + // copy of the path string that we can overwrite + // + char *spath = (char *)alloca (arglen + 1); + memcpy (spath, arg, arglen + 1); + + char * sspath; + + // + // retpath contains the converted path string to be returned + // + char *retpath = (char *)malloc(((MAX_PATH - arglen) > 0) ? + MAX_PATH : arglen + MAX_PATH); + memset (retpath, 0, MAX_PATH); + int retpath_len = 0; + int retpath_buflen = MAX_PATH; + +#define retpathcat(retstr) \ + retpath_len += strlen(retstr); \ + if (retpath_buflen <= retpath_len) \ + { \ + retpath_buflen = ((retpath_buflen * 2 <= retpath_len) ? \ + retpath_len + 1 : retpath_buflen * 2); \ + retpath = (char *)realloc (retpath, retpath_buflen); \ + } \ + strcat (retpath, retstr); + +#define retpathcpy(retstr) \ + retpath_len = strlen (retstr); \ + *retpath = '\0'; \ + if (retpath_buflen <= retpath_len ) \ + { \ + retpath_buflen = ((retpath_buflen * 2 <= retpath_len) ? \ + retpath_len + 1 : retpath_buflen * 2); \ + retpath = (char *)realloc (retpath, retpath_buflen); \ + } \ + strcpy (retpath, retstr); + + // + // Just return win32 paths and path lists. + // + if (isabswinpath (arg) + || (strchr (arg, ';') > 0) + ) + { + debug_printf("returning Win32 absolute path: %s", arg); + return ((char *)arg); + } + // + // Multiple forward slashes are treated special, + // Remove one and return for the form of //foo or ///bar + // but just return for the form of //server/share. + // + else if (arg[0] == '/' && arg[1] == '/') + { + int tidx = 2; + while (spath[tidx] && spath[tidx] == '/') + tidx++; + if (strchr (&spath[tidx], '/')) + { + retpathcpy (spath); + } + else + { + retpathcpy (&spath[1]); + } + return ScrubRetpath (retpath); + } + // + // special case confusion elimination + // Translate a path that looks similar to /c: to c:/. + // + else if (arg[0] == '/' && isabswinpath (arg + 1)) + { + retpathcpy (&arg[1]); + return ScrubRetpath (retpath); + } + // + // Check for variable set. + // + else if ((sspath = strchr(spath, '=')) && isalpha (spath[0])) + { + if (isabswinpath (sspath + 1)) { + debug_printf("returning: %s", arg); + return (char *)arg; + } + char *swin32_path = arg_heuristic(sspath + 1); + if (swin32_path == (sspath + 1)) { + debug_printf("returning: %s", arg); + return (char *)arg; + } + *sspath = '\0'; + retpathcpy (spath); + retpathcat ("="); + retpathcat (swin32_path); + free (swin32_path); + return ScrubRetpath (retpath); + } + // + // Check for paths after commas, if string begins with a '-' character. + // + else if ((sspath = strchr(spath, ',')) && spath[0] == '-') + { + if (isabswinpath (sspath + 1)) { + debug_printf("returning: %s", arg); + return (char *)arg; + } + char *swin32_path = arg_heuristic(sspath + 1); + if (swin32_path == (sspath + 1)) { + debug_printf("returning: %s", arg); + return (char *)arg; + } + *sspath = '\0'; + retpathcpy (spath); + retpathcat (","); + retpathcat (swin32_path); + free (swin32_path); + return ScrubRetpath (retpath); + } + // + // Check for POSIX path lists. + // But we have to allow processing of quoted strings and switches first + // which uses recursion so this code will be seen again. + // + else + { + sspath = strchr (spath, ':'); + // + // Prevent http://some.string/ from being modified. + // + if ((sspath > 0 && strlen (sspath) > 2) + && (sspath[1] == '/') + && (sspath[2] == '/') + ) + { + debug_printf("returning: %s", arg); + return ((char *)arg); + } + else + if ((sspath > 0) + && (strchr (spath, '/') > 0) + // + // Prevent strings beginning with -, ", ', or @ from being processed, + // remember that this is a recursive routine. + // + && (strchr ("-\"\'@", spath[0]) == 0) + // + // Prevent ``foo:echo /bar/baz'' from being considered a path list. + // + && (strlen (sspath) > 1 && strchr (":./", sspath[1]) > 0) + ) + { + // + // Yes, convert to Win32 path list. + // + while (sspath) + { + *sspath = '\0'; + char *swin32_path = arg_heuristic (spath); + // + // Just ignore sret; swin32_path has the value we need. + // + retpathcat (swin32_path); + if (swin32_path != spath) + free (swin32_path); + spath = sspath + 1; + sspath = strchr (spath, ':'); + retpathcat (";"); + // + // Handle the last path in the list. + // + if (!sspath) + { + char *swin32_path = arg_heuristic (spath); + retpathcat (swin32_path); + if (swin32_path != spath) + free (swin32_path); + } + } + return ScrubRetpath (retpath); + } + else + { + switch (spath[0]) + { + case '/': + // + // Just a normal POSIX path. + // + { + // + // Convert only up to a ".." path component, and + // keep all what follows as is. + // + sspath = strstr (spath, "/.."); + if (sspath) + { + *sspath = '\0'; + char *swin32_path = arg_heuristic (spath); + if (swin32_path == spath) + { + debug_printf("returning: %s", arg); + return ((char *)arg); + } + retpathcpy (swin32_path); + retpathcat ("/"); + retpathcat (sspath+1); + free (swin32_path); + return ScrubRetpath (retpath); + } + if (strcmp(spath, "/dev/null") == 0) + { + retpathcpy("nul"); + return ScrubRetpath (retpath); + } + path_conv p (spath, 0); + if (p.error) + { + set_errno(p.error); + debug_printf("returning: %s", arg); + return ((char *)arg); + } + retpathcpy (p.get_win32 ()); + return ScrubRetpath (retpath); + } + case '-': + // + // here we check for POSIX paths as attributes to a POSIX switch. + // + sspath = strchr (spath, '='); + if (sspath) + { + // + // just use recursion if we find a set variable token. + // + *sspath = '\0'; + if (isabswinpath (sspath + 1)) { + debug_printf("returning: %s", arg); + return (char *)arg; + } + char *swin32_path = arg_heuristic(sspath + 1); + if (swin32_path == sspath + 1) + { + debug_printf("returning: %s", arg); + return ((char *)arg); + } + retpathcpy (spath); + retpathcat ("="); + retpathcat (swin32_path); + free (swin32_path); + return ScrubRetpath (retpath); + } + else + { + // + // Check for single letter option with a + // path argument attached, eg -I/include */ + // + if (spath[1] && spath[2] == '/') + { + debug_printf("spath = %s", spath); + sspath = spath + 2; + char *swin32_path = arg_heuristic (sspath); + if (swin32_path == sspath) + { + debug_printf("returning: %s", arg); + return ((char *)arg); + } + sspath = (char *)spath; + sspath++; + sspath++; + *sspath = '\0'; + retpathcpy (spath); + *sspath = '/'; + retpathcat (swin32_path); + free (swin32_path); + return ScrubRetpath (retpath); + } + else + { + debug_printf("returning: %s", arg); + return ((char *)arg); + } + } + break; + case '@': + // + // here we check for POSIX paths as attributes to a response + // file argument (@file). This is specifically to support + // MinGW binutils and gcc. + // + sspath = spath + 1; + if (isabswinpath (sspath)) + { + debug_printf("returning: %s", arg); + return (char *)arg; + } + if (spath[1] == '/') + { + debug_printf("spath = %s", spath); + char *swin32_path = arg_heuristic (sspath); + if (swin32_path == sspath) + { + debug_printf("returning: %s", arg); + return ((char *)arg); + } + sspath = (char *)spath; + sspath++; + *sspath = '\0'; + retpathcpy (spath); + *sspath = '/'; + retpathcat (swin32_path); + free (swin32_path); + return ScrubRetpath (retpath); + } + else + { + debug_printf("returning: %s", arg); + return ((char *)arg); + } + break; + case '"': + // + // Handle a double quote case. + // + debug_printf ("spath: %s", spath); + if (spath[1] == '/') + { + retpathcpy ("\""); + char *tpath = strchr(&spath[1], '"'); + if (tpath) + *tpath = (char)NULL; + char *swin32_path = arg_heuristic (&spath[1]); + if (swin32_path == &spath[1]) + { + debug_printf("returning: %s", arg); + return ((char *)arg); + } + retpathcat (swin32_path); + free (swin32_path); + if (tpath) + retpathcat ("\""); + return ScrubRetpath (retpath); + } + debug_printf("returning: %s", arg); + return ((char *)arg); + case '\'': + // + // Handle a single quote case. + // + debug_printf ("spath: %s", spath); + if (spath[1] == '/') + { + retpathcpy ("'"); + char *tpath = strchr(&spath[1], '\''); + if (tpath) + *tpath = (char)NULL; + char *swin32_path = arg_heuristic (&spath[1]); + if (swin32_path == &spath[1]) + { + debug_printf("returning: %s", arg); + return ((char *)arg); + } + retpathcat (swin32_path); + free (swin32_path); + if (tpath) + retpathcat ("'"); + return ScrubRetpath (retpath); + } + debug_printf("returning: %s", arg); + return ((char *)arg); + default: + // + // This takes care of variable_foo=/bar/baz + // + if ((sspath = strchr(spath, '=')) && (sspath[1] == '/')) + { + sspath[1] = '\0'; + retpathcpy (spath); + sspath[1] = '/'; + char *swin32_path = arg_heuristic (&sspath[1]); + if (swin32_path == &sspath[1]) + { + debug_printf("returning: %s", arg); + return ((char *)arg); + } + retpathcat (swin32_path); + free (swin32_path); + return ScrubRetpath (retpath); + } + // + // Oh well, nothing special found, set win32_path same as path. + // + debug_printf("returning: %s", arg); + return ((char *)arg); + } + } + } + // I should not get to this point. + assert (false); + debug_printf("returning: %s", arg); + return ScrubRetpath (retpath); +} + /******************** Exported Path Routines *********************/ /* Cover functions to the path conversion routines. @@ -4572,6 +5200,15 @@ else tocopy = posix; + // Make sure that we have forward slashes always. + char *pstr; + pstr = strchr(tocopy, '\\'); + while (pstr) + { + *pstr = '/'; + pstr = strchr(pstr, '\\'); + } + debug_printf ("posix %s", posix); if (strlen (tocopy) >= ulen) { diff -Naur curr_cyg/winsup/cygwin/spawn.cc curr_msys/winsup/cygwin/spawn.cc --- curr_cyg/winsup/cygwin/spawn.cc 2013-07-21 23:30:19.000000000 +0400 +++ curr_msys/winsup/cygwin/spawn.cc 2013-07-22 06:34:55.000000000 +0400 @@ -407,12 +407,26 @@ moreinfo->argc = newargv.argc; moreinfo->argv = newargv; } - else if (!cmd.fromargv (newargv, real_path.get_win32 (), + else + { + for (int i = 0; i < newargv.argc; i++) + { + //convert argv to win32 + int newargvlen = strlen (newargv[i]); + char *tmpbuf = (char *)malloc (newargvlen + 1); + memcpy (tmpbuf, newargv[i], newargvlen + 1); + tmpbuf = arg_heuristic(tmpbuf); + debug_printf("newargv[%d] = %s", i, newargv[i]); + newargv.replace (i, tmpbuf); + free (tmpbuf); + } + if (!cmd.fromargv (newargv, real_path.get_win32 (), real_path.iscygexec ())) - { - res = -1; - goto out; - } + { + res = -1; + goto out; + } + } if (mode != _P_OVERLAY || !real_path.iscygexec () @@ -537,11 +551,11 @@ cygbench ("spawn-worker"); - if (!real_path.iscygexec()) + if (!real_path.iscygexec ()) ::cygheap->fdtab.set_file_pointers_for_exec (); moreinfo->envp = build_env (envp, envblock, moreinfo->envc, - real_path.iscygexec ()); + real_path.iscygexec (), real_path.iscygexec ()); if (!moreinfo->envp || !envblock) { set_errno (E2BIG); diff -Naur curr_cyg/winsup/cygwin/uname.cc curr_msys/winsup/cygwin/uname.cc --- curr_cyg/winsup/cygwin/uname.cc 2013-07-21 23:30:19.000000000 +0400 +++ curr_msys/winsup/cygwin/uname.cc 2013-07-22 06:34:55.000000000 +0400 @@ -29,7 +29,9 @@ char *snp = strstr (cygwin_version.dll_build_date, "SNP"); memset (name, 0, sizeof (*name)); - __small_sprintf (name->sysname, "CYGWIN_%s", wincap.osname ()); + char* msystem = getenv("MSYSTEM"); + const char *msystem_cygwin = "CYGWIN"; + __small_sprintf (name->sysname, "%s_%s", msystem ? msystem : msystem_cygwin, wincap.osname ()); /* Add a hint to the sysname, that we're running under WOW64. This might give an early clue if somebody encounters problems. */ diff -Naur curr_cyg/winsup/cygwin/winf.h curr_msys/winsup/cygwin/winf.h --- curr_cyg/winsup/cygwin/winf.h 2013-07-21 23:30:19.000000000 +0400 +++ curr_msys/winsup/cygwin/winf.h 2013-07-22 06:34:55.000000000 +0400 @@ -53,6 +53,10 @@ calloced = 1; } } + void replace (int i, const char *arg) + { + argv[i] = cstrdup1 (arg); + } void dup_all () { for (int i = calloced; i < argc; i++) @@ -76,6 +80,8 @@ void prepend (const char *, int); void __reg2 finish (bool); bool __reg3 fromargv(av&, const char *, bool);; + operator char *() {return buf;} + size_t idx() {return ix;} operator size_t () const { return ix + 1; } operator const char * () const { return buf; } operator wchar_t * () ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: MSYS mode (continue) 2013-07-26 4:03 ` LRN @ 2013-07-26 5:46 ` Christopher Faylor 0 siblings, 0 replies; 52+ messages in thread From: Christopher Faylor @ 2013-07-26 5:46 UTC (permalink / raw) To: cygwin-developers On Fri, Jul 26, 2013 at 08:02:45AM +0400, LRN wrote: >Please specify how the hooks will look, now that you know which points >of the code need to be hooked up. Apparently you haven't read any of the past discussion and are just trying to jump into the middle without doing any homework. We are still discussing implementation. That is the whole point of this thread. I did provide a straw man proposal which showed what a hook could look like, however. cgf ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: MSYS mode (continue) 2013-07-25 20:53 ` Christopher Faylor 2013-07-25 21:08 ` LRN @ 2013-07-26 8:15 ` Corinna Vinschen 2013-07-26 15:14 ` Christopher Faylor 2013-07-27 3:07 ` Charles Wilson 1 sibling, 2 replies; 52+ messages in thread From: Corinna Vinschen @ 2013-07-26 8:15 UTC (permalink / raw) To: cygwin-developers On Jul 25 16:53, Christopher Faylor wrote: > On Thu, Jul 25, 2013 at 02:20:50PM -0400, Charles Wilson wrote: > >> But underlying there's still a normal Cygwin DLL and > >> most tools could just be copied verbatim since they don't need this > >> extra functionality. > > > >And that's the bit where I disagree. Sure, some scripting tools might > >not need adjustment, so long as their interpreter was $MSYS-enabled > >(e.g. automake -> msys-perl, msys-bash) -- because the script will "see" > >dos-style paths, so its interpreter better be able to handle them. > > > >But unless you restrict yourself to only passing around relative paths > >(or god forbid, that old "unity mount" idea), any .exe will need to live > >in one world or the other. Otherwise, how would paths be interpreted? > >Using which tools' mount table? > > > >Naturally from the command line I can compensate: > > > >msys$ /c/cygwin/bin/foobar.exe $(/c/cygwin/bin/cygpath.exe -u $(cygpath > >-d /msys/mount/table/path) ) > > > >but yee gods that'd be annoying in any automated setting. > > I don't know if this helps but the vague plan is to now have two DLLs > where before you only had one. You'd still be providing "MSYS" binaries > which relied on "MSYS.dll" but, under the hood, MSYS.dll would be only a > small dll which relied on cygwin1.dll for all of the heavy lifting. > > You'd still have a normal MSYS distribution and it would still, in theory, > support everything (with the possible exception of very lax security) that > the old MSYS did. An MSYS release would consist of MSYS*.dll, cygwin1.dll, > bash, etc. Here's where I disagree. I think the executables should *not* rely on MSYS.dll being available. Ideally the executables are linked against the Cygwin DLL and MSYS.dll is called as a side-by-side implementation. So, if MSYS.dll isn't available, they still function as normal Cygwin executables. That's why I proposed the solution(s) in http://cygwin.com/ml/cygwin-developers/2013-07/msg00003.html Assuming you implement it the first way, you get an executable linked against a crt0.o which tries a LoadLibrary("MSYS.dll"). If it fails, the executable does business as usual. It will not fail, because there's still the Cygwin DLL. If LoadLib worked, crt0 calls GetProcAddress("__msys_hook") and then __msys_hook(). __msys_hook collects the hook function pointers and sends them to the CYgwin DLL via a call to cygwin_internal(CW_HOOK, &hook_list). Voila, the hooks are set up, we're in MSYS mode. Another alternative would be if the Cygwin DLL itself had a switch to load the MSYS dll (export CYGWIN=MSYS ;)). This would allows MSYS mode even with completely unchanged executables. > I don't think anyone was proposing seamless interoperation between MSYS > and cygwin. Yes, I honestly think this would be possible and desirable. MSYS is just a tiny change for a specific task in comparison to the default Cygwin mode. MSYS would concentrate on this task and the required tools for this task and the rest could be stock Cygwin distro. Btw., this does *not* mean I agree with all changes MSYS is doing. I have a hard time to see the necessity changing the /etc/fstab layout, for instance, since it doesn't add or change anything you can't have with the standard fstab. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: MSYS mode (continue) 2013-07-26 8:15 ` Corinna Vinschen @ 2013-07-26 15:14 ` Christopher Faylor 2013-07-26 15:48 ` LRN 2013-07-26 16:12 ` Corinna Vinschen 2013-07-27 3:07 ` Charles Wilson 1 sibling, 2 replies; 52+ messages in thread From: Christopher Faylor @ 2013-07-26 15:14 UTC (permalink / raw) To: cygwin-developers On Fri, Jul 26, 2013 at 10:15:10AM +0200, Corinna Vinschen wrote: >On Jul 25 16:53, Christopher Faylor wrote: >> On Thu, Jul 25, 2013 at 02:20:50PM -0400, Charles Wilson wrote: >> >> But underlying there's still a normal Cygwin DLL and >> >> most tools could just be copied verbatim since they don't need this >> >> extra functionality. >> > >> >And that's the bit where I disagree. Sure, some scripting tools might >> >not need adjustment, so long as their interpreter was $MSYS-enabled >> >(e.g. automake -> msys-perl, msys-bash) -- because the script will "see" >> >dos-style paths, so its interpreter better be able to handle them. >> > >> >But unless you restrict yourself to only passing around relative paths >> >(or god forbid, that old "unity mount" idea), any .exe will need to live >> >in one world or the other. Otherwise, how would paths be interpreted? >> >Using which tools' mount table? >> > >> >Naturally from the command line I can compensate: >> > >> >msys$ /c/cygwin/bin/foobar.exe $(/c/cygwin/bin/cygpath.exe -u $(cygpath >> >-d /msys/mount/table/path) ) >> > >> >but yee gods that'd be annoying in any automated setting. >> >> I don't know if this helps but the vague plan is to now have two DLLs >> where before you only had one. You'd still be providing "MSYS" binaries >> which relied on "MSYS.dll" but, under the hood, MSYS.dll would be only a >> small dll which relied on cygwin1.dll for all of the heavy lifting. >> >> You'd still have a normal MSYS distribution and it would still, in theory, >> support everything (with the possible exception of very lax security) that >> the old MSYS did. An MSYS release would consist of MSYS*.dll, cygwin1.dll, >> bash, etc. > >Here's where I disagree. I think the executables should *not* rely on >MSYS.dll being available. Ideally the executables are linked against >the Cygwin DLL and MSYS.dll is called as a side-by-side implementation. >So, if MSYS.dll isn't available, they still function as normal Cygwin >executables. That's why I proposed the solution(s) in >http://cygwin.com/ml/cygwin-developers/2013-07/msg00003.html >Assuming you implement it the first way, you get an executable linked >against a crt0.o which tries a LoadLibrary("MSYS.dll"). If it fails, >the executable does business as usual. It will not fail, because >there's still the Cygwin DLL. > >If LoadLib worked, crt0 calls GetProcAddress("__msys_hook") and then >__msys_hook(). __msys_hook collects the hook function pointers and >sends them to the CYgwin DLL via a call to cygwin_internal(CW_HOOK, >&hook_list). Voila, the hooks are set up, we're in MSYS mode. > > >Another alternative would be if the Cygwin DLL itself had a switch to >load the MSYS dll (export CYGWIN=MSYS ;)). This would allows MSYS mode >even with completely unchanged executables. > > >> I don't think anyone was proposing seamless interoperation between MSYS >> and cygwin. > >Yes, I honestly think this would be possible and desirable. MSYS is >just a tiny change for a specific task in comparison to the default >Cygwin mode. MSYS would concentrate on this task and the required tools >for this task and the rest could be stock Cygwin distro. > > >Btw., this does *not* mean I agree with all changes MSYS is doing. I >have a hard time to see the necessity changing the /etc/fstab layout, >for instance, since it doesn't add or change anything you can't have >with the standard fstab. So, you did. I missed the ramifications of that message. I guess that's why Chuck was confused. I'm suggesting something different so we're all confused. This does not address the problem that there are local modifications in some MSYS utilities. This doesn't solve the problem of make understanding c:\foo. Doesn't MSYS bash allow constructs of the form c:\foo without making that c:foo? If so, the DLL isn't going to help there. I don't think that we should be seeing the word "msys" throughout the DLL source code. The hooks could all be just named "cygwin_hook" generic and, maybe we should recognize something like a "CYGWIN=PRELOAD=MSYS.dll". I don't know how the MSYS folks would feel about that however. Having to tell their users that they need to set an environment variable before they do anything seems like it would be a maintenance headache. As far as /etc/fstab is concerned, since they were the first to implement the notion, I would assume that they don't want to have to tell their userbase to change any more than we would want to have to tell every Cygwin user that they have to edit a file to make the next version of Cygwin work correctly. cgf ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: MSYS mode (continue) 2013-07-26 15:14 ` Christopher Faylor @ 2013-07-26 15:48 ` LRN 2013-07-26 16:16 ` Corinna Vinschen 2013-07-26 16:12 ` Corinna Vinschen 1 sibling, 1 reply; 52+ messages in thread From: LRN @ 2013-07-26 15:48 UTC (permalink / raw) To: cygwin-developers -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 26.07.2013 19:14, Christopher Faylor wrote: > On Fri, Jul 26, 2013 at 10:15:10AM +0200, Corinna Vinschen wrote: >> On Jul 25 16:53, Christopher Faylor wrote: >>> On Thu, Jul 25, 2013 at 02:20:50PM -0400, Charles Wilson wrote: >>>>> But underlying there's still a normal Cygwin DLL and >>>>> most tools could just be copied verbatim since they don't need this >>>>> extra functionality. >>>> >>>> And that's the bit where I disagree. Sure, some scripting tools might >>>> not need adjustment, so long as their interpreter was $MSYS-enabled >>>> (e.g. automake -> msys-perl, msys-bash) -- because the script will "see" >>>> dos-style paths, so its interpreter better be able to handle them. >>>> >>>> But unless you restrict yourself to only passing around relative paths >>>> (or god forbid, that old "unity mount" idea), any .exe will need to live >>>> in one world or the other. Otherwise, how would paths be interpreted? >>>> Using which tools' mount table? >>>> >>>> Naturally from the command line I can compensate: >>>> >>>> msys$ /c/cygwin/bin/foobar.exe $(/c/cygwin/bin/cygpath.exe -u $(cygpath >>>> -d /msys/mount/table/path) ) >>>> >>>> but yee gods that'd be annoying in any automated setting. >>> >>> I don't know if this helps but the vague plan is to now have two DLLs >>> where before you only had one. You'd still be providing "MSYS" binaries >>> which relied on "MSYS.dll" but, under the hood, MSYS.dll would be only a >>> small dll which relied on cygwin1.dll for all of the heavy lifting. >>> >>> You'd still have a normal MSYS distribution and it would still, in theory, >>> support everything (with the possible exception of very lax security) that >>> the old MSYS did. An MSYS release would consist of MSYS*.dll, cygwin1.dll, >>> bash, etc. >> >> Here's where I disagree. I think the executables should *not* rely on >> MSYS.dll being available. Ideally the executables are linked against >> the Cygwin DLL and MSYS.dll is called as a side-by-side implementation. >> So, if MSYS.dll isn't available, they still function as normal Cygwin >> executables. That's why I proposed the solution(s) in >> http://cygwin.com/ml/cygwin-developers/2013-07/msg00003.html > > >> Assuming you implement it the first way, you get an executable linked >> against a crt0.o which tries a LoadLibrary("MSYS.dll"). If it fails, >> the executable does business as usual. It will not fail, because >> there's still the Cygwin DLL. >> >> If LoadLib worked, crt0 calls GetProcAddress("__msys_hook") and then >> __msys_hook(). __msys_hook collects the hook function pointers and >> sends them to the CYgwin DLL via a call to cygwin_internal(CW_HOOK, >> &hook_list). Voila, the hooks are set up, we're in MSYS mode. >> >> >> Another alternative would be if the Cygwin DLL itself had a switch to >> load the MSYS dll (export CYGWIN=MSYS ;)). This would allows MSYS mode >> even with completely unchanged executables. >> >> >>> I don't think anyone was proposing seamless interoperation between MSYS >>> and cygwin. >> >> Yes, I honestly think this would be possible and desirable. MSYS is >> just a tiny change for a specific task in comparison to the default >> Cygwin mode. MSYS would concentrate on this task and the required tools >> for this task and the rest could be stock Cygwin distro. >> >> >> Btw., this does *not* mean I agree with all changes MSYS is doing. I >> have a hard time to see the necessity changing the /etc/fstab layout, >> for instance, since it doesn't add or change anything you can't have >> with the standard fstab. > > So, you did. I missed the ramifications of that message. I guess > that's why Chuck was confused. I'm suggesting something different so > we're all confused. > > This does not address the problem that there are local modifications in > some MSYS utilities. This doesn't solve the problem of make > understanding c:\foo. Yep, you need make sure that make is not configured with ac_cv_dos_paths=no. > Doesn't MSYS bash allow constructs of the form > c:\foo without making that c:foo? It doesn't. You have to carefully avoid the use of '\' everywhere (much easier than escaping it). > I don't think that we should be seeing the word "msys" throughout the > DLL source code. The hooks could all be just named "cygwin_hook" > generic and, maybe we should recognize something like a > "CYGWIN=PRELOAD=MSYS.dll". I don't know how the MSYS folks would > feel about that however. Having to tell their users that they need > to set an environment variable before they do anything seems like it > would be a maintenance headache. MSYS actually does require an environment variable to be set. MSYSTEM=MINGW32 or MSYSTEM=MSYS (at least MSYS1 did, if you wanted to use it with MinGW, and MSYS2 does, in its current form). Most users must have MSYSTEM=MINGW32, otherwise their build system type will be misdetected (as MSYSTEM affects the name returned by uname() syscall). In MSYS1 this was done by the msys.bat batch file that was used to launch the shell. > > As far as /etc/fstab is concerned, since they were the first to > implement the notion, I would assume that they don't want to have to > tell their userbase to change any more than we would want to have to > tell every Cygwin user that they have to edit a file to make the > next version of Cygwin work correctly. I wouldn't worry about this too much. MSYS2, being nearly pure Cygwin, may require more elaborate installation procedures than MSYS1 did. These procedures could include an /etc/fstab conversion script, if users upgrade from MSYS1. MSYS1 compatibility might be interesting for some people (for mingw.org - - definitely), but not for everyone. - -- O< ascii ribbon - stop html email! - www.asciiribbon.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) iQEcBAEBAgAGBQJR8po9AAoJEOs4Jb6SI2CwC4sIAKW1+EdYl/OqCQDzfAnGICiw uPhWlOCHnbKzUpK1URGB0DShU99YjI420hSlGwa8vSJss32DHFiLi9xpjBos5diV nm5hc2B8MJ9tF0L0amPfJ+6dfUlwHwApKfiSWSxnZA4Sw+ZbPM3ImqHqAWibFP/3 poY0t0NisBFKsX7wZ8J23/5k4DcscEoXMUFowgatel6VTPxK47sQ1cOa6WmLMJCu p0UUJvoGSsH6eskE1sXgucqkke60niRsWZCB8Qw2bh6Fkzk+J3A+YDjoGf+g58vx vXXcB7G+1h7Wo5IDPbcv8PgQARRwB/0Z6dD1Dde1wF8hqreq0EQZMrA6n8bTmMw= =d1B2 -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: MSYS mode (continue) 2013-07-26 15:48 ` LRN @ 2013-07-26 16:16 ` Corinna Vinschen 0 siblings, 0 replies; 52+ messages in thread From: Corinna Vinschen @ 2013-07-26 16:16 UTC (permalink / raw) To: cygwin-developers On Jul 26 19:48, LRN wrote: > On 26.07.2013 19:14, Christopher Faylor wrote: > > On Fri, Jul 26, 2013 at 10:15:10AM +0200, Corinna Vinschen wrote: > > I don't think that we should be seeing the word "msys" throughout the > > DLL source code. The hooks could all be just named "cygwin_hook" > > generic and, maybe we should recognize something like a > > "CYGWIN=PRELOAD=MSYS.dll". I don't know how the MSYS folks would > > feel about that however. Having to tell their users that they need > > to set an environment variable before they do anything seems like it > > would be a maintenance headache. > MSYS actually does require an environment variable to be set. > MSYSTEM=MINGW32 or MSYSTEM=MSYS (at least MSYS1 did, if you wanted to > use it with MinGW, and MSYS2 does, in its current form). Most users must > have MSYSTEM=MINGW32, otherwise their build system type will be > misdetected (as MSYSTEM affects the name returned by uname() syscall). > > In MSYS1 this was done by the msys.bat batch file that was used to > launch the shell. So that shouldn't be much of a problem. > > As far as /etc/fstab is concerned, since they were the first to > > implement the notion, I would assume that they don't want to have to > > tell their userbase to change any more than we would want to have to > > tell every Cygwin user that they have to edit a file to make the > > next version of Cygwin work correctly. > > I wouldn't worry about this too much. MSYS2, being nearly pure Cygwin, > may require more elaborate installation procedures than MSYS1 did. These > procedures could include an /etc/fstab conversion script, if users > upgrade from MSYS1. > > MSYS1 compatibility might be interesting for some people (for mingw.org > - - definitely), but not for everyone. Wouldn't a generic conversion script be in order then, which also enforces the noacl setting if desired? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: MSYS mode (continue) 2013-07-26 15:14 ` Christopher Faylor 2013-07-26 15:48 ` LRN @ 2013-07-26 16:12 ` Corinna Vinschen 2013-07-26 16:37 ` Christopher Faylor 1 sibling, 1 reply; 52+ messages in thread From: Corinna Vinschen @ 2013-07-26 16:12 UTC (permalink / raw) To: cygwin-developers On Jul 26 11:14, Christopher Faylor wrote: > On Fri, Jul 26, 2013 at 10:15:10AM +0200, Corinna Vinschen wrote: > >On Jul 25 16:53, Christopher Faylor wrote: > >> On Thu, Jul 25, 2013 at 02:20:50PM -0400, Charles Wilson wrote: > >> >> But underlying there's still a normal Cygwin DLL and > >> >> most tools could just be copied verbatim since they don't need this > >> >> extra functionality. > >> > > >> >And that's the bit where I disagree. Sure, some scripting tools might > >> >not need adjustment, so long as their interpreter was $MSYS-enabled > >> >(e.g. automake -> msys-perl, msys-bash) -- because the script will "see" > >> >dos-style paths, so its interpreter better be able to handle them. > >> > > >> >But unless you restrict yourself to only passing around relative paths > >> >(or god forbid, that old "unity mount" idea), any .exe will need to live > >> >in one world or the other. Otherwise, how would paths be interpreted? > >> >Using which tools' mount table? > >> > > >> >Naturally from the command line I can compensate: > >> > > >> >msys$ /c/cygwin/bin/foobar.exe $(/c/cygwin/bin/cygpath.exe -u $(cygpath > >> >-d /msys/mount/table/path) ) > >> > > >> >but yee gods that'd be annoying in any automated setting. > >> > >> I don't know if this helps but the vague plan is to now have two DLLs > >> where before you only had one. You'd still be providing "MSYS" binaries > >> which relied on "MSYS.dll" but, under the hood, MSYS.dll would be only a > >> small dll which relied on cygwin1.dll for all of the heavy lifting. > >> > >> You'd still have a normal MSYS distribution and it would still, in theory, > >> support everything (with the possible exception of very lax security) that > >> the old MSYS did. An MSYS release would consist of MSYS*.dll, cygwin1.dll, > >> bash, etc. > > > >Here's where I disagree. I think the executables should *not* rely on > >MSYS.dll being available. Ideally the executables are linked against > >the Cygwin DLL and MSYS.dll is called as a side-by-side implementation. > >So, if MSYS.dll isn't available, they still function as normal Cygwin > >executables. That's why I proposed the solution(s) in > >http://cygwin.com/ml/cygwin-developers/2013-07/msg00003.html > > > >Assuming you implement it the first way, you get an executable linked > >against a crt0.o which tries a LoadLibrary("MSYS.dll"). If it fails, > >the executable does business as usual. It will not fail, because > >there's still the Cygwin DLL. > > > >If LoadLib worked, crt0 calls GetProcAddress("__msys_hook") and then > >__msys_hook(). __msys_hook collects the hook function pointers and > >sends them to the CYgwin DLL via a call to cygwin_internal(CW_HOOK, > >&hook_list). Voila, the hooks are set up, we're in MSYS mode. > > > > > >Another alternative would be if the Cygwin DLL itself had a switch to > >load the MSYS dll (export CYGWIN=MSYS ;)). This would allows MSYS mode > >even with completely unchanged executables. > > > > > >> I don't think anyone was proposing seamless interoperation between MSYS > >> and cygwin. > > > >Yes, I honestly think this would be possible and desirable. MSYS is > >just a tiny change for a specific task in comparison to the default > >Cygwin mode. MSYS would concentrate on this task and the required tools > >for this task and the rest could be stock Cygwin distro. > > > > > >Btw., this does *not* mean I agree with all changes MSYS is doing. I > >have a hard time to see the necessity changing the /etc/fstab layout, > >for instance, since it doesn't add or change anything you can't have > >with the standard fstab. > > So, you did. I missed the ramifications of that message. I guess > that's why Chuck was confused. I'm suggesting something different so > we're all confused. > > This does not address the problem that there are local modifications in > some MSYS utilities. This doesn't solve the problem of make > understanding c:\foo. Doesn't MSYS bash allow constructs of the form > c:\foo without making that c:foo? If so, the DLL isn't going to help > there. That's what I talked about in my next to last paragraph. As far as I'm concerned, MSYS would be a DLL tweaking the behaviour of Cygwin via the hooks, *plus* a set of tools specificially tweaked where necessary for what it's supposed to do. Make is one example, bash another, gcc would target mingw32 by default, stuff like that. Still, that doesn't mean that every tool has to be tweaked. Most tools would work OOTB. > I don't think that we should be seeing the word "msys" throughout the > DLL source code. The hooks could all be just named "cygwin_hook" > generic Actually, I'd prefer to have only a single foreign environment using the Cygwin DLL, not a whole bunch. This implies that I could live with a single occurence of the work "MSYS" in the Cygwin code. > and, maybe we should recognize something like a > "CYGWIN=PRELOAD=MSYS.dll". I don't know how the MSYS folks would > feel about that however. Having to tell their users that they need > to set an environment variable before they do anything seems like it > would be a maintenance headache. I don't know if that's a problem for them, but this reminds me... maybe we can use the LD_PRELOAD mechanism in hookapi.cc for that? > As far as /etc/fstab is concerned, since they were the first to > implement the notion, I would assume that they don't want to have to > tell their userbase to change any more than we would want to have to > tell every Cygwin user that they have to edit a file to make the > next version of Cygwin work correctly. Backward compatibility? What a weird concept :) Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: MSYS mode (continue) 2013-07-26 16:12 ` Corinna Vinschen @ 2013-07-26 16:37 ` Christopher Faylor 2013-07-26 16:45 ` Daniel Colascione 2013-07-26 16:47 ` Corinna Vinschen 0 siblings, 2 replies; 52+ messages in thread From: Christopher Faylor @ 2013-07-26 16:37 UTC (permalink / raw) To: cygwin-developers On Fri, Jul 26, 2013 at 06:12:05PM +0200, Corinna Vinschen wrote: >I don't know if that's a problem for them, but this reminds me... maybe >we can use the LD_PRELOAD mechanism in hookapi.cc for that? I was thinking that we'd use something like that (re my use of PRELOAD and your use of CW_HOOK) but, you're right. Someone could potentially implement MSYS.dll via LD_PRELOAD: LD_PRELOAD=msys.dll and then have msys.dll hook the functions that it is interested in using via CW_HOOK. cgf ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: MSYS mode (continue) 2013-07-26 16:37 ` Christopher Faylor @ 2013-07-26 16:45 ` Daniel Colascione 2013-07-26 16:47 ` Corinna Vinschen 1 sibling, 0 replies; 52+ messages in thread From: Daniel Colascione @ 2013-07-26 16:45 UTC (permalink / raw) To: cygwin-developers [-- Attachment #1: Type: text/plain, Size: 860 bytes --] On 7/26/2013 9:37 AM, Christopher Faylor wrote: > On Fri, Jul 26, 2013 at 06:12:05PM +0200, Corinna Vinschen wrote: >> I don't know if that's a problem for them, but this reminds me... maybe >> we can use the LD_PRELOAD mechanism in hookapi.cc for that? > > I was thinking that we'd use something like that (re my use of PRELOAD > and your use of CW_HOOK) but, you're right. Someone could potentially > implement MSYS.dll via LD_PRELOAD: > > LD_PRELOAD=msys.dll > > and then have msys.dll hook the functions that it is interested in using > via CW_HOOK. By the way: can we make LD_PRELOAD hook all modules, not just the main program? If my LD_PRELOADed module hooks write(2) in foo.exe, which uses bar.dll, then write(2) from foo.exe will be intercepted, but write(2) from bar.dll won't be --- only foo.exe's import table is munged. [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 260 bytes --] ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: MSYS mode (continue) 2013-07-26 16:37 ` Christopher Faylor 2013-07-26 16:45 ` Daniel Colascione @ 2013-07-26 16:47 ` Corinna Vinschen 2013-07-26 17:01 ` Christopher Faylor 2013-07-26 23:12 ` Yaakov (Cygwin/X) 1 sibling, 2 replies; 52+ messages in thread From: Corinna Vinschen @ 2013-07-26 16:47 UTC (permalink / raw) To: cygwin-developers On Jul 26 12:37, Christopher Faylor wrote: > On Fri, Jul 26, 2013 at 06:12:05PM +0200, Corinna Vinschen wrote: > >I don't know if that's a problem for them, but this reminds me... maybe > >we can use the LD_PRELOAD mechanism in hookapi.cc for that? > > I was thinking that we'd use something like that (re my use of PRELOAD > and your use of CW_HOOK) but, you're right. Someone could potentially > implement MSYS.dll via LD_PRELOAD: > > LD_PRELOAD=msys.dll > > and then have msys.dll hook the functions that it is interested in using > via CW_HOOK. Two points come to mind. - Does CW_HOOK still work? I had to change a lot of code in hook_or_detect_cygwin to handle big executables and 32 vs. 64 bit, so I have no idea if it still does the righht thing in terms of CW_HOOK. - Isn't CW_HOOK a bit heavy handed for MSYS? MSYS only replaces partial functionality, not entire functions. Something like a CW_HOOK2 which only results in Cygwin calling certain function pointers for minor tweaks could be the result... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: MSYS mode (continue) 2013-07-26 16:47 ` Corinna Vinschen @ 2013-07-26 17:01 ` Christopher Faylor 2013-07-26 17:03 ` Daniel Colascione 2013-07-26 23:12 ` Yaakov (Cygwin/X) 1 sibling, 1 reply; 52+ messages in thread From: Christopher Faylor @ 2013-07-26 17:01 UTC (permalink / raw) To: cygwin-developers On Fri, Jul 26, 2013 at 06:47:16PM +0200, Corinna Vinschen wrote: >On Jul 26 12:37, Christopher Faylor wrote: >> On Fri, Jul 26, 2013 at 06:12:05PM +0200, Corinna Vinschen wrote: >> >I don't know if that's a problem for them, but this reminds me... maybe >> >we can use the LD_PRELOAD mechanism in hookapi.cc for that? >> >> I was thinking that we'd use something like that (re my use of PRELOAD >> and your use of CW_HOOK) but, you're right. Someone could potentially >> implement MSYS.dll via LD_PRELOAD: >> >> LD_PRELOAD=msys.dll >> >> and then have msys.dll hook the functions that it is interested in using >> via CW_HOOK. > >Two points come to mind. > >- Does CW_HOOK still work? I had to change a lot of code in > hook_or_detect_cygwin to handle big executables and 32 vs. 64 bit, so > I have no idea if it still does the righht thing in terms of CW_HOOK. Who knows? That's something that should be fixed, regardless. >- Isn't CW_HOOK a bit heavy handed for MSYS? MSYS only replaces partial > functionality, not entire functions. Something like a CW_HOOK2 which > only results in Cygwin calling certain function pointers for minor > tweaks could be the result... MSYS is free to call the old function first if it needs to and then modify the output. That's basically what any hook would do anyway. Daniel Colascione's point is a stumbling block though since the LD_PRELOAD method doesn't currently allow hooking anything other than the main executable. That means that, say, ncurses wouldn't know about an MSYS-hooked uname. It is possible to work around that but it would require the addition of new code to the LD_PRELOAD mechanism, requiring that we keep a table of hooked functions. cgf ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: MSYS mode (continue) 2013-07-26 17:01 ` Christopher Faylor @ 2013-07-26 17:03 ` Daniel Colascione 2013-07-26 17:36 ` Christopher Faylor 0 siblings, 1 reply; 52+ messages in thread From: Daniel Colascione @ 2013-07-26 17:03 UTC (permalink / raw) To: cygwin-developers [-- Attachment #1: Type: text/plain, Size: 749 bytes --] On 7/26/2013 10:01 AM, Christopher Faylor wrote: > Daniel Colascione's point is a stumbling block though since the > LD_PRELOAD method doesn't currently allow hooking anything other than > the main executable. That means that, say, ncurses wouldn't know about > an MSYS-hooked uname. It is possible to work around that but it would > require the addition of new code to the LD_PRELOAD mechanism, requiring > that we keep a table of hooked functions. You don't need to maintain your own table. When you hook, you just have to munge all the import tables of all currently-loaded modules, then munge the export table of the module you want to hook. Munging the export table will take care of any modules that load in the future. [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 260 bytes --] ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: MSYS mode (continue) 2013-07-26 17:03 ` Daniel Colascione @ 2013-07-26 17:36 ` Christopher Faylor 0 siblings, 0 replies; 52+ messages in thread From: Christopher Faylor @ 2013-07-26 17:36 UTC (permalink / raw) To: cygwin-developers On Fri, Jul 26, 2013 at 10:03:42AM -0700, Daniel Colascione wrote: >On 7/26/2013 10:01 AM, Christopher Faylor wrote: >>Daniel Colascione's point is a stumbling block though since the >>LD_PRELOAD method doesn't currently allow hooking anything other than >>the main executable. That means that, say, ncurses wouldn't know about >>an MSYS-hooked uname. It is possible to work around that but it would >>require the addition of new code to the LD_PRELOAD mechanism, requiring >>that we keep a table of hooked functions. > >You don't need to maintain your own table. When you hook, you just >have to munge all the import tables of all currently-loaded modules, >then munge the export table of the module you want to hook. Munging >the export table will take care of any modules that load in the future. I think it would be faster to keep a list of functions since, otherwise, on fork, it seems like you'd have to walk the whole Cygwin export list, looking for functions to re-target. cgf ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: MSYS mode (continue) 2013-07-26 16:47 ` Corinna Vinschen 2013-07-26 17:01 ` Christopher Faylor @ 2013-07-26 23:12 ` Yaakov (Cygwin/X) 1 sibling, 0 replies; 52+ messages in thread From: Yaakov (Cygwin/X) @ 2013-07-26 23:12 UTC (permalink / raw) To: cygwin-developers On 2013-07-26 11:47, Corinna Vinschen wrote: > - Does CW_HOOK still work? I had to change a lot of code in > hook_or_detect_cygwin to handle big executables and 32 vs. 64 bit, so > I have no idea if it still does the righht thing in terms of CW_HOOK. datefudge (in Ports) seems to work correctly on x86_64, so I believe so. Yaakov ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: MSYS mode (continue) 2013-07-26 8:15 ` Corinna Vinschen 2013-07-26 15:14 ` Christopher Faylor @ 2013-07-27 3:07 ` Charles Wilson 2013-07-28 0:18 ` NightStrike 2013-07-29 9:25 ` Corinna Vinschen 1 sibling, 2 replies; 52+ messages in thread From: Charles Wilson @ 2013-07-27 3:07 UTC (permalink / raw) To: cygwin-developers On 7/26/2013 4:15 AM, Corinna Vinschen wrote: > On Jul 25 16:53, Christopher Faylor wrote: >> I don't know if this helps but the vague plan is to now have two DLLs >> where before you only had one. You'd still be providing "MSYS" binaries >> which relied on "MSYS.dll" but, under the hood, MSYS.dll would be only a >> small dll which relied on cygwin1.dll for all of the heavy lifting. >> >> You'd still have a normal MSYS distribution and it would still, in theory, >> support everything (with the possible exception of very lax security) that >> the old MSYS did. An MSYS release would consist of MSYS*.dll, cygwin1.dll, >> bash, etc. > > Here's where I disagree. I think the executables should *not* rely on > MSYS.dll being available. Ideally the executables are linked against > the Cygwin DLL and MSYS.dll is called as a side-by-side implementation. > So, if MSYS.dll isn't available, they still function as normal Cygwin > executables. That's why I proposed the solution(s) in > http://cygwin.com/ml/cygwin-developers/2013-07/msg00003.html So, in this proposal I'd have an "msys" directory structure, with cygwin1.dll, an /etc/fstab, and lots of plain-old-cygwin executables, bit-for-bit identical to the executables in my "real" cygwin installation/directory structure. On executable launch, ALL such applications would check for the hook DLL (as directed by an env variable, perhaps, or some other mechanism -- maybe encoded in a known-present file, like.../etc/fstab? [1]) and if present, load it. Even the (bit-for-bit-identical) apps in my "real" cygwin installation would do this -- but because (a) they don't have that env setting or fstab setting, and (b) even if they did, the special msys-hook dll isn't present in that tree -- so nothing actually happens in that situation. Now, back in my MSYS-on-cygwin installation, there are SOME executables that are actually *different* that the corresponding ones in real-cygwin-land. Stuff like make, bash, perl, etc -- all may have been compiled with different options because we (the mingw/msys people) want them to behave differently, in ways that can't automatically be handled by the hooked changes in cygwin1.dll's own behavior. Have I got that all correct? [1] I think this is better than an environment var, because then my "regular" cygwin tree and my "msys" cygwin tree would both just work, without needed extraneous global env vars that might interfere with the other's operation. In fact, I might want *different* CYGWIN env var settings for the two trees, but unless I set them in the global env then StartMenu-launched apps lose out. Could we maybe extend the CYGWIN env var idea to files, similar to the /etc/fstab[.d] structure, which are then *augmented* by $CYGWIN? e.g. in my msys-on-cygwin tree, I might have /etc/cygwin_settings hook=/bin/msys-hook.dll export glob:ignorecase winsymlinks:nativestrict /etc/cygwin_settings.d/user error_start:c:\msys\bin\gdb.exe But in my "real" cygwin tree, I might have /etc/cygwin_settings proc_retry:1 /etc/cygwin_settings.d/user pipe_byte > Assuming you implement it the first way, you get an executable linked > against a crt0.o which tries a LoadLibrary("MSYS.dll"). If it fails, > the executable does business as usual. It will not fail, because > there's still the Cygwin DLL. > > If LoadLib worked, crt0 calls GetProcAddress("__msys_hook") and then > __msys_hook(). __msys_hook collects the hook function pointers and > sends them to the CYgwin DLL via a call to cygwin_internal(CW_HOOK, > &hook_list). Voila, the hooks are set up, we're in MSYS mode. > > > Another alternative would be if the Cygwin DLL itself had a switch to > load the MSYS dll (export CYGWIN=MSYS ;)). This would allows MSYS mode > even with completely unchanged executables. Right -- but *some* executables would need to actually BE different, aside from the underlying posix library's behavioral changes, to get a "real" MSYS environment. >> I don't think anyone was proposing seamless interoperation between MSYS >> and cygwin. > > Yes, I honestly think this would be possible and desirable. MSYS is > just a tiny change for a specific task in comparison to the default > Cygwin mode. MSYS would concentrate on this task and the required tools > for this task and the rest could be stock Cygwin distro. I think that would, in fact, work -- but I think the list of tools that would need compile-time changes is larger than you would hope. But...IMO that's ok. MSYS's goal was to be a *minimal* system...NOT an alternate cygwin. If this proposal (a) makes the msys "fork" a non-fork, AND easier to maintain, and (b) incidentally means that SOMETIMES you might be able to "drop in" a stock cygwin .exe and it might just work -- no guarantees, you break it you bought it, we're just mean -- then it's a win overall. The MSYS team would just provide patched and (re)compiled versions of most of their current set of tools...and if users wanted to "drop in" (e.g.) git.exe, well they are welcome to try it. No support offered or guaranteed, and they might just get lucky. > Btw., this does *not* mean I agree with all changes MSYS is doing. I > have a hard time to see the necessity changing the /etc/fstab layout, > for instance, since it doesn't add or change anything you can't have > with the standard fstab. As cgf pointed out, if "we" (cygwin) are trying to come up with an easy upgrade path for existing users of MSYS, then we (mingw/msys) users would prefer not to have to change our existing fstab format on all of our installations. Unless you (we, cygwin) automate that somehow... -- Chuck ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: MSYS mode (continue) 2013-07-27 3:07 ` Charles Wilson @ 2013-07-28 0:18 ` NightStrike 2013-07-29 9:30 ` Corinna Vinschen 2013-07-29 9:25 ` Corinna Vinschen 1 sibling, 1 reply; 52+ messages in thread From: NightStrike @ 2013-07-28 0:18 UTC (permalink / raw) To: cygwin-developers On Fri, Jul 26, 2013 at 11:06 PM, Charles Wilson wrote: > On 7/26/2013 4:15 AM, Corinna Vinschen wrote: >> Another alternative would be if the Cygwin DLL itself had a switch to >> load the MSYS dll (export CYGWIN=MSYS ;)). This would allows MSYS mode >> even with completely unchanged executables. > > > Right -- but *some* executables would need to actually BE different, aside > from the underlying posix library's behavioral changes, to get a "real" MSYS > environment. Perhaps it would be useful to actually identify which packages have extenuating needs. Maybe it's just one or two. Maybe it's all but one or two. I don't think that currently, the problem space is properly enumerated, but is instead living in the abstract. ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: MSYS mode (continue) 2013-07-28 0:18 ` NightStrike @ 2013-07-29 9:30 ` Corinna Vinschen 2013-07-29 11:00 ` LRN 0 siblings, 1 reply; 52+ messages in thread From: Corinna Vinschen @ 2013-07-29 9:30 UTC (permalink / raw) To: cygwin-developers On Jul 27 20:17, NightStrike wrote: > On Fri, Jul 26, 2013 at 11:06 PM, Charles Wilson wrote: > > On 7/26/2013 4:15 AM, Corinna Vinschen wrote: > >> Another alternative would be if the Cygwin DLL itself had a switch to > >> load the MSYS dll (export CYGWIN=MSYS ;)). This would allows MSYS mode > >> even with completely unchanged executables. > > > > > > Right -- but *some* executables would need to actually BE different, aside > > from the underlying posix library's behavioral changes, to get a "real" MSYS > > environment. > > Perhaps it would be useful to actually identify which packages have > extenuating needs. Maybe it's just one or two. Maybe it's all but > one or two. I don't think that currently, the problem space is > properly enumerated, but is instead living in the abstract. Very good point. This would perhaps show us much better where we're heading here. From the current input I only see the following required changes in relation to a stock Cygwin distro: - make w/ DOS path handling - gcc targeting Mingw rather than Cygwin. - Cygwin compiler provided as cross tool $arch-pc-cygwin-gcc, etc.(*) Corinna (*) Per my suggestion there would be no MSYS targeting compiler anymore. It would target Cygwin and everything else just depends on how the MSYS dll gets loaded. -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: MSYS mode (continue) 2013-07-29 9:30 ` Corinna Vinschen @ 2013-07-29 11:00 ` LRN 2013-07-29 11:19 ` Corinna Vinschen 2013-07-29 11:19 ` Earnie Boyd 0 siblings, 2 replies; 52+ messages in thread From: LRN @ 2013-07-29 11:00 UTC (permalink / raw) To: cygwin-developers -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 29.07.2013 13:29, Corinna Vinschen wrote: > On Jul 27 20:17, NightStrike wrote: >> On Fri, Jul 26, 2013 at 11:06 PM, Charles Wilson wrote: >>> On 7/26/2013 4:15 AM, Corinna Vinschen wrote: >>>> Another alternative would be if the Cygwin DLL itself had a switch to >>>> load the MSYS dll (export CYGWIN=MSYS ;)). This would allows MSYS mode >>>> even with completely unchanged executables. >>> >>> >>> Right -- but *some* executables would need to actually BE different, aside >>> from the underlying posix library's behavioral changes, to get a "real" MSYS >>> environment. >> >> Perhaps it would be useful to actually identify which packages have >> extenuating needs. Maybe it's just one or two. Maybe it's all but >> one or two. I don't think that currently, the problem space is >> properly enumerated, but is instead living in the abstract. > > Very good point. This would perhaps show us much better where we're > heading here. From the current input I only see the following required > changes in relation to a stock Cygwin distro: > > - make w/ DOS path handling Yes. Note that the code DOES exist in make, but is disabled when make is built for Cygwin. One might question whether it was a good idea to disable support for W32 paths in make that runs on W32 (with a compatibility layer, but still...) in the first place. > - gcc targeting Mingw rather than Cygwin. You already have that, it's called "mingw cross-compiler for cygwin". And that is not what msys users use. I think you've meant something different here, i'm not sure what. > - Cygwin compiler provided as cross tool $arch-pc-cygwin-gcc, etc.(*) Yes. That includes binutils too (obviously) Also: base-files: add /mingw/bin to PATH when running in MINGW mode (adding /mingw/share/{man,info} to {MAN,INFO}PATH is also useful, but not really mandatory) (ok, these aren't binaries, so maybe they don't qualify) bash: Fix various instances of '\r' handling. coreutils: Bring back the '\r' support in md5sum. This is another change that might just go into Cygwin in general. I'm not sure whether '\r' is a valid character to use in filenames. (optionally) embed install.exe.manifest into install.exe There are also patches to rebase that i find useful, but they are up to debate. Yeah, that list turned out to be really short. There may be other packages that need fixing ('\r' handling is the likely culprit), but i haven't bumped into them yet, so i wouldn't know. - -- O< ascii ribbon - stop html email! - www.asciiribbon.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) iQEcBAEBAgAGBQJR9ks4AAoJEOs4Jb6SI2CwGKwIAJjB2P3fS9xVjhBP5gyOSv8W aevmjZ5nLXH0JyWqv9kNM87vyU16V7yEcXel1Md+Fcy6fdQ6xTzU9xjnDjLIPItk B6IR/DKTAUMeZSo99gjKOcvi1YFH6AdlOlsvdBPemVl5TQ9FR11F5V0Ff9zSwyB9 tLH/bRIb3Wj5wiRBqg0mxIu1w+ur6crR0w9qavj3pGwfbfOQPJN4FD05iXtltwo5 MX1yWlnbySaYJsVGBzQX2w7ROQ7fEa2urvUxPASszuzQGrCVa1qQnfn3exv8+cX4 fwN3axRkM6P6UAPjO9UkuB9/AoNUDX9u+MIbWtrIGhnM6oewL7/aDypYogA66X4= =7Rx3 -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: MSYS mode (continue) 2013-07-29 11:00 ` LRN @ 2013-07-29 11:19 ` Corinna Vinschen 2013-07-29 15:36 ` LRN 2013-07-29 11:19 ` Earnie Boyd 1 sibling, 1 reply; 52+ messages in thread From: Corinna Vinschen @ 2013-07-29 11:19 UTC (permalink / raw) To: cygwin-developers On Jul 29 15:00, LRN wrote: > On 29.07.2013 13:29, Corinna Vinschen wrote: > > On Jul 27 20:17, NightStrike wrote: > >> Perhaps it would be useful to actually identify which packages have > >> extenuating needs. Maybe it's just one or two. Maybe it's all but > >> one or two. I don't think that currently, the problem space is > >> properly enumerated, but is instead living in the abstract. > > > > Very good point. This would perhaps show us much better where we're > > heading here. From the current input I only see the following required > > changes in relation to a stock Cygwin distro: > > > > - make w/ DOS path handling > Yes. Note that the code DOES exist in make, but is disabled when make is > built for Cygwin. One might question whether it was a good idea to > disable support for W32 paths in make that runs on W32 (with a > compatibility layer, but still...) in the first place. Cygwin paths can contain "x:" as part of a normal filename. > > - gcc targeting Mingw rather than Cygwin. > You already have that, it's called "mingw cross-compiler for cygwin". > And that is not what msys users use. > I think you've meant something different here, i'm not sure what. That's exactly what I meant. Of course we have a mingw cross compiler in the Cygwin distro, but as far as the discussion on the mingw-w64 list showed, MSYS users apparently prefer the "native" gcc compiler (the one called "gcc") to produce mingw executables (aka "native Windows exectables running without a compat layer") to avoid cross compiling when creating native Windows executables. If the native gcc in an MSYS install targets MSYS, and if you had to use a cross compiler to create native Windows executables (as in Cygwin), there would ne no reason for MSYS at all since it would be equivalent to Cygwin. > > - Cygwin compiler provided as cross tool $arch-pc-cygwin-gcc, etc.(*) > Yes. That includes binutils too (obviously) > > > Also: > > base-files: > add /mingw/bin to PATH when running in MINGW mode > (adding /mingw/share/{man,info} to {MAN,INFO}PATH is also useful, but > not really mandatory) > (ok, these aren't binaries, so maybe they don't qualify) > > bash: > Fix various instances of '\r' handling. > > coreutils: > Bring back the '\r' support in md5sum. This is another change that might > just go into Cygwin in general. I'm not sure whether '\r' is a valid > character to use in filenames. Yes. > (optionally) embed install.exe.manifest into install.exe > > There are also patches to rebase that i find useful, but they are up to > debate. > > Yeah, that list turned out to be really short. There may be other > packages that need fixing ('\r' handling is the likely culprit), but i > haven't bumped into them yet, so i wouldn't know. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: MSYS mode (continue) 2013-07-29 11:19 ` Corinna Vinschen @ 2013-07-29 15:36 ` LRN 2013-07-29 15:47 ` Corinna Vinschen 0 siblings, 1 reply; 52+ messages in thread From: LRN @ 2013-07-29 15:36 UTC (permalink / raw) To: cygwin-developers -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 29.07.2013 15:18, Corinna Vinschen wrote: > On Jul 29 15:00, LRN wrote: >> On 29.07.2013 13:29, Corinna Vinschen wrote: >>> On Jul 27 20:17, NightStrike wrote: >>>> Perhaps it would be useful to actually identify which packages have >>>> extenuating needs. Maybe it's just one or two. Maybe it's all but >>>> one or two. I don't think that currently, the problem space is >>>> properly enumerated, but is instead living in the abstract. >>> >>> Very good point. This would perhaps show us much better where we're >>> heading here. From the current input I only see the following required >>> changes in relation to a stock Cygwin distro: >>> >>> - gcc targeting Mingw rather than Cygwin. >> You already have that, it's called "mingw cross-compiler for cygwin". >> And that is not what msys users use. >> I think you've meant something different here, i'm not sure what. > > That's exactly what I meant. Of course we have a mingw cross compiler > in the Cygwin distro, but as far as the discussion on the mingw-w64 list > showed, MSYS users apparently prefer the "native" gcc compiler (the one > called "gcc") "native" compiler is the one that does not do cross-compiling. That is, it compiles with $build==$host, produces code for $build, and looks for headers/libs in $prefix/{include,lib} (unlike cross-compilers, which produce code for $host!=$build and look in $prefix/$host/{include,lib}). Whether it's called "gcc.exe" or "i686-w64-mingw32.exe" is not important (well, it is, but usually you just symlink gcc.exe to i686-w64-mingw32.exe). > to produce mingw executables (aka "native Windows > exectables running without a compat layer") to avoid cross compiling > when creating native Windows executables. If the native gcc in an MSYS > install targets MSYS, and if you had to use a cross compiler to create > native Windows executables (as in Cygwin), there would ne no reason for > MSYS at all since it would be equivalent to Cygwin. Yes. In this case i don't see how Cygwin fits in here. Unless you suddenly decided to become a MinGW toolchain vendor. /usr/bin/gcc is a cygwin gcc that targets cygwin /mingw/bin/gcc is MinGW gcc that targets W32. Anything that resides in /mingw is completely outside of cygwin domain, which is why i was surprised to hear that you wanted to provide mingw gcc. I would expect people to get cygwin/msys in one place, and get MinGW in another. Even mingw-get, while being a source of both msys and mingw packages, clearly distinguishes betweent he two. - -- O< ascii ribbon - stop html email! - www.asciiribbon.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) iQEcBAEBAgAGBQJR9ovsAAoJEOs4Jb6SI2CwwdcH/0qynygMxZMHTh/P9WIkJ3oQ yysC8gJ21ScexouI3uwSzFH6n9pFUZ7cboFsdY3b5WH62K85RHZnI0EUd8YLAmM+ NXPj7XiqSbWbEO7GBQhsvr3T5QEP4M/2xCOTQdqMJI2Ew4VAbKsEDrZQIvZoQoGD 59ZFzMZR1phE868EFg2QtdHVomyZwudUg+ZWkuK4vxhkfkMQ/ebNG21tvRSXFgYM yh/jRXTd0ITVw7NgXc5w6U16u9xC3eJFtdIfpxF1cKvkPUikyo4rZFiLl+n8O1JM X+XMrJmHOjTV/yqYB1g5Zx6Ebhb8xkh0S222fDrWCD7TtQixT5rKmt3XIdFwRSk= =d8By -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: MSYS mode (continue) 2013-07-29 15:36 ` LRN @ 2013-07-29 15:47 ` Corinna Vinschen 2013-07-29 16:37 ` Charles Wilson 2013-07-30 0:45 ` LRN 0 siblings, 2 replies; 52+ messages in thread From: Corinna Vinschen @ 2013-07-29 15:47 UTC (permalink / raw) To: cygwin-developers On Jul 29 19:36, LRN wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 29.07.2013 15:18, Corinna Vinschen wrote: > > On Jul 29 15:00, LRN wrote: > >> On 29.07.2013 13:29, Corinna Vinschen wrote: > >>> On Jul 27 20:17, NightStrike wrote: > >>>> Perhaps it would be useful to actually identify which packages have > >>>> extenuating needs. Maybe it's just one or two. Maybe it's all but > >>>> one or two. I don't think that currently, the problem space is > >>>> properly enumerated, but is instead living in the abstract. > >>> > >>> Very good point. This would perhaps show us much better where we're > >>> heading here. From the current input I only see the following required > >>> changes in relation to a stock Cygwin distro: > >>> > >>> - gcc targeting Mingw rather than Cygwin. > >> You already have that, it's called "mingw cross-compiler for cygwin". > >> And that is not what msys users use. > >> I think you've meant something different here, i'm not sure what. > > > > That's exactly what I meant. Of course we have a mingw cross compiler > > in the Cygwin distro, but as far as the discussion on the mingw-w64 list > > showed, MSYS users apparently prefer the "native" gcc compiler (the one > > called "gcc") > "native" compiler is the one that does not do cross-compiling. That is, > it compiles with $build==$host, produces code for $build, and looks for > headers/libs in $prefix/{include,lib} (unlike cross-compilers, which > produce code for $host!=$build and look in $prefix/$host/{include,lib}). > Whether it's called "gcc.exe" or "i686-w64-mingw32.exe" is not important > (well, it is, but usually you just symlink gcc.exe to i686-w64-mingw32.exe). I'm perfectly aware what a cross compiler is, but in case of Cygwin or MSYS you have a bit of a hard time to define what a native compiler is, the one creating Cygwin binaries or the one creating Windows binaries with the unspoken assumption that they don't require the Cygwin DLL. That's why I tried to describe it in so may word and apparently failed. > > to produce mingw executables (aka "native Windows > > exectables running without a compat layer") to avoid cross compiling > > when creating native Windows executables. If the native gcc in an MSYS > > install targets MSYS, and if you had to use a cross compiler to create > > native Windows executables (as in Cygwin), there would ne no reason for > > MSYS at all since it would be equivalent to Cygwin. > > Yes. In this case i don't see how Cygwin fits in here. Unless you > suddenly decided to become a MinGW toolchain vendor. > /usr/bin/gcc is a cygwin gcc that targets cygwin > /mingw/bin/gcc is MinGW gcc that targets W32. > > Anything that resides in /mingw is completely outside of cygwin domain, > which is why i was surprised to hear that you wanted to provide mingw gcc. > > I would expect people to get cygwin/msys in one place, and get MinGW in > another. Even mingw-get, while being a source of both msys and mingw > packages, clearly distinguishes betweent he two. That's what I understood differently. From the discussion on mingw-w64 it seemed that a mingw dev using Cygwin/MSYS would prefer if the default gcc creates non-CYgwin/MSYS, but rather Windows-only binaries. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: MSYS mode (continue) 2013-07-29 15:47 ` Corinna Vinschen @ 2013-07-29 16:37 ` Charles Wilson 2013-07-30 1:18 ` LRN 2013-07-30 0:45 ` LRN 1 sibling, 1 reply; 52+ messages in thread From: Charles Wilson @ 2013-07-29 16:37 UTC (permalink / raw) To: cygwin-developers On 7/29/2013 11:47 AM, Corinna Vinschen wrote: > That's what I understood differently. From the discussion on mingw-w64 > it seemed that a mingw dev using Cygwin/MSYS would prefer if the default > gcc creates non-CYgwin/MSYS, but rather Windows-only binaries. I agree with Corinna here. I think LRN is assuming that the installation structure will remain the same as MinGW/MSYS going forward, and I do not believe that is correct -- at least, that's not what Corinna is proposing IIUC. Here's how MinGW/MSYS works right now: *normally* the batch file you use to enter the "MinGW" environment, launches bash with 1) MSYSTEM=MINGW32 2) /mingw/bin at the "front" of $PATH (wherever your mount table happens to say that is) Your phyiscal directory structure *normally* looks something like this: C:\MinGW <<<<< mounted as /mingw bin MinGW (that is, "native" win32) gcc.exe & friends include "native" win32 headers lib and libraries msys 1.0 <<<<< mounted as / bin gcc.exe -- only this time, it's an msys-target compiler. But note that it is actually configured as a "native" compiler include msys headers and lib libraries Because of #1 and #2 above, uname reports MINGW32, and the first gcc found in your path is the "native" win32 MinGW one. However, an *msys* developer would launch a script that invokes bash with 1) MSYSTEM=MSYS 2) /bin at the "front" of $PATH In this case, uname reports MSYS, and the first gcc found in your path is the msys one. =====-----===== In the new scenario, we might have a separable installation -- maybe c:\msys\2.0\ but there isn't any gcc.exe installed there. And then you might install MinGW gcc somewhere like c:\MinGW-4.8.1\ and just arrange that c:\msys\2.0\etc\fstab has c:\MinGW-4.8.1\ /mingw and again, you make sure that /mingw/bin is in your $PATH. However, in the new scenario, you MIGHT have, in c:\msys\2.0\i686-pc-cygwin\, a cross compiler targetting "cygwin/msys" and running on...MinGW (even though "MinGW" environment is, for all intents and purposes, a slightly modified cygwin -- but uname reports MINGW32 just like it does for "native" MinGW/win32 operation). To build msys apps in this environment, you have to use --host=i686-pc-cygwin (and remember, because uname is reporting "MINGW32", any build system will operate under the assumption that you are, in fact, cross compiling). There are some advantages to the former system, not least of which is that when MSYSTEM=MSYS, you're compiling natively so you can easily run any test suites without having to play games with the build system. I think LRN is assuming that the gcc installed in /bin would be the cygwin gcc (configured as a native compiler), and we'd continue to play $MSYSTEM/$PATH games. One additional "advantage" to the former system is the autotools. Right now we can have a "clean" separation between aclocal/.m4 files that have data corresponding to MinGW-compiled native libs and tools, and aclocal/.m4 files that have data corresponding to the msys ones -- because we have two entirely distinct "sets" of autotools. /mingw/* has the whole panoply of autoconf2.1/2.5/wrapper, automake1.4--1.12/wrapper, libtool, gettext, and libintl. All are configured with --prefix=/mingw, so they look in /mingw/share/aclocal*/ for .m4 stuff. OTOH, in /{bin,lib,share} we have one specific version of autoconf (2.59 IIRC), one specific version of automake (1.11?), libtool specially hacked to support msys (because "regular" libtool does not), gettext, and libintl. Because msys has never been, and was not intended to be, a public "triple" value, these versions' config.guess/config.sub were modified to recognize the MSYS uname, and report i686-pc-msys as a triple, and to actually handle that triple correctly. The /mingw version of the autotools was not hacked in this way. This way, when porting some package in /mingw land and running re-autoconf, users don't get "fooled" by picking up stuff in /share/aclocal/* -- they only "see" the .m4 files that correspond to OTHER fully-ported-to-mingw libs and tools. -- Chuck ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: MSYS mode (continue) 2013-07-29 16:37 ` Charles Wilson @ 2013-07-30 1:18 ` LRN 0 siblings, 0 replies; 52+ messages in thread From: LRN @ 2013-07-30 1:18 UTC (permalink / raw) To: cygwin-developers -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 29.07.2013 20:37, Charles Wilson wrote: > On 7/29/2013 11:47 AM, Corinna Vinschen wrote: >> That's what I understood differently. From the discussion on mingw-w64 >> it seemed that a mingw dev using Cygwin/MSYS would prefer if the default >> gcc creates non-CYgwin/MSYS, but rather Windows-only binaries. > > I agree with Corinna here. I think LRN is assuming that the > installation structure will remain the same as MinGW/MSYS going forward, > and I do not believe that is correct -- at least, that's not what > Corinna is proposing IIUC. > > > In the new scenario, we might have a separable installation -- maybe > c:\msys\2.0\ > but there isn't any gcc.exe installed there. And then you might install > MinGW gcc somewhere like > c:\MinGW-4.8.1\ > and just arrange that > c:\msys\2.0\etc\fstab > has > c:\MinGW-4.8.1\ /mingw > > and again, you make sure that /mingw/bin is in your $PATH. > > However, in the new scenario, you MIGHT have, in > c:\msys\2.0\i686-pc-cygwin\, a cross compiler targetting "cygwin/msys" > and running on...MinGW (even though "MinGW" environment is, for all > intents and purposes, a slightly modified cygwin -- but uname reports > MINGW32 just like it does for "native" MinGW/win32 operation). To build > msys apps in this environment, you have to use --host=i686-pc-cygwin > (and remember, because uname is reporting "MINGW32", any build system > will operate under the assumption that you are, in fact, cross compiling). That might work. It also means that you'll need a new cygwin cross-compiler (a mingw->cygwin cross-compiler, although in reality it might be cygwin->cygwin native compiler that looks like a cross-compiler). Unless existing one can be stuffed into /usr/i686-pc-cygwin without any ill effects. > > There are some advantages to the former system, not least of which is > that when MSYSTEM=MSYS, you're compiling natively so you can easily run > any test suites without having to play games with the build system. > > I think LRN is assuming that the gcc installed in /bin would be the > cygwin gcc (configured as a native compiler), and we'd continue to play > $MSYSTEM/$PATH games. Yes, LRN is assuming that /usr/bin/gcc is a cygwin-gcc, and /mingw/bin/gcc is a mingw gcc. $MSYSTEM/$PATH games worked well enough so far. > > One additional "advantage" to the former system is the autotools. Right > now we can have a "clean" separation between aclocal/.m4 files that have > data corresponding to MinGW-compiled native libs and tools, and > aclocal/.m4 files that have data corresponding to the msys ones -- > because we have two entirely distinct "sets" of autotools. > > /mingw/* has the whole panoply of autoconf2.1/2.5/wrapper, > automake1.4--1.12/wrapper, libtool, gettext, and libintl. All are > configured with --prefix=/mingw, so they look in /mingw/share/aclocal*/ > for .m4 stuff. Yes, that is a good point. > > OTOH, in /{bin,lib,share} we have one specific version of autoconf (2.59 > IIRC), one specific version of automake (1.11?), libtool specially > hacked to support msys (because "regular" libtool does not), gettext, > and libintl. Because msys has never been, and was not intended to be, a > public "triple" value, these versions' config.guess/config.sub were > modified to recognize the MSYS uname, and report i686-pc-msys as a > triple, and to actually handle that triple correctly. Yes, but with cygwin that is going to go away, as i686-pc-cygwin IS a valid triplet. More reasons to not to let mingw apps see these autotools and m4 files. > > The /mingw version of the autotools was not hacked in this way. Though it might be hacked in other, unspecified ways (for example, i mess with stuff a lot to integrate W32 CPython; this is not needed for msys-python). You've laid out advantages and "advantages" of the former system. What are the advantages of the latter system? - -- O< ascii ribbon - stop html email! - www.asciiribbon.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) iQEcBAEBAgAGBQJR9xRSAAoJEOs4Jb6SI2CwZgUH/0O53vyz6+QfwWFYBWCtsXl9 yIwVEoEQY7GmwFFPRXLiZkh8EQx2/xKdZrpwFGVHPb/hFyYuBPjDkzDlWV6KrFBh o3YKPlZjPw1gyD+p03ekFkxpgPgZpucaR0k54UyqnnXAtZwA8NhToMokxPJVKez3 e4gpM+dmmpWWsZLQl7I1ZwOTnG88B7aySt8nphGpfUCtfWGzaKU+6JN48HzQapHU 7Wj30Ashmt1eI9LJK5kz+RnBEzdrYlsJITDa+BdHBSFhgqZsMc/DothBmcxi4hl4 ZPFWi6ErAggdkIHrYku1/YUjDjZ19KXHkerY+0y9QwQAJUVZ0iSaau82C3EIZcY= =p74t -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: MSYS mode (continue) 2013-07-29 15:47 ` Corinna Vinschen 2013-07-29 16:37 ` Charles Wilson @ 2013-07-30 0:45 ` LRN 2013-07-30 9:04 ` Corinna Vinschen 1 sibling, 1 reply; 52+ messages in thread From: LRN @ 2013-07-30 0:45 UTC (permalink / raw) To: cygwin-developers -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 29.07.2013 19:47, Corinna Vinschen wrote: > On Jul 29 19:36, LRN wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 29.07.2013 15:18, Corinna Vinschen wrote: >>> On Jul 29 15:00, LRN wrote: >>>> On 29.07.2013 13:29, Corinna Vinschen wrote: >>>>> On Jul 27 20:17, NightStrike wrote: >>>>>> Perhaps it would be useful to actually identify which packages have >>>>>> extenuating needs. Maybe it's just one or two. Maybe it's all but >>>>>> one or two. I don't think that currently, the problem space is >>>>>> properly enumerated, but is instead living in the abstract. >>>>> >>>>> Very good point. This would perhaps show us much better where we're >>>>> heading here. From the current input I only see the following required >>>>> changes in relation to a stock Cygwin distro: >>>>> >>>>> - gcc targeting Mingw rather than Cygwin. >>>> You already have that, it's called "mingw cross-compiler for cygwin". >>>> And that is not what msys users use. >>>> I think you've meant something different here, i'm not sure what. >>> >>> to produce mingw executables (aka "native Windows >>> exectables running without a compat layer") to avoid cross compiling >>> when creating native Windows executables. If the native gcc in an MSYS >>> install targets MSYS, and if you had to use a cross compiler to create >>> native Windows executables (as in Cygwin), there would ne no reason for >>> MSYS at all since it would be equivalent to Cygwin. >> >> Yes. In this case i don't see how Cygwin fits in here. Unless you >> suddenly decided to become a MinGW toolchain vendor. >> /usr/bin/gcc is a cygwin gcc that targets cygwin >> /mingw/bin/gcc is MinGW gcc that targets W32. >> >> Anything that resides in /mingw is completely outside of cygwin domain, >> which is why i was surprised to hear that you wanted to provide mingw gcc. >> >> I would expect people to get cygwin/msys in one place, and get MinGW in >> another. Even mingw-get, while being a source of both msys and mingw >> packages, clearly distinguishes betweent he two. > > That's what I understood differently. From the discussion on mingw-w64 > it seemed that a mingw dev using Cygwin/MSYS would prefer if the default > gcc creates non-CYgwin/MSYS, but rather Windows-only binaries. The problem is not that you can't have a W32-targetted gcc.exe in /usr/bin. The problem is that the convention that everyone has been following for years now is that all mingw stuff lives in /mingw, and all msys (cygwin) stuff lives in /usr. These two are never mixed. If you start providing alternative gccs, that might confuse people. A lot. Since for people who installed cygwin-gcc, gcc.exe will produce cygwin binaries, while the ones with mingw-gcc will have a gcc.exe that produces mingw binaries. Also, how will you have both cygwin-gcc and mingw-gcc installed at the same time (some people do need that)? Relying on prefixes (i686-pc-cygwin-gcc and i686-w64-mingw32-gcc) might work, but not all packages are prefix-aware. This also brings us back to the distinction between native and non-native toolchains. To have both gccs in /usr, you'll have to make them look for stuff in /usr/$target/{include,lib}. Can't have both mingw and cygwin libs/headers in /usr/{lib,include}, obviously. While that might work, i'd guess that it will also break in a some cases, where people (and scripts) expect that $prefix/{lib,include} are the right dirs to use. If it looks in $prefix/$target/{lib,include} and has a name $target-gcc, then from user's point of view it's a cross-compiler (even if has build==host==target), and we've already decided that you already have a cross-compiler and don't need another one. /mingw also provided a way to swap mingw subsystem (just edit /etc/fstab to make /mingw point to a different dir, then restart the shell). With everything living in /usr that might be unnecessary, but now that i think of this...how are you going to separate compiled binaries from each other? Say, your /usr/bin/i686-w64-mingw-gcc builds libxml2-2.dll. That lands in /usr/bin. And when you compile libxml with /usr/bin/x86_64-w64-mingw-gcc, it builds libxml2-2.dll, and it lands into the same directory. Where else could it go? /usr/i686-w64-mingw/bin or /usr/x86_64-w64-mingw/bin? I've never seen mingw doing that kind of stuff. And how are you going to maintain PATH for them? If you propose to have only the toolchain in /usr, but build&install everything with --prefix=/mingw...that, again, might work in some cases, but not the others. Also, which packages are "the toolchain"? You will also need to configure gcc that lives in /usr to look for headers/libs in /mingw/{include,lib}. So i'd suggest to stick with /usr and /mingw convention and let mingw take care of itself. It's simpler that way. - -- O< ascii ribbon - stop html email! - www.asciiribbon.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) iQEcBAEBAgAGBQJR9wyWAAoJEOs4Jb6SI2CwkQ4H/iumE/JGhaPRrYrYygRTByht 9r+sTWocYtEeec1pM+Uza4lW9z03gMlcV5JZNM+UJ7d/mrJLFPFNBXR6B1PCZb7q sPq/XGB0JdY/mhDQ7Zm6nzW1lTFucEoNQh/KHc6yiRJwkaKVgt1erkQVznOtTvCq ZKk9HLqUx4zf6OVk7iJLNS9Y0pBesXmXljo3N4/iYKsRvGa3a1qWd7AmEmEKeYBU AfBQezkmP1/L/alNB5oNCAA7yj2W+ilfz5sUHVyq6EeXjQlr+xKvuJ8M/gTp6lYa 6946x414ANr3pCXa/Du3coN2372zydssxnRcOqW5SgL8L6l1orsvnfYpuJ2QuOo= =E7Iz -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: MSYS mode (continue) 2013-07-30 0:45 ` LRN @ 2013-07-30 9:04 ` Corinna Vinschen 2013-07-30 9:32 ` Alexey Pavlov 0 siblings, 1 reply; 52+ messages in thread From: Corinna Vinschen @ 2013-07-30 9:04 UTC (permalink / raw) To: cygwin-developers On Jul 30 04:45, LRN wrote: > On 29.07.2013 19:47, Corinna Vinschen wrote: > > On Jul 29 19:36, LRN wrote: > >> I would expect people to get cygwin/msys in one place, and get MinGW in > >> another. Even mingw-get, while being a source of both msys and mingw > >> packages, clearly distinguishes betweent he two. > > > > That's what I understood differently. From the discussion on mingw-w64 > > it seemed that a mingw dev using Cygwin/MSYS would prefer if the default > > gcc creates non-CYgwin/MSYS, but rather Windows-only binaries. > > The problem is not that you can't have a W32-targetted gcc.exe in /usr/bin. > > The problem is that the convention that everyone has been following for > years now is that all mingw stuff lives in /mingw, and all msys (cygwin) > stuff lives in /usr. These two are never mixed. > [...] > So i'd suggest to stick with /usr and /mingw convention and let mingw > take care of itself. It's simpler that way. Fine with me, of course. I don't have that problem myself so whatever works better for you is ok. But then the number of changed packages doesn't really matter. From my POV MSYS sticks to being it's own distro with another focus than the Cygwin distro. So we're back to discussing in how far MSYS can be implemented using a stock Cygwin DLL under the hood and the tweaks being in an external MSYS DLL so users can mix the best of both worlds as they see fit for their purpose. Are you going to help implementing this? If not, I'm missing input from any of the developers working on MSYS2... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: MSYS mode (continue) 2013-07-30 9:04 ` Corinna Vinschen @ 2013-07-30 9:32 ` Alexey Pavlov 2013-07-30 9:47 ` Corinna Vinschen 0 siblings, 1 reply; 52+ messages in thread From: Alexey Pavlov @ 2013-07-30 9:32 UTC (permalink / raw) To: cygwin-developers 2013/7/30 Corinna Vinschen > > On Jul 30 04:45, LRN wrote: > > On 29.07.2013 19:47, Corinna Vinschen wrote: > > > On Jul 29 19:36, LRN wrote: > > >> I would expect people to get cygwin/msys in one place, and get MinGW in > > >> another. Even mingw-get, while being a source of both msys and mingw > > >> packages, clearly distinguishes betweent he two. > > > > > > That's what I understood differently. From the discussion on mingw-w64 > > > it seemed that a mingw dev using Cygwin/MSYS would prefer if the default > > > gcc creates non-CYgwin/MSYS, but rather Windows-only binaries. > > > > The problem is not that you can't have a W32-targetted gcc.exe in /usr/bin. > > > > The problem is that the convention that everyone has been following for > > years now is that all mingw stuff lives in /mingw, and all msys (cygwin) > > stuff lives in /usr. These two are never mixed. > > [...] > > So i'd suggest to stick with /usr and /mingw convention and let mingw > > take care of itself. It's simpler that way. > > Fine with me, of course. I don't have that problem myself so whatever > works better for you is ok. But then the number of changed packages > doesn't really matter. From my POV MSYS sticks to being it's own distro > with another focus than the Cygwin distro. > > So we're back to discussing in how far MSYS can be implemented using a > stock Cygwin DLL under the hood and the tweaks being in an external MSYS > DLL so users can mix the best of both worlds as they see fit for their > purpose. > As I see all discussion not about implementing but about philosophy of MSYS. At the start of discussion I wrote about my changes in Cygwin sources to have MSYS. And also send small patches but nothing really doing in this direction. What steps do we need to start any work on implementing it? Now I see next points where we can change Cygwin functionality: 1. uname function 2. reading /etc/fstab 3. passing arguments and environment variables to non-Cygwin processes ( environ.cc, spawn.cc ) 4. symlinks changes (copy instead symlink) > > Are you going to help implementing this? If not, I'm missing input > from any of the developers working on MSYS2... > > I'm on vacation until September. But I can help if any work starting in this direction. Regards, Alexey. > Corinna > > -- > Corinna Vinschen Please, send mails regarding Cygwin to > Cygwin Maintainer cygwin AT cygwin DOT com > Red Hat ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: MSYS mode (continue) 2013-07-30 9:32 ` Alexey Pavlov @ 2013-07-30 9:47 ` Corinna Vinschen 2013-07-30 10:27 ` Alexey Pavlov 0 siblings, 1 reply; 52+ messages in thread From: Corinna Vinschen @ 2013-07-30 9:47 UTC (permalink / raw) To: cygwin-developers On Jul 30 13:32, Alexey Pavlov wrote: > 2013/7/30 Corinna Vinschen > > > > On Jul 30 04:45, LRN wrote: > > > On 29.07.2013 19:47, Corinna Vinschen wrote: > > > > On Jul 29 19:36, LRN wrote: > > > >> I would expect people to get cygwin/msys in one place, and get MinGW in > > > >> another. Even mingw-get, while being a source of both msys and mingw > > > >> packages, clearly distinguishes betweent he two. > > > > > > > > That's what I understood differently. From the discussion on mingw-w64 > > > > it seemed that a mingw dev using Cygwin/MSYS would prefer if the default > > > > gcc creates non-CYgwin/MSYS, but rather Windows-only binaries. > > > > > > The problem is not that you can't have a W32-targetted gcc.exe in /usr/bin. > > > > > > The problem is that the convention that everyone has been following for > > > years now is that all mingw stuff lives in /mingw, and all msys (cygwin) > > > stuff lives in /usr. These two are never mixed. > > > [...] > > > So i'd suggest to stick with /usr and /mingw convention and let mingw > > > take care of itself. It's simpler that way. > > > > Fine with me, of course. I don't have that problem myself so whatever > > works better for you is ok. But then the number of changed packages > > doesn't really matter. From my POV MSYS sticks to being it's own distro > > with another focus than the Cygwin distro. > > > > So we're back to discussing in how far MSYS can be implemented using a > > stock Cygwin DLL under the hood and the tweaks being in an external MSYS > > DLL so users can mix the best of both worlds as they see fit for their > > purpose. > > > > As I see all discussion not about implementing but about philosophy of > MSYS. No. We were talking about how to implement the changes. Your patches change Cygwin directly, but the idea is to keep the actual changes separate, outside of Cygwin, as hooks. > At the start of discussion I wrote about my changes in Cygwin > sources to have MSYS. And also send small patches but nothing really > doing in this direction. > What steps do we need to start any work on implementing it? > Now I see next points where we can change Cygwin functionality: > 1. uname function > 2. reading /etc/fstab > 3. passing arguments and environment variables to non-Cygwin > processes ( environ.cc, spawn.cc ) > 4. symlinks changes (copy instead symlink) Yes, these are the behavioral changes you want to implement, but this is the discussion as to *how* to implement them. You never actually took part in this discssion yet. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: MSYS mode (continue) 2013-07-30 9:47 ` Corinna Vinschen @ 2013-07-30 10:27 ` Alexey Pavlov 2013-07-30 10:34 ` Corinna Vinschen 0 siblings, 1 reply; 52+ messages in thread From: Alexey Pavlov @ 2013-07-30 10:27 UTC (permalink / raw) To: cygwin-developers 2013/7/30 Corinna Vinschen: > On Jul 30 13:32, Alexey Pavlov wrote: >> 2013/7/30 Corinna Vinschen >> > >> > On Jul 30 04:45, LRN wrote: >> > > On 29.07.2013 19:47, Corinna Vinschen wrote: >> > > > On Jul 29 19:36, LRN wrote: >> > > >> I would expect people to get cygwin/msys in one place, and get MinGW in >> > > >> another. Even mingw-get, while being a source of both msys and mingw >> > > >> packages, clearly distinguishes betweent he two. >> > > > >> > > > That's what I understood differently. From the discussion on mingw-w64 >> > > > it seemed that a mingw dev using Cygwin/MSYS would prefer if the default >> > > > gcc creates non-CYgwin/MSYS, but rather Windows-only binaries. >> > > >> > > The problem is not that you can't have a W32-targetted gcc.exe in /usr/bin. >> > > >> > > The problem is that the convention that everyone has been following for >> > > years now is that all mingw stuff lives in /mingw, and all msys (cygwin) >> > > stuff lives in /usr. These two are never mixed. >> > > [...] >> > > So i'd suggest to stick with /usr and /mingw convention and let mingw >> > > take care of itself. It's simpler that way. >> > >> > Fine with me, of course. I don't have that problem myself so whatever >> > works better for you is ok. But then the number of changed packages >> > doesn't really matter. From my POV MSYS sticks to being it's own distro >> > with another focus than the Cygwin distro. >> > >> > So we're back to discussing in how far MSYS can be implemented using a >> > stock Cygwin DLL under the hood and the tweaks being in an external MSYS >> > DLL so users can mix the best of both worlds as they see fit for their >> > purpose. >> > >> >> As I see all discussion not about implementing but about philosophy of >> MSYS. > > No. We were talking about how to implement the changes. Your patches > change Cygwin directly, but the idea is to keep the actual changes > separate, outside of Cygwin, as hooks. > >> At the start of discussion I wrote about my changes in Cygwin >> sources to have MSYS. And also send small patches but nothing really >> doing in this direction. >> What steps do we need to start any work on implementing it? >> Now I see next points where we can change Cygwin functionality: >> 1. uname function >> 2. reading /etc/fstab >> 3. passing arguments and environment variables to non-Cygwin >> processes ( environ.cc, spawn.cc ) >> 4. symlinks changes (copy instead symlink) > > Yes, these are the behavioral changes you want to implement, but this is > the discussion as to *how* to implement them. You never actually took > part in this discssion yet. > Now there are not many changes that I do in Cygwin sources and it change only small functionality without breaking anything for cygwin users (only symlinks is breaking thing). If we need to implement changes in external DLL we doesn't want to full rewrite modified functions in this DLL. External DLL need only do changes inside the Cygwin functions not full replace this functions I think. Maybe you create separate branch in CVS source where we can try to implement MSYS mode and also create hook in uname function, for example, to try how it work? From my POV we need to create separate distro for MSYS where in bash profile we can activate MSYS mode for Cygwin.dll with some environment variable that tell to load msys.dll. But if you want has working applications between normal Cygwin and msys-in-cygwin then they need to be linked only with cygwin.dll and doesn't need to know anything about msys.dll. > > Corinna > > -- > Corinna Vinschen Please, send mails regarding Cygwin to > Cygwin Maintainer cygwin AT cygwin DOT com > Red Hat ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: MSYS mode (continue) 2013-07-30 10:27 ` Alexey Pavlov @ 2013-07-30 10:34 ` Corinna Vinschen 2013-07-30 10:59 ` Alexey Pavlov 0 siblings, 1 reply; 52+ messages in thread From: Corinna Vinschen @ 2013-07-30 10:34 UTC (permalink / raw) To: cygwin-developers On Jul 30 14:27, Alexey Pavlov wrote: > 2013/7/30 Corinna Vinschen: > > On Jul 30 13:32, Alexey Pavlov wrote: > >> 2013/7/30 Corinna Vinschen > >> > > >> > On Jul 30 04:45, LRN wrote: > >> > > On 29.07.2013 19:47, Corinna Vinschen wrote: > >> > > > On Jul 29 19:36, LRN wrote: > >> > > >> I would expect people to get cygwin/msys in one place, and get MinGW in > >> > > >> another. Even mingw-get, while being a source of both msys and mingw > >> > > >> packages, clearly distinguishes betweent he two. > >> > > > > >> > > > That's what I understood differently. From the discussion on mingw-w64 > >> > > > it seemed that a mingw dev using Cygwin/MSYS would prefer if the default > >> > > > gcc creates non-CYgwin/MSYS, but rather Windows-only binaries. > >> > > > >> > > The problem is not that you can't have a W32-targetted gcc.exe in /usr/bin. > >> > > > >> > > The problem is that the convention that everyone has been following for > >> > > years now is that all mingw stuff lives in /mingw, and all msys (cygwin) > >> > > stuff lives in /usr. These two are never mixed. > >> > > [...] > >> > > So i'd suggest to stick with /usr and /mingw convention and let mingw > >> > > take care of itself. It's simpler that way. > >> > > >> > Fine with me, of course. I don't have that problem myself so whatever > >> > works better for you is ok. But then the number of changed packages > >> > doesn't really matter. From my POV MSYS sticks to being it's own distro > >> > with another focus than the Cygwin distro. > >> > > >> > So we're back to discussing in how far MSYS can be implemented using a > >> > stock Cygwin DLL under the hood and the tweaks being in an external MSYS > >> > DLL so users can mix the best of both worlds as they see fit for their > >> > purpose. > >> > > >> > >> As I see all discussion not about implementing but about philosophy of > >> MSYS. > > > > No. We were talking about how to implement the changes. Your patches > > change Cygwin directly, but the idea is to keep the actual changes > > separate, outside of Cygwin, as hooks. > > > >> At the start of discussion I wrote about my changes in Cygwin > >> sources to have MSYS. And also send small patches but nothing really > >> doing in this direction. > >> What steps do we need to start any work on implementing it? > >> Now I see next points where we can change Cygwin functionality: > >> 1. uname function > >> 2. reading /etc/fstab > >> 3. passing arguments and environment variables to non-Cygwin > >> processes ( environ.cc, spawn.cc ) > >> 4. symlinks changes (copy instead symlink) > > > > Yes, these are the behavioral changes you want to implement, but this is > > the discussion as to *how* to implement them. You never actually took > > part in this discssion yet. > > > > Now there are not many changes that I do in Cygwin sources and it > change only small functionality without breaking anything for cygwin > users (only symlinks is breaking thing). > If we need to implement changes in external DLL we doesn't want to > full rewrite modified functions in this DLL. External DLL need only do > changes inside the Cygwin functions not full replace this functions I > think. That was part of cgf's original proposal. We have the CW_HOOK mechanism to overload entire functions (per the discussion not fully implemented yet) but there's no problem to implement a kind of mini-hook with a set of function pointers called from the CYgwin DLL at certain, yet to be defined points. > Maybe you create separate branch in CVS source where we can try to > implement MSYS mode and also create hook in uname function, for > example, to try how it work? That should be possible. > >From my POV we need to create separate distro for MSYS where in bash > profile we can activate MSYS mode for Cygwin.dll with some environment > variable that tell to load msys.dll. But if you want has working > applications between normal Cygwin and msys-in-cygwin then they need > to be linked only with cygwin.dll and doesn't need to know anything > about msys.dll. Exactly. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: MSYS mode (continue) 2013-07-30 10:34 ` Corinna Vinschen @ 2013-07-30 10:59 ` Alexey Pavlov 2013-07-30 14:55 ` Christopher Faylor 0 siblings, 1 reply; 52+ messages in thread From: Alexey Pavlov @ 2013-07-30 10:59 UTC (permalink / raw) To: cygwin-developers 2013/7/30 Corinna Vinschen: > On Jul 30 14:27, Alexey Pavlov wrote: >> 2013/7/30 Corinna Vinschen: >> > On Jul 30 13:32, Alexey Pavlov wrote: >> >> 2013/7/30 Corinna Vinschen >> >> > >> >> > On Jul 30 04:45, LRN wrote: >> >> > > On 29.07.2013 19:47, Corinna Vinschen wrote: >> >> > > > On Jul 29 19:36, LRN wrote: >> >> > > >> I would expect people to get cygwin/msys in one place, and get MinGW in >> >> > > >> another. Even mingw-get, while being a source of both msys and mingw >> >> > > >> packages, clearly distinguishes betweent he two. >> >> > > > >> >> > > > That's what I understood differently. From the discussion on mingw-w64 >> >> > > > it seemed that a mingw dev using Cygwin/MSYS would prefer if the default >> >> > > > gcc creates non-CYgwin/MSYS, but rather Windows-only binaries. >> >> > > >> >> > > The problem is not that you can't have a W32-targetted gcc.exe in /usr/bin. >> >> > > >> >> > > The problem is that the convention that everyone has been following for >> >> > > years now is that all mingw stuff lives in /mingw, and all msys (cygwin) >> >> > > stuff lives in /usr. These two are never mixed. >> >> > > [...] >> >> > > So i'd suggest to stick with /usr and /mingw convention and let mingw >> >> > > take care of itself. It's simpler that way. >> >> > >> >> > Fine with me, of course. I don't have that problem myself so whatever >> >> > works better for you is ok. But then the number of changed packages >> >> > doesn't really matter. From my POV MSYS sticks to being it's own distro >> >> > with another focus than the Cygwin distro. >> >> > >> >> > So we're back to discussing in how far MSYS can be implemented using a >> >> > stock Cygwin DLL under the hood and the tweaks being in an external MSYS >> >> > DLL so users can mix the best of both worlds as they see fit for their >> >> > purpose. >> >> > >> >> >> >> As I see all discussion not about implementing but about philosophy of >> >> MSYS. >> > >> > No. We were talking about how to implement the changes. Your patches >> > change Cygwin directly, but the idea is to keep the actual changes >> > separate, outside of Cygwin, as hooks. >> > >> >> At the start of discussion I wrote about my changes in Cygwin >> >> sources to have MSYS. And also send small patches but nothing really >> >> doing in this direction. >> >> What steps do we need to start any work on implementing it? >> >> Now I see next points where we can change Cygwin functionality: >> >> 1. uname function >> >> 2. reading /etc/fstab >> >> 3. passing arguments and environment variables to non-Cygwin >> >> processes ( environ.cc, spawn.cc ) >> >> 4. symlinks changes (copy instead symlink) >> > >> > Yes, these are the behavioral changes you want to implement, but this is >> > the discussion as to *how* to implement them. You never actually took >> > part in this discssion yet. >> > >> >> Now there are not many changes that I do in Cygwin sources and it >> change only small functionality without breaking anything for cygwin >> users (only symlinks is breaking thing). >> If we need to implement changes in external DLL we doesn't want to >> full rewrite modified functions in this DLL. External DLL need only do >> changes inside the Cygwin functions not full replace this functions I >> think. > > That was part of cgf's original proposal. We have the CW_HOOK mechanism > to overload entire functions (per the discussion not fully implemented > yet) but there's no problem to implement a kind of mini-hook with a > set of function pointers called from the CYgwin DLL at certain, yet to > be defined points. > We need to determine places where you need to create hooks in Cygwin.dll and also prototypes for external functions (input and output arguments). Msys mode only change functions for non-Cygwin applications and in this case where it can be handled? In cygwin.dll or in msys.dll? For example, when we pass arguments to new process we determine in Cygwin is new process depends on cygwin.dll or not and make decision about changing arguments. If new process is non-cygwin then we try to change arguments else we leave them as is. If we need do implement decision logic in msys.dll then we need to rewrite many code. But if we implement it in Cygwin dll then it was simple like this: if (!iscygexec() && msysmode) { // hook to function from msys.dll } else { // default cygwin code } In this case we can create mini-hooks in cygwin DLL that call functions from msys.dll if necessary. >> Maybe you create separate branch in CVS source where we can try to >> implement MSYS mode and also create hook in uname function, for >> example, to try how it work? > > That should be possible. > >> >From my POV we need to create separate distro for MSYS where in bash >> profile we can activate MSYS mode for Cygwin.dll with some environment >> variable that tell to load msys.dll. But if you want has working >> applications between normal Cygwin and msys-in-cygwin then they need >> to be linked only with cygwin.dll and doesn't need to know anything >> about msys.dll. > > Exactly. > > > Corinna > > -- > Corinna Vinschen Please, send mails regarding Cygwin to > Cygwin Maintainer cygwin AT cygwin DOT com > Red Hat ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: MSYS mode (continue) 2013-07-30 10:59 ` Alexey Pavlov @ 2013-07-30 14:55 ` Christopher Faylor 2013-07-30 15:43 ` Christopher Faylor 2013-07-30 16:14 ` Christopher Faylor 0 siblings, 2 replies; 52+ messages in thread From: Christopher Faylor @ 2013-07-30 14:55 UTC (permalink / raw) To: cygwin-developers On Tue, Jul 30, 2013 at 02:59:40PM +0400, Alexey Pavlov wrote: >We need to determine places where you need to create hooks in >Cygwin.dll and also prototypes for external functions (input and >output arguments). Msys mode only change functions for non-Cygwin >applications and in this case where it can be handled? In cygwin.dll >or in msys.dll? This is the outstanding question for the last month or so. >For example, when we pass arguments to new process we determine in >Cygwin is new process depends on cygwin.dll or not and make decision >about changing arguments. If new process is non-cygwin then we try to >change arguments else we leave them as is. If we need do implement >decision logic in msys.dll then we need to rewrite many code. But if >we implement it in Cygwin dll then it was simple like this: No. In the spawn function, you have something like: if (!callout (CO_SPAWN, mode, &argv, &argc)) ... And a DLL which has been preloaded and registered with cygwin1.dll will modify the arguments as needed. Either that or, the other proposal is that MSYS could just use LD_PRELOAD but, as attractive as the notion of not modifying Cygwin at all might be, it would mean that the MSYS dll would have to do a lot more work for the above scenario because it would have to emulate a lot of what Cygwin does to emulate exec/spawn. So, in the interests of moving this discussion along, here is a more fleshed out proposal: Any helper DLL would be registered using a CYGWIN environment variable preload keyword: set CYGWIN=preload:msys.dll An error will be issued if Cygwin can't find the preload dll. The DLL will register callouts via: cygwin_internal (CW_CALLOUT, function_which_handles_callouts); Callout Arguments CO_SPAWN mode (value), argv (reference), argc (reference) CO_UNAME utsname (reference) CO_ENV envp (reference) CO_SYMLINK is_native_symlink (value), oldpath (reference), newpath (reference)* CW_MALLOC Amount of cygheap memory to allocate *Choosing where to call this might be tricky. I don't see any reason why MSYS shouldn't avail itself of the new native symlinks if they can be created. Otherwise, symlink would have to be short-circuited in some cases so maybe we need to check the return value of the callout function: ... switch (callout (CW_SYMLINK, is_native_symlink, &oldpath, &newpath)) { case CO_R_KEEP_GOING: break; case CO_R_SHORT_CIRCUIT: return 0; case CO_R_ERR: return -1; } ... The callout function will look something like: enum callout_return callout (enum callout co, ...) { if (!callout_func) return CO_R_KEEP_GOING; va_list ap; va_start (ap, co); return callout_func (co, ap); } (I have to think about the most efficient way to implement this) What other CO_* values are needed? cgf ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: MSYS mode (continue) 2013-07-30 14:55 ` Christopher Faylor @ 2013-07-30 15:43 ` Christopher Faylor 2013-07-30 16:14 ` Christopher Faylor 1 sibling, 0 replies; 52+ messages in thread From: Christopher Faylor @ 2013-07-30 15:43 UTC (permalink / raw) To: cygwin-developers On Tue, Jul 30, 2013 at 10:55:33AM -0400, Christopher Faylor wrote: >On Tue, Jul 30, 2013 at 02:59:40PM +0400, Alexey Pavlov wrote: >>We need to determine places where you need to create hooks in >>Cygwin.dll and also prototypes for external functions (input and >>output arguments). Msys mode only change functions for non-Cygwin >>applications and in this case where it can be handled? In cygwin.dll >>or in msys.dll? > >This is the outstanding question for the last month or so. > >>For example, when we pass arguments to new process we determine in >>Cygwin is new process depends on cygwin.dll or not and make decision >>about changing arguments. If new process is non-cygwin then we try to >>change arguments else we leave them as is. If we need do implement >>decision logic in msys.dll then we need to rewrite many code. But if >>we implement it in Cygwin dll then it was simple like this: > >No. In the spawn function, you have something like: > > if (!callout (CO_SPAWN, mode, &argv, &argc)) > ... > >And a DLL which has been preloaded and registered with cygwin1.dll will >modify the arguments as needed. > >Either that or, the other proposal is that MSYS could just use LD_PRELOAD >but, as attractive as the notion of not modifying Cygwin at all might be, >it would mean that the MSYS dll would have to do a lot more work for >the above scenario because it would have to emulate a lot of what Cygwin >does to emulate exec/spawn. > >So, in the interests of moving this discussion along, here is a more >fleshed out proposal: > >Any helper DLL would be registered using a CYGWIN environment variable >preload keyword: > >set CYGWIN=preload:msys.dll > >An error will be issued if Cygwin can't find the preload dll. > >The DLL will register callouts via: > >cygwin_internal (CW_CALLOUT, function_which_handles_callouts); > >Callout Arguments >CO_SPAWN mode (value), argv (reference), argc (reference) >CO_UNAME utsname (reference) >CO_ENV envp (reference) >CO_SYMLINK is_native_symlink (value), oldpath (reference), newpath (reference)* >CW_MALLOC Amount of cygheap memory to allocate I just implemented some of this and I'm wondering if we might need some way of controlling the flow on entry to a function and on exit. So maybe the above could be implemented as: CO_UNAME_ENTRY CO_UNAME_EXIT but that might be overkill. It wouldn't necessarily make sense for CO_SPAWN either. cgf ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: MSYS mode (continue) 2013-07-30 14:55 ` Christopher Faylor 2013-07-30 15:43 ` Christopher Faylor @ 2013-07-30 16:14 ` Christopher Faylor 1 sibling, 0 replies; 52+ messages in thread From: Christopher Faylor @ 2013-07-30 16:14 UTC (permalink / raw) To: cygwin-developers On Tue, Jul 30, 2013 at 10:55:33AM -0400, Christopher Faylor wrote: >CW_MALLOC Amount of cygheap memory to allocate I didn't make it clear that this would be a cygwin_internal() call. cgf ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: MSYS mode (continue) 2013-07-29 11:00 ` LRN 2013-07-29 11:19 ` Corinna Vinschen @ 2013-07-29 11:19 ` Earnie Boyd 2013-07-29 12:20 ` Charles Wilson 1 sibling, 1 reply; 52+ messages in thread From: Earnie Boyd @ 2013-07-29 11:19 UTC (permalink / raw) To: cygwin-developers On Mon, Jul 29, 2013 at 7:00 AM, LRN wrote: >> - make w/ DOS path handling > Yes. Note that the code DOES exist in make, but is disabled when make is > built for Cygwin. One might question whether it was a good idea to > disable support for W32 paths in make that runs on W32 (with a > compatibility layer, but still...) in the first place. > MSYS has never modified the make source and it uses the CYGWIN coding. The only thing is we do accept windows pathing in the form of C:/SOME/DIR but not C:\SOME\DIR. The only thing I know that is currently changed is bash to add a -W option to pwd. That should be carried forward to /bin/pwd but that currently isn't the case. All of the path handling magic happens in msys-1.0.dll. The other thing that happens are chosen sane defaults for the options provided by CYGWIN so that users reporting errors wouldn't have the chance to screw with a known set of configuration and the CYGWIN variable is thus ignored. And all file handles are set to _O_BINARY without the ability to change it; I don't know if that matters for the current version of Cygwin but mentioning it just in case. -- Earnie -- https://sites.google.com/site/earnieboyd ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: MSYS mode (continue) 2013-07-29 11:19 ` Earnie Boyd @ 2013-07-29 12:20 ` Charles Wilson 2013-07-29 12:49 ` Corinna Vinschen 2013-07-29 18:11 ` Larry Hall (Cygwin Developers) 0 siblings, 2 replies; 52+ messages in thread From: Charles Wilson @ 2013-07-29 12:20 UTC (permalink / raw) To: cygwin-developers On 7/29/2013 7:19 AM, Earnie Boyd wrote: > On Mon, Jul 29, 2013 at 7:00 AM, LRN wrote: >>> - make w/ DOS path handling >> Yes. Note that the code DOES exist in make, but is disabled when make is >> built for Cygwin. One might question whether it was a good idea to >> disable support for W32 paths in make that runs on W32 (with a >> compatibility layer, but still...) in the first place. >> > > MSYS has never modified the make source and it uses the CYGWIN coding. > The only thing is we do accept windows pathing in the form of > C:/SOME/DIR but not C:\SOME\DIR. No. Here's the patches applied to msys's make-3.81 make/01-make-3.81-2-cygwin.patch -- from cygwin's 3.81-2 package make/02-make-3.81-dos-path.patch make/03-make-3.81-case_preserve.patch make/04-make-3.81-msys.patch I've archives all the patches I used when I last built the msys apps -- it's over 1MB after xz compression. I'll figure out somewhere to put it and post the link later today. Here's the file listing -- 151 different patches to 56 different products. Some were unofficial, since I never actually published my msys-tcl port. expat/expat-2.0.1-1-msys.patch libiconv/00-wchar-libiconv-1.14.patch libiconv/01-undo-cygwin17-reloc-libiconv-1.14.patch libiconv/02-reloc-libiconv-1.14.patch libiconv/03-cygwin-libiconv-1.14.patch libiconv/libiconv-1.13.1-2-msys.patch libiconv/libiconv-1.14-1.msys.patch libiconv/libiconv-1.14-1.src.patch autoconf/autoconf-2.67-1-msys.patch autoconf/autoconf-2.68-1.msys.patch autoconf/autoconf-2.68-1.src.patch autogen/autogen-5.10.1-1-msys.patch automake/automake-1.11.1-1-msys.patch bash/01-bash-3.1-msys.patch bison/bison-2.4.2-1-msys.patch bzip2/01-cygming-bzip2-1.0.6.src.patch bzip2/bzgrep-debian-1.0.5-6.patch bzip2/bzip2-1.0.4-bzip2recover.patch bzip2/bzip2-1.0.6-1.msys.patch bzip2/bzip2-1.0.6-1.src.patch bzip2/bzip2-1.0.6-3.mgw.patch bzip2/bzip2-1.0.6-progress.patch coreutils/01-coreutils-5.97-1-cygwin.patch coreutils/02-coreutils-5.97-3-msys.patch coreutils/03-coreutils-5.97-2-autoreconf.patch coreutils/04-coreutils-5.97-3-more-autoreconf.patch crypt/crypt-1.1_1-3-msys.patch cvs/9991-cvs-1.12.13-10-cygwin-src.patch cvs/9992-cvs-1.12.13-10-cygwin-ext.patch cvs/9993-cvs-1.12.13-2-msys.patch cvs/9994-cvs-1.12.13-po-template.patch cygutils/cygutils-1.3.4-3-msys-unmerged.patch cygutils/cygutils-1.3.4-4-msys.patch dash/01-cygwin-dash-0.5.5.1-2.patch dash/02-msys-dash-0.5.5.1.patch diffutils/01-diffutils-2.8.7-3-gnulib.patch diffutils/02-diffutils-2.8.7-3-msys.patch libtool/0001-Fix-regression-in-command-line-length-computation.patch libtool/0002-cygwin-mingw-Create-UAC-manifest-files.patch libtool/0003-Pass-various-runtime-library-flags-to-GCC.patch libtool/0004-Fix-linking-with-fstack-protector.patch libtool/0005-msys-support.patch libxml2/2.7.3-doc-install.patch libxml2/libxml2-2.7.6-1-msys.patch lndir/lndir-1.0.1-2-msys.patch m4/01-m4-1.4.14-1-msys.patch make/01-make-3.81-2-cygwin.patch make/02-make-3.81-dos-path.patch make/03-make-3.81-case_preserve.patch make/04-make-3.81-msys.patch man/01-man-1.6e-1-cygwin-src-fwdprt.patch man/02-man-1.6f-2-msys.patch minires/minires-1.01-1.patch minires/minires-1.02_1-2-msys.patch mktemp/mktemp-1.6-2-msys.patch msysCORE/foo.patch msysCORE-old/all-deltas.patch msysCORE-old/build-machinery-1.0.15.patch msysCORE-old/pseudo-reloc-fork-fix.patch openssh/01-openssh-5.4p1-msys.patch openssl/01-msys-initial.patch openssl/openssl-0.9.6-x509.patch openssl/openssl-0.9.7-beta5-version-add-engines.patch openssl/openssl-0.9.8e-crt.patch patch/9991-patch-2.5.8-9-cygwin-src-fwdprt.patch patch/9992-patch-2.6.1-1-msys.patch patch/msys-build-patch perl-old/perl-5.6.1_2-1-msys.patch popt/01-popt-0.15-2-msys.patch rebase/rebase-4.0.1_1-1.msys.patch rebase/rebase-4.0.1_1-1.src.patch rsync/01-rsync-3.0.8-msys.patch rxvt/991-rxvt-2.7.2-msys-dll-name.patch rxvt/900-rxvt-2.7.2-yodl.patch rxvt/901-rxvt-2.7.2-doc.patch rxvt/902-rxvt-2.7.2-changelogs.patch rxvt/903-rxvt-2.7.2-remove-files.patch rxvt/904-rxvt-2.7.2-msys-orig.patch rxvt/905-rxvt-2.7.2-license.patch rxvt/990-rxvt-2.7.2-msys-3.patch rxvt/992-rxvt-2.7.2-msys-fixup-resources.patch sed/sed-4.2.1-2-msys.patch tar/990-tar-1.22-1-cygwin-fwdport.patch tar/991-tar-1.23-1-msys.patch tar/992-silence-record-size-warning.patch tcl/03-cygwin-un-win32ify.patch tcl/04-cygwin-env-sync.patch tcl/05-msys-libprefix-load.patch tcl/06-cygwin-nocolons.patch tcl/07-msys-termio-without-parext.patch tcl/08-msys-workaround-stdhandles-ebadf.patch tcl/09-cygwin-use-autoimport.patch tcl/10-cygwin-msys-libprefix-build.patch tcl/11-msys-tcl-m4.patch tcl/8.5-cygwin.patch tcl/8.5.10-tea-m4.patch tcl/tcl-8.5.11-1.msys.patch termcap/termcap-0.20050421_1-2-msys.patch texinfo/9991-texinfo-4.13-3-cygwin-src.patch texinfo/9992-texinfo-4.13a-1-msys-gnulib-updates.patch texinfo/9993-texinfo-4.13a-2-msys-other.patch texinfo/9994-texinfo-4.13a-3-msys-libintl.patch unzip/01-unzip-6.0-10-cygwin.patch unzip/02-unzip-6.0-1-msys.patch unzip/bzip2-1.0.5-10.partial-src.patch vim/vim-7.2-2-msys.patch wget/01-wget-1.12-1-msys.patch xz/01-cygwin-xz-5.0.2-1.patch xz/02-msys-missing-stdint-inttypes.patch xz/03-msys-getopt-workaround.patch xz/04-msys-other.patch xz/xz-5.0.3-1.msys.patch xz/xz-rollup-fixes-7fcc6334.patch zip/bzip2-1.0.5-10.partial-src.patch zip/zip-3.0-1-msys.patch zip/zip-3.0-11.src.patch zip/zip-3.0-build.patch file/9991-file-5.00-3-cygwin-src-partial.patch file/9992-file-5.04-1-msys.patch findutils/01-findutils-4.4.0-3-cygwin-src-fwdprt.patch findutils/02-findutils-4.4.2-2-msys.patch flex/flex-2.5.35-2-msys.patch flex/flex-debian-2.5.35-7-partial.patch gawk/999-gawk-3.1.7-2-msys.patch gdbm/gdbm-1.8.3-3-msys.patch gettext/gettext-0.18.1.1-1.msys.patch gettext/gettext-0.18.1.1-1.src.patch gettext/00-slowdown-cvs-archive-creation.patch gettext/01-msys-fixes.patch gettext/02-locale-gettext-0.18.1.1.patch gettext/03-cygwin-gettext-0.18.1.1.patch gettext/04-mingw-script-slash-fix.patch gmp/gmp-5.0.1-1-msys.patch grep/999-grep-2.5.4-2-msys.patch groff/01-doc-gfdl-msys.patch groff/02-msys-install.patch guile/guile-1.8.7-2-msys.patch gzip/9991-grep-1.3.12-2-cygwin-src.patch gzip/9992-grep-1.3.12-2-msys.patch inetutils/01-buildsystem-updates.patch inetutils/02-gnulib_20100205-updates.patch inetutils/03-autoreconf-updates.patch inetutils/04-documentation-updates.patch inetutils/05-missing-headers.patch inetutils/06-cygwin-1.7-1pre-unofficial.patch inetutils/07-msys-missing-headers.patch inetutils/08-msys-fixups.patch inetutils/09-msys-replace-rfunc-for-vista.patch less/01-434417-LESS_IS_MORE.patch less/02-less-429-1-cygwin-src.patch libarchive/01-libarchive-msys-initial.patch This also misses the changes to the build configurations (e.g. msys builds foo with --disable-bar, while cygwin uses --enable-bar, etc). -- Chuck ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: MSYS mode (continue) 2013-07-29 12:20 ` Charles Wilson @ 2013-07-29 12:49 ` Corinna Vinschen 2013-07-29 14:22 ` Charles Wilson 2013-07-29 18:11 ` Larry Hall (Cygwin Developers) 1 sibling, 1 reply; 52+ messages in thread From: Corinna Vinschen @ 2013-07-29 12:49 UTC (permalink / raw) To: cygwin-developers On Jul 29 08:20, Charles Wilson wrote: > On 7/29/2013 7:19 AM, Earnie Boyd wrote: > >On Mon, Jul 29, 2013 at 7:00 AM, LRN wrote: > >>>- make w/ DOS path handling > >>Yes. Note that the code DOES exist in make, but is disabled when make is > >>built for Cygwin. One might question whether it was a good idea to > >>disable support for W32 paths in make that runs on W32 (with a > >>compatibility layer, but still...) in the first place. > >> > > > >MSYS has never modified the make source and it uses the CYGWIN coding. > > The only thing is we do accept windows pathing in the form of > >C:/SOME/DIR but not C:\SOME\DIR. > > No. > > Here's the patches applied to msys's make-3.81 > > make/01-make-3.81-2-cygwin.patch -- from cygwin's 3.81-2 package > make/02-make-3.81-dos-path.patch > make/03-make-3.81-case_preserve.patch > make/04-make-3.81-msys.patch > > I've archives all the patches I used when I last built the msys apps > -- it's over 1MB after xz compression. I'll figure out somewhere to > put it and post the link later today. > > Here's the file listing -- 151 different patches to 56 different > products. Some were unofficial, since I never actually published my > msys-tcl port. The question is, are they really necessary? I seriously doubt that you have to patch inetutils beyond what's required for Cygwin, unless you want the kitchen sink to work with DOS paths. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: MSYS mode (continue) 2013-07-29 12:49 ` Corinna Vinschen @ 2013-07-29 14:22 ` Charles Wilson 0 siblings, 0 replies; 52+ messages in thread From: Charles Wilson @ 2013-07-29 14:22 UTC (permalink / raw) To: cygwin-developers [-- Attachment #1: Type: text/plain, Size: 3416 bytes --] On 7/29/2013 8:49 AM, Corinna Vinschen wrote: > The question is, are they really necessary? I seriously doubt that you > have to patch inetutils beyond what's required for Cygwin, unless you > want the kitchen sink to work with DOS paths. They *were* necessary for msys-1, given the following: 1) msys itself was very old, and had only cygwin-1.3.4 era capabilities 2) the msys targetting compiler is to this day ALSO very old: it's based on gcc-3.4.4 if you can believe it. Now, it is certainly true that in the new "era" with msys-on-cygwin, point #1 above is no longer applicable. And, because there really won't be an msys target compiler, just the plain old cygwin one (with -DMSYS [1] and, depending on how the msys hook dll gets loaded, perhaps -lmsys), then msys apps no longer have to work around old-gcc breakage. But there are still some patches that will be necessary, and I'm afraid only experience will tell us which ones. My set of 151 patches to 56 packages [2] is probably the "outer limit"; some packages might be workable with no special msys changes, others might only need a small subset of what was previously necessary. Let's go back to our favorite example, msys-make: make/01-make-3.81-2-cygwin.patch -------------------------------- from cygwin's 3.81-2 package, so this is not interesting when we're discussing *differences* between the cygwin and "msys" versions make/02-make-3.81-dos-path.patch -------------------------------- * configure.in (PATH_SEPARATOR_CHAR): Define to the value of $PATH_SEPARATOR. * make.h (PATH_SEPARATOR_CHAR): Define only if still undefined. Normally, it is defined in config.h. * config/dospaths.m4 <ac_cv_dos_paths>: Define to yes on Cygwin as well. * job.c (construct_command_argv_internal) [HAVE_DOS_PATHS]: Define sh_chars_sh for Windows platforms that emulate Unix. This *might* be in make-3.82.90, I'm not sure. But for msys we need to ensure that ac_cv_dos_paths is "yes", regardless of whether it is yes or no on cygwin. make/03-make-3.81-case_preserve.patch -------------------------------- case-insensitive but case-preserving rule matching. Pretty sure "real" cygwin doesn't want, and doesn't have, this one. Over in mingw/msys land we went round and round with "csmake" (case sensitive), "cpmake" (this one), and "regular" make, and finally decided that cpmake had the fewest drawbacks when working with "native" gcc... make/04-make-3.81-msys.patch -------------------------------- build system changes. In configure.in, the original AC_SUBSTs didn't do the right thing and needed to use a more modern idiom. In Makefile.am, the test driver section relied on symlinks, which are obviously broken in "old" msys. I think we're all pretty much on the same page, that "msys" needs a special version of make. Does bash need to be different? probably. Perl...maybe??? inetutils (clients only) -- I think some of these changes^Wcripplings are necessary, regardless of the "environment" improvements that modernizing msys and its associated gcc bring. But it'll just have to be on a case-by-case basis. I've uploaded my entire msys patch collection [2] in case anyone is really crazy^Winterested... [1] This will still be needed because of the msys-*behavioral* patches that are still going to be necessary, in some cases... [2] http://mingw.cwilson.fastmail.fm/msys-patches.tar.xz -- Chuck [-- Attachment #2: 02-make-3.81-dos-path.patch --] [-- Type: text/plain, Size: 2809 bytes --] 2006-08-18 Eli Zaretskii <address@hidden> * configure.in (PATH_SEPARATOR_CHAR): Define to the value of $PATH_SEPARATOR. * make.h (PATH_SEPARATOR_CHAR): Define only if still undefined. Normally, it is defined in config.h. * config/dospaths.m4 <ac_cv_dos_paths>: Define to yes on Cygwin as well. * job.c (construct_command_argv_internal) [HAVE_DOS_PATHS]: Define sh_chars_sh for Windows platforms that emulate Unix. --- old/make-3.81/configure.in 2006-04-01 12:36:40.000000000 +0300 +++ new/make-3.81/configure.in 2006-08-18 21:12:32.828125000 +0300 @@ -384,6 +384,8 @@ ;; esac +AC_DEFINE_UNQUOTED(PATH_SEPARATOR_CHAR,'$PATH_SEPARATOR',[Define to the character that separates directories in PATH.]) + # Include the Maintainer's Makefile section, if it's here. MAINT_MAKEFILE=/dev/null --- old/make-3.81/make.h 2006-02-16 03:54:43.000000000 +0200 +++ new/make-3.81/make.h 2006-08-18 21:12:32.859375000 +0300 @@ -347,12 +347,14 @@ #define S_(msg1,msg2,num) ngettext (msg1,msg2,num) /* Handle other OSs. */ -#if defined(HAVE_DOS_PATHS) -# define PATH_SEPARATOR_CHAR ';' -#elif defined(VMS) -# define PATH_SEPARATOR_CHAR ',' -#else -# define PATH_SEPARATOR_CHAR ':' +#ifndef PATH_SEPARATOR_CHAR +# if defined(HAVE_DOS_PATHS) +# define PATH_SEPARATOR_CHAR ';' +# elif defined(VMS) +# define PATH_SEPARATOR_CHAR ',' +# else +# define PATH_SEPARATOR_CHAR ':' +# endif #endif /* This is needed for getcwd() and chdir(). */ --- old/make-3.81/config/dospaths.m4 2006-03-10 06:20:45.000000000 +0200 +++ new/make-3.81/config/dospaths.m4 2006-08-18 21:12:32.859375000 +0300 @@ -22,7 +22,7 @@ AC_CACHE_CHECK([whether system uses MSDOS-style paths], [ac_cv_dos_paths], [ AC_COMPILE_IFELSE([ -#if !defined _WIN32 && !defined __WIN32__ && !defined __MSDOS__ && !defined __EMX__ && !defined __MSYS__ +#if !defined _WIN32 && !defined __WIN32__ && !defined __MSDOS__ && !defined __EMX__ && !defined __MSYS__ && !defined __CYGWIN__ neither MSDOS nor Windows nor OS2 #endif ], --- old/make-3.81/job.c 2006-03-20 07:03:04.000000000 +0200 +++ new/make-3.81/job.c 2006-08-19 09:25:07.687500000 +0300 @@ -2307,6 +2307,12 @@ construct_command_argv_internal (char *l "login", "logout", "read", "readonly", "set", "shift", "switch", "test", "times", "trap", "umask", "wait", "while", 0 }; +# ifdef HAVE_DOS_PATHS + /* This is required if the MSYS/Cygwin ports (which do not define + WINDOWS32) are compiled with HAVE_DOS_PATHS defined, which uses + sh_chars_sh[] directly (see below). */ + static char *sh_chars_sh = sh_chars; +# endif /* HAVE_DOS_PATHS */ #endif register int i; register char *p; [-- Attachment #3: 03-make-3.81-case_preserve.patch --] [-- Type: text/plain, Size: 9533 bytes --] diff -rup make-3.81/implicit.c make-3.81-new/implicit.c --- old/make-3.81/implicit.c Wed May 28 23:57:40 2008 +++ new/make-3.81/implicit.c Wed May 28 23:30:55 2008 @@ -27,7 +27,8 @@ Foundation, Inc., 51 Franklin St, Fifth static int pattern_search PARAMS ((struct file *file, int archive, - unsigned int depth, unsigned int recursions)); + unsigned int depth, unsigned int recursions, + int strict_case)); \f /* For a FILE which has no commands specified, try to figure out some from the implicit pattern rules. @@ -36,16 +37,19 @@ pattern_search PARAMS ((struct file *fil or returns 0 if no implicit rule was found. */ int -try_implicit_rule (struct file *file, unsigned int depth) +try_implicit_rule (struct file *file, unsigned int depth, int strict_case) { - DBF (DB_IMPLICIT, _("Looking for an implicit rule for `%s'.\n")); + if (strict_case) + DBF (DB_IMPLICIT, _("Looking for an implicit rule for `%s'.\n")); + else + DBF (DB_IMPLICIT, _("Looking for a case-insensitive implicit rule for `%s'.\n")); /* The order of these searches was previously reversed. My logic now is that since the non-archive search uses more information in the target (the archive search omits the archive name), it is more specific and should come first. */ - if (pattern_search (file, 0, depth, 0)) + if (pattern_search (file, 0, depth, 0, strict_case)) return 1; #ifndef NO_ARCHIVES @@ -55,7 +59,7 @@ try_implicit_rule (struct file *file, un { DBF (DB_IMPLICIT, _("Looking for archive-member implicit rule for `%s'.\n")); - if (pattern_search (file, 1, depth, 0)) + if (pattern_search (file, 1, depth, 0, strict_case)) return 1; } #endif @@ -198,7 +202,8 @@ get_next_word (char *buffer, unsigned in static int pattern_search (struct file *file, int archive, - unsigned int depth, unsigned int recursions) + unsigned int depth, unsigned int recursions, + int strict_case) { /* Filename we are searching for a rule for. */ char *filename = archive ? strchr (file->name, '(') : file->name; @@ -698,13 +703,13 @@ pattern_search (struct file *file, int a /* @@ dep->changed check is disabled. */ if (((f = lookup_file (name)) != 0 && f->is_target) /*|| ((!dep->changed || check_lastslash) && */ - || file_exists_p (name)) + || (strict_case ? file_exists_p (name) : (access (name, F_OK) == 0))) continue; /* This code, given FILENAME = "lib/foo.o", dependency name "lib/foo.c", and VPATH=src, searches for "src/lib/foo.c". */ vname = name; - if (vpath_search (&vname, (FILE_TIMESTAMP *) 0)) + if (vpath_search (&vname, (FILE_TIMESTAMP *) 0, strict_case)) { DBS (DB_IMPLICIT, (_("Found prerequisite `%s' as VPATH `%s'\n"), @@ -735,7 +740,8 @@ pattern_search (struct file *file, int a if (pattern_search (intermediate_file, 0, depth + 1, - recursions + 1)) + recursions + 1, + strict_case)) { d->intermediate_file = intermediate_file; d->intermediate_pattern = intermediate_file->name; @@ -751,7 +757,8 @@ pattern_search (struct file *file, int a so we won't go through the search again later. */ if (intermediate_file->variables) free_variable_set (intermediate_file->variables); - file_impossible (name); + if (strict_case==0) + file_impossible (name); } /* A dependency of this rule does not exist. Therefore, diff -rup make-3.81/make.h make-3.81-new/make.h --- old/make-3.81/make.h Wed May 28 23:57:40 2008 +++ new/make-3.81/make.h Wed May 28 23:30:55 2008 @@ -459,7 +459,7 @@ extern void install_default_implicit_rul extern void build_vpath_lists PARAMS ((void)); extern void construct_vpath_list PARAMS ((char *pattern, char *dirpath)); -extern int vpath_search PARAMS ((char **file, FILE_TIMESTAMP *mtime_ptr)); +extern int vpath_search PARAMS ((char **file, FILE_TIMESTAMP *mtime_ptr, int strict_case)); extern int gpath_search PARAMS ((char *file, unsigned int len)); extern void construct_include_path PARAMS ((char **arg_dirs)); diff -rup make-3.81/remake.c make-3.81-new/remake.c --- old/make-3.81/remake.c Wed May 28 23:57:40 2008 +++ new/make-3.81/remake.c Wed May 28 23:30:55 2008 @@ -39,7 +39,7 @@ Foundation, Inc., 51 Franklin St, Fifth #include <io.h> #endif -extern int try_implicit_rule PARAMS ((struct file *file, unsigned int depth)); +extern int try_implicit_rule PARAMS ((struct file *file, unsigned int depth, int strict_case)); /* The test for circular dependencies is based on the 'updating' bit in @@ -450,8 +450,10 @@ update_file_1 (struct file *file, unsign if (!file->phony && file->cmds == 0 && !file->tried_implicit) { - if (try_implicit_rule (file, depth)) + if (try_implicit_rule (file, depth, 1)) DBF (DB_IMPLICIT, _("Found an implicit rule for `%s'.\n")); + else if (try_implicit_rule (file, depth, 0)) + DBF (DB_IMPLICIT, _("Found an case-insensitive implicit rule for `%s'.\n")); else DBF (DB_IMPLICIT, _("No implicit rule found for `%s'.\n")); file->tried_implicit = 1; @@ -958,8 +960,10 @@ check_dep (struct file *file, unsigned i if (!file->phony && file->cmds == 0 && !file->tried_implicit) { - if (try_implicit_rule (file, depth)) + if (try_implicit_rule (file, depth, 1)) DBF (DB_IMPLICIT, _("Found an implicit rule for `%s'.\n")); + else if (try_implicit_rule (file, depth, 0)) + DBF (DB_IMPLICIT, _("Found an case-insensitive implicit rule for `%s'.\n")); else DBF (DB_IMPLICIT, _("No implicit rule found for `%s'.\n")); file->tried_implicit = 1; @@ -1230,7 +1234,7 @@ f_mtime (struct file *file, int search) { /* If name_mtime failed, search VPATH. */ char *name = file->name; - if (vpath_search (&name, &mtime) + if (vpath_search (&name, &mtime, 1) || vpath_search (&name, &mtime, 0) /* Last resort, is it a library (-lxxx)? */ || (name[0] == '-' && name[1] == 'l' && library_search (&name, &mtime))) @@ -1533,7 +1537,7 @@ library_search (char **lib, FILE_TIMESTA /* Now try VPATH search on that. */ file = libbuf; - if (vpath_search (&file, mtime_ptr)) + if (vpath_search (&file, mtime_ptr, 1) || vpath_search (&file, mtime_ptr, 1)) { *lib = file; return 1; diff -rup make-3.81/vpath.c make-3.81-new/vpath.c --- old/make-3.81/vpath.c Wed May 28 23:57:40 2008 +++ new/make-3.81/vpath.c Wed May 28 23:51:23 2008 @@ -48,7 +48,7 @@ static struct vpath *general_vpath; static struct vpath *gpaths; \f -static int selective_vpath_search PARAMS ((struct vpath *path, char **file, FILE_TIMESTAMP *mtime_ptr)); +static int selective_vpath_search PARAMS ((struct vpath *path, char **file, FILE_TIMESTAMP *mtime_ptr, int strict_case)); /* Reverse the chain of selective VPATH lists so they will be searched in the order given in the makefiles @@ -334,7 +334,7 @@ gpath_search (char *file, unsigned int l Otherwise we return 0. */ int -vpath_search (char **file, FILE_TIMESTAMP *mtime_ptr) +vpath_search (char **file, FILE_TIMESTAMP *mtime_ptr, int strict_case) { register struct vpath *v; @@ -351,11 +351,11 @@ vpath_search (char **file, FILE_TIMESTAM for (v = vpaths; v != 0; v = v->next) if (pattern_matches (v->pattern, v->percent, *file)) - if (selective_vpath_search (v, file, mtime_ptr)) + if (selective_vpath_search (v, file, mtime_ptr, strict_case)) return 1; if (general_vpath != 0 - && selective_vpath_search (general_vpath, file, mtime_ptr)) + && selective_vpath_search (general_vpath, file, mtime_ptr, strict_case)) return 1; return 0; @@ -370,7 +370,8 @@ vpath_search (char **file, FILE_TIMESTAM static int selective_vpath_search (struct vpath *path, char **file, - FILE_TIMESTAMP *mtime_ptr) + FILE_TIMESTAMP *mtime_ptr, + int strict_case) { int not_target; char *name, *n; @@ -500,10 +501,19 @@ selective_vpath_search (struct vpath *pa Now NAME is the name of the directory to look in. */ *n = '\0'; - /* We know the directory is in the hash table now because either - construct_vpath_list or the code just above put it there. - Does the file we seek exist in it? */ - exists_in_cache = exists = dir_file_exists_p (name, filename); + if (strict_case) + { + /* We know the directory is in the hash table now because either + construct_vpath_list or the code just above put it there. + Does the file we seek exist in it? */ + exists_in_cache = exists = dir_file_exists_p (name, filename); + } + else + { + /* If using a case insensitive search, avoid the case sensitive + lookup function above and force a real filesystem check. */ + exists_in_cache = exists = 1; + } #endif } [-- Attachment #4: 04-make-3.81-msys.patch --] [-- Type: text/plain, Size: 1981 bytes --] diff -urN old/make-3.81/Makefile.am new/make-3.81/Makefile.am --- old/make-3.81/Makefile.am 2006-04-01 02:36:40.000000000 -0400 +++ new/make-3.81/Makefile.am 2009-11-07 19:23:03.012300000 -0500 @@ -172,10 +172,17 @@ case `cd $(srcdir); pwd` in `pwd`) : ;; \ *) test -d tests || mkdir tests; \ rm -f srctests; \ - if ln -s "$(srcdir)/tests" srctests; then \ + if /bin/false && ln -s "$(srcdir)/tests" srctests; then \ for f in run_make_tests run_make_tests.pl test_driver.pl scripts; do \ rm -f tests/$$f; ln -s ../srctests/$$f tests; \ - done; fi ;; \ + done; \ + else \ + mkdir srctests ;\ + lndir $(srcdir)/tests/ srctests ;\ + for f in run_make_tests run_make_tests.pl test_driver.pl scripts; do \ + rm -f tests/$$f; (cd tests && ln -s ../srctests/$$f .); \ + done; \ + fi ;; \ esac; \ echo "cd tests && $(PERL) ./run_make_tests.pl -make ../make$(EXEEXT) $(MAKETESTFLAGS)"; \ cd tests && $(PERL) ./run_make_tests.pl -make ../make$(EXEEXT) $(MAKETESTFLAGS); \ diff -urN old/make-3.81/configure.in new/make-3.81/configure.in --- old/make-3.81/configure.in 2009-11-07 19:22:43.044300000 -0500 +++ new/make-3.81/configure.in 2009-11-07 19:37:43.011500000 -0500 @@ -40,9 +40,8 @@ # Specialized system macros AC_CANONICAL_HOST -AC_AIX +AC_USE_SYSTEM_EXTENSIONS AC_ISC_POSIX -AC_MINIX # Needed for ansi2knr AM_C_PROTOTYPES @@ -360,9 +359,14 @@ #endif ], [AC_MSG_RESULT(yes) make_cv_sys_gnu_glob=yes], [AC_MSG_RESULT([no; using local copy]) -AC_SUBST(GLOBINC) GLOBINC='-I$(srcdir)/glob' -AC_SUBST(GLOBLIB) GLOBLIB=glob/libglob.a make_cv_sys_gnu_glob=no])]) +if test "$make_cv_sys_gnu_glob" = no; then + GLOBINC='-I$(srcdir)/glob' + GLOBLIB=glob/libglob.a +fi +AC_SUBST(GLOBINC) +AC_SUBST(GLOBLIB) + # Tell automake about this, so it can build the right .c files. AM_CONDITIONAL(USE_LOCAL_GLOB, test "$make_cv_sys_gnu_glob" = no) ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: MSYS mode (continue) 2013-07-29 12:20 ` Charles Wilson 2013-07-29 12:49 ` Corinna Vinschen @ 2013-07-29 18:11 ` Larry Hall (Cygwin Developers) 1 sibling, 0 replies; 52+ messages in thread From: Larry Hall (Cygwin Developers) @ 2013-07-29 18:11 UTC (permalink / raw) To: cygwin-developers On 7/29/2013 8:20 AM, Charles Wilson wrote: > On 7/29/2013 7:19 AM, Earnie Boyd wrote: >> On Mon, Jul 29, 2013 at 7:00 AM, LRN wrote: >>>> - make w/ DOS path handling >>> Yes. Note that the code DOES exist in make, but is disabled when make is >>> built for Cygwin. One might question whether it was a good idea to >>> disable support for W32 paths in make that runs on W32 (with a >>> compatibility layer, but still...) in the first place. >>> >> >> MSYS has never modified the make source and it uses the CYGWIN coding. >> The only thing is we do accept windows pathing in the form of >> C:/SOME/DIR but not C:\SOME\DIR. > > No. > > Here's the patches applied to msys's make-3.81 <snip> > I've archives all the patches I used when I last built the msys apps -- it's > over 1MB after xz compression. I'll figure out somewhere to put it and post > the link later today. > > Here's the file listing -- 151 different patches to 56 different products. > Some were unofficial, since I never actually published my msys-tcl port. <snip> Interesting. Assuming a review of all these patches (and any future MSYS or even Cygwin-specific patch) won't either be jettisoned as no longer needed or viewed as common functionality desired in the unified MSYS/Cygwin universe, I'm starting to think the question of whether EXEs are "drop-in" chameleons for MSYS or CYGWIN is an implementation detail that the user should not know about or exploit. We don't want users to have to understand which EXEs are exactly the same code for both MSYS and Cygwin and which aren't. Worse, we don't want to have to determine which EXE the user has "dropped-in" when they report an issue. By these statements, I'm not saying that the "drop-in" capability shouldn't be used where possible. But if it is used, it should be something entirely opaque to the user. Even beyond that, we should actively hide this technical "sugar" from the end users to avoid the potential support nightmare. This shouldn't be a big deal though. We'd just need to install all the tools for each environment separately. -- Larry ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: MSYS mode (continue) 2013-07-27 3:07 ` Charles Wilson 2013-07-28 0:18 ` NightStrike @ 2013-07-29 9:25 ` Corinna Vinschen 1 sibling, 0 replies; 52+ messages in thread From: Corinna Vinschen @ 2013-07-29 9:25 UTC (permalink / raw) To: cygwin-developers On Jul 26 23:06, Charles Wilson wrote: > On 7/26/2013 4:15 AM, Corinna Vinschen wrote: > >Here's where I disagree. I think the executables should *not* rely on > >MSYS.dll being available. Ideally the executables are linked against > >the Cygwin DLL and MSYS.dll is called as a side-by-side implementation. > >So, if MSYS.dll isn't available, they still function as normal Cygwin > >executables. That's why I proposed the solution(s) in > >http://cygwin.com/ml/cygwin-developers/2013-07/msg00003.html > > So, in this proposal I'd have an "msys" directory structure, with > cygwin1.dll, an /etc/fstab, and lots of plain-old-cygwin > executables, bit-for-bit identical to the executables in my "real" > cygwin installation/directory structure. > > On executable launch, ALL such applications would check for the hook > DLL (as directed by an env variable, perhaps, or some other > mechanism -- maybe encoded in a known-present file, > like.../etc/fstab? [1]) and if present, load it. Depends. If the Cygwin DLL itself cares for loading a side-by-side MSYS.dll, then yes. If the crt0.o takes over this job, then only the applications rebuilt with this crt0.o will do that. > Now, back in my MSYS-on-cygwin installation, there are SOME > executables that are actually *different* that the corresponding > ones in real-cygwin-land. Stuff like make, bash, perl, etc -- all > may have been compiled with different options because we (the > mingw/msys people) want them to behave differently, in ways that > can't automatically be handled by the hooked changes in > cygwin1.dll's own behavior. > > Have I got that all correct? More or less, yes, except for the tiny detail above. > [1] I think this is better than an environment var, because then my > "regular" cygwin tree and my "msys" cygwin tree would both just > work, without needed extraneous global env vars that might interfere > with the other's operation. > > In fact, I might want *different* CYGWIN env var settings for the > two trees, but unless I set them in the global env then > StartMenu-launched apps lose out. They don't lose if you do it right. Don't start the application, start a script or batch file instead. > Could we maybe extend the CYGWIN env var idea to files, similar to > the /etc/fstab[.d] structure, which are then *augmented* by $CYGWIN? Reluctantly so. Opening files costs time. Reading the env is extremly cheap in comparison. > >Another alternative would be if the Cygwin DLL itself had a switch to > >load the MSYS dll (export CYGWIN=MSYS ;)). This would allows MSYS mode > >even with completely unchanged executables. > > Right -- but *some* executables would need to actually BE different, > aside from the underlying posix library's behavioral changes, to get > a "real" MSYS environment. Yes, that's what I said all the time. MSYSies will want another make and maybe another bash. > The MSYS team would just provide patched and (re)compiled versions > of most of their current set of tools...and if users wanted to "drop > in" (e.g.) git.exe, well they are welcome to try it. No support > offered or guaranteed, and they might just get lucky. Yes. I'm sure this works most of the time and only a couple of tools really need to be cripp^Waugmented. > As cgf pointed out, if "we" (cygwin) are trying to come up with an > easy upgrade path for existing users of MSYS, then we (mingw/msys) > users would prefer not to have to change our existing fstab format > on all of our installations. Unless you (we, cygwin) automate that > somehow... I think the latter should be a "we, msys". Providing an upgrade script from MSYS to MSYS2 doesn't look like a Cygwin task to me. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat ^ permalink raw reply [flat|nested] 52+ messages in thread
end of thread, other threads:[~2013-07-30 16:14 UTC | newest] Thread overview: 52+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <CABEPuQ+YxNF6LTAxRTVDQqQsKvGWGuaRxx1JAH62+wZZzgsC9w@mail.gmail.com> [not found] ` <CABEPuQKRz2kamtrbBF5MjxPiSRMxwJ7NhG6wRrtRXMoBm+quNg@mail.gmail.com> [not found] ` <20130704091632.GM5118@calimero.vinschen.de> [not found] ` <CABEPuQKb8ZFvA=5947_JNQ3xZUNi98FTkV=9Q04f8vMY-4q1pg@mail.gmail.com> [not found] ` <20130704101046.GN5118@calimero.vinschen.de> [not found] ` <CABEPuQJ2S5jUbJDS+XUhrvdLtu6t53QAvsmQ_q5RbvELZxHJhw@mail.gmail.com> [not found] ` <20130704103708.GA12995@calimero.vinschen.de> [not found] ` <CABEPuQ+iF265-SQzfLTmsBegG+BVjpLPowxRAH8ioWv1Us_iYg@mail.gmail.com> [not found] ` <20130704121617.GC12995@calimero.vinschen.de> [not found] ` <20130704163612.GA4729@ednor.casa.cgf.cx> 2013-07-05 9:07 ` MSYS mode (continue) Corinna Vinschen 2013-07-05 16:42 ` Christopher Faylor 2013-07-11 11:17 ` Corinna Vinschen 2013-07-25 11:06 ` Alexey Pavlov 2013-07-25 11:11 ` Corinna Vinschen 2013-07-25 13:11 ` Charles Wilson 2013-07-25 15:02 ` Corinna Vinschen 2013-07-25 18:21 ` Charles Wilson 2013-07-25 18:33 ` Charles Wilson 2013-07-25 20:53 ` Christopher Faylor 2013-07-25 21:08 ` LRN 2013-07-25 21:31 ` Larry Hall (Cygwin Developers) 2013-07-26 1:55 ` Christopher Faylor 2013-07-26 4:03 ` LRN 2013-07-26 5:46 ` Christopher Faylor 2013-07-26 8:15 ` Corinna Vinschen 2013-07-26 15:14 ` Christopher Faylor 2013-07-26 15:48 ` LRN 2013-07-26 16:16 ` Corinna Vinschen 2013-07-26 16:12 ` Corinna Vinschen 2013-07-26 16:37 ` Christopher Faylor 2013-07-26 16:45 ` Daniel Colascione 2013-07-26 16:47 ` Corinna Vinschen 2013-07-26 17:01 ` Christopher Faylor 2013-07-26 17:03 ` Daniel Colascione 2013-07-26 17:36 ` Christopher Faylor 2013-07-26 23:12 ` Yaakov (Cygwin/X) 2013-07-27 3:07 ` Charles Wilson 2013-07-28 0:18 ` NightStrike 2013-07-29 9:30 ` Corinna Vinschen 2013-07-29 11:00 ` LRN 2013-07-29 11:19 ` Corinna Vinschen 2013-07-29 15:36 ` LRN 2013-07-29 15:47 ` Corinna Vinschen 2013-07-29 16:37 ` Charles Wilson 2013-07-30 1:18 ` LRN 2013-07-30 0:45 ` LRN 2013-07-30 9:04 ` Corinna Vinschen 2013-07-30 9:32 ` Alexey Pavlov 2013-07-30 9:47 ` Corinna Vinschen 2013-07-30 10:27 ` Alexey Pavlov 2013-07-30 10:34 ` Corinna Vinschen 2013-07-30 10:59 ` Alexey Pavlov 2013-07-30 14:55 ` Christopher Faylor 2013-07-30 15:43 ` Christopher Faylor 2013-07-30 16:14 ` Christopher Faylor 2013-07-29 11:19 ` Earnie Boyd 2013-07-29 12:20 ` Charles Wilson 2013-07-29 12:49 ` Corinna Vinschen 2013-07-29 14:22 ` Charles Wilson 2013-07-29 18:11 ` Larry Hall (Cygwin Developers) 2013-07-29 9:25 ` Corinna Vinschen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).