Which is it -pc- or -unknown-
The config.guess file[1] is confused. 840i*:CYGWIN*:*) 841 echo ${UNAME_MACHINE}-pc-cygwin 842 exit ;; - 870amd64:CYGWIN*:*:* | x86_64:CYGWIN*:*:*) 871 echo x86_64-unknown-cygwin 872 exit ;; The GCC executable is x86_64-pc-cygwin-gcc.exe but config.guess on my system gives x86_64-unknown-cygwin so specifying a fully qualified host doesn't find the executable file. So which should it be? [1]http://git.savannah.gnu.org/cgit/config.git/tree/config.guess?id=c003e5cb947924ca5edd25c3b840aaa373c66b28 -- cyg Simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Which is it -pc- or -unknown-
On 2017-10-17 13:16, cyg Simple wrote: > The config.guess file[1] is confused. > > 840i*:CYGWIN*:*) > 841 echo ${UNAME_MACHINE}-pc-cygwin > 842 exit ;; > - > 870amd64:CYGWIN*:*:* | x86_64:CYGWIN*:*:*) > 871 echo x86_64-unknown-cygwin > 872 exit ;; > > The GCC executable is x86_64-pc-cygwin-gcc.exe but config.guess on my > system gives x86_64-unknown-cygwin so specifying a fully qualified host > doesn't find the executable file. So which should it be? > > [1]http://git.savannah.gnu.org/cgit/config.git/tree/config.guess?id=c003e5cb947924ca5edd25c3b840aaa373c66b28 That part of the triplet is defined as vendor, so it was probably initially Intel, then compatibles came out and that was genericized to PC, then someone objected and discussed and came up with Unknown, rather than say Any or None. It may reflect development ages of projects, autotools, defaults on projects, or project politics. Some projects still use PC, which may be a project override, others use Unknown, which should be the default in current releases of autotools. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Which is it -pc- or -unknown-
On 10/17/2017 3:45 PM, Brian Inglis wrote: > On 2017-10-17 13:16, cyg Simple wrote: >> The config.guess file[1] is confused. >> >> 840i*:CYGWIN*:*) >> 841 echo ${UNAME_MACHINE}-pc-cygwin >> 842 exit ;; >> - >> 870amd64:CYGWIN*:*:* | x86_64:CYGWIN*:*:*) >> 871 echo x86_64-unknown-cygwin >> 872 exit ;; >> >> The GCC executable is x86_64-pc-cygwin-gcc.exe but config.guess on my >> system gives x86_64-unknown-cygwin so specifying a fully qualified host >> doesn't find the executable file. So which should it be? >> >> [1]http://git.savannah.gnu.org/cgit/config.git/tree/config.guess?id=c003e5cb947924ca5edd25c3b840aaa373c66b28 > > That part of the triplet is defined as vendor, so it was probably initially > Intel, then compatibles came out and that was genericized to PC, then someone > objected and discussed and came up with Unknown, rather than say Any or None. > It may reflect development ages of projects, autotools, defaults on projects, > or > project politics. > Some projects still use PC, which may be a project override, others use > Unknown, > which should be the default in current releases of autotools. > So config.guess needs to change, correct? I thought the I had remembered the discussion that it should be -unknown- for Cygwin. But the GCC distribution is giving us -pc- instead which means the maintainer specified the target as such. That needs to change as well. I'm on x86_64 I bet x86 will be -pc- from config.guess just by the way it's coded. Confusing! -- cyg Simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Which is it -pc- or -unknown-
On 2017-10-17 15:31, cyg Simple wrote: > On 10/17/2017 3:45 PM, Brian Inglis wrote: >> On 2017-10-17 13:16, cyg Simple wrote: >>> The config.guess file[1] is confused. >>> 840i*:CYGWIN*:*) >>> 841 echo ${UNAME_MACHINE}-pc-cygwin >>> 842 exit ;; >>> - >>> 870amd64:CYGWIN*:*:* | x86_64:CYGWIN*:*:*) >>> 871 echo x86_64-unknown-cygwin >>> 872 exit ;; >>> The GCC executable is x86_64-pc-cygwin-gcc.exe but config.guess on my >>> system gives x86_64-unknown-cygwin so specifying a fully qualified host >>> doesn't find the executable file. So which should it be? >>> [1]http://git.savannah.gnu.org/cgit/config.git/tree/config.guess?id=c003e5cb947924ca5edd25c3b840aaa373c66b28 >> That part of the triplet is defined as vendor, so it was probably initially >> Intel, then compatibles came out and that was genericized to PC, then someone >> objected and discussed and came up with Unknown, rather than say Any or None. >> It may reflect development ages of projects, autotools, defaults on >> projects, or >> project politics. >> Some projects still use PC, which may be a project override, others use >> Unknown, >> which should be the default in current releases of autotools. > So config.guess needs to change, correct? I thought the I had > remembered the discussion that it should be -unknown- for Cygwin. But > the GCC distribution is giving us -pc- instead which means the > maintainer specified the target as such. That needs to change as well. > I'm on x86_64 I bet x86 will be -pc- from config.guess just by the way > it's coded. Confusing! You might want to diff the upstream config.{guess,sub} with those from /usr/share/automake1.{14,15}/ as those are the latest, and earlier releases to see if they are just old, in case there are project customizations. You can then decide whether you want to look further at how much of the project automake infrastructure you want to upgrade, or check if the project has looked at, or is working on, doing that. If you do so, you could look at offering that back upstream. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Which is it -pc- or -unknown-
On 2017-10-17 13:16, cyg Simple wrote: > The config.guess file[1] is confused. > > 840i*:CYGWIN*:*) > 841 echo ${UNAME_MACHINE}-pc-cygwin > 842 exit ;; > - > 870amd64:CYGWIN*:*:* | x86_64:CYGWIN*:*:*) > 871 echo x86_64-unknown-cygwin > 872 exit ;; > > The GCC executable is x86_64-pc-cygwin-gcc.exe but config.guess on my > system gives x86_64-unknown-cygwin so specifying a fully qualified host > doesn't find the executable file. So which should it be? > > [1]http://git.savannah.gnu.org/cgit/config.git/tree/config.guess?id=c003e5cb947924ca5edd25c3b840aaa373c66b28 There are also similar confusions and differences between projects and distros about use of x86_64 (or x86-64) and amd64. You may have come across others. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Which is it -pc- or -unknown-
On 10/17/2017 7:39 PM, Brian Inglis wrote: > On 2017-10-17 15:31, cyg Simple wrote: >> On 10/17/2017 3:45 PM, Brian Inglis wrote: >>> On 2017-10-17 13:16, cyg Simple wrote: The config.guess file[1] is confused. 840i*:CYGWIN*:*) 841echo ${UNAME_MACHINE}-pc-cygwin 842exit ;; - 870amd64:CYGWIN*:*:* | x86_64:CYGWIN*:*:*) 871echo x86_64-unknown-cygwin 872exit ;; The GCC executable is x86_64-pc-cygwin-gcc.exe but config.guess on my system gives x86_64-unknown-cygwin so specifying a fully qualified host doesn't find the executable file. So which should it be? [1]http://git.savannah.gnu.org/cgit/config.git/tree/config.guess?id=c003e5cb947924ca5edd25c3b840aaa373c66b28 >>> That part of the triplet is defined as vendor, so it was probably initially >>> Intel, then compatibles came out and that was genericized to PC, then >>> someone >>> objected and discussed and came up with Unknown, rather than say Any or >>> None. >>> It may reflect development ages of projects, autotools, defaults on >>> projects, or >>> project politics. >>> Some projects still use PC, which may be a project override, others use >>> Unknown, >>> which should be the default in current releases of autotools. >> So config.guess needs to change, correct? I thought the I had >> remembered the discussion that it should be -unknown- for Cygwin. But >> the GCC distribution is giving us -pc- instead which means the >> maintainer specified the target as such. That needs to change as well. >> I'm on x86_64 I bet x86 will be -pc- from config.guess just by the way >> it's coded. Confusing! > > You might want to diff the upstream config.{guess,sub} with those from > /usr/share/automake1.{14,15}/ as those are the latest, and earlier releases to > see if they are just old, in case there are project customizations. > You can then decide whether you want to look further at how much of the > project > automake infrastructure you want to upgrade, or check if the project has > looked > at, or is working on, doing that. > If you do so, you could look at offering that back upstream. > Brian, I quoted the git master of config.guess in my original mail. My concern is that on my 64bit Cygwin version config.guess guesses the build as x86_64-unknown-cygwin but x86_64-pc-cygwin-gcc.exe is distributed. Therefore there is a mismatch between what the maintainer gives us from the GCC distribution and what the upstream config.guess gives us. This leads to not being able to find x86_64-unknown-cygwin-gcc.exe. -- cyg Simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Which is it -pc- or -unknown-
On 10/17/2017 7:49 PM, Brian Inglis wrote: > On 2017-10-17 13:16, cyg Simple wrote: >> The config.guess file[1] is confused. >> >> 840i*:CYGWIN*:*) >> 841 echo ${UNAME_MACHINE}-pc-cygwin >> 842 exit ;; >> - >> 870amd64:CYGWIN*:*:* | x86_64:CYGWIN*:*:*) >> 871 echo x86_64-unknown-cygwin >> 872 exit ;; >> >> The GCC executable is x86_64-pc-cygwin-gcc.exe but config.guess on my >> system gives x86_64-unknown-cygwin so specifying a fully qualified host >> doesn't find the executable file. So which should it be? >> >> [1]http://git.savannah.gnu.org/cgit/config.git/tree/config.guess?id=c003e5cb947924ca5edd25c3b840aaa373c66b28 > > There are also similar confusions and differences between projects and distros > about use of x86_64 (or x86-64) and amd64. You may have come across others. > I'm only concerned with Cygwin at the moment. As I understand it the we should distribute x86[_64]-unknown-cygwin-*.exe and not as x86[_64]-pc-cygwin-*.exe We also need to correct config.guess for the i*:CYGWIN*:* match. -- cyg Simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Which is it -pc- or -unknown-
On 2017-10-17 21:29, cyg Simple wrote: > On 10/17/2017 7:49 PM, Brian Inglis wrote: >> On 2017-10-17 13:16, cyg Simple wrote: >>> The config.guess file[1] is confused. >>> >>> 840i*:CYGWIN*:*) >>> 841 echo ${UNAME_MACHINE}-pc-cygwin >>> 842 exit ;; >>> - >>> 870amd64:CYGWIN*:*:* | x86_64:CYGWIN*:*:*) >>> 871 echo x86_64-unknown-cygwin >>> 872 exit ;; >>> >>> The GCC executable is x86_64-pc-cygwin-gcc.exe but config.guess on my >>> system gives x86_64-unknown-cygwin so specifying a fully qualified host >>> doesn't find the executable file. So which should it be? >>> >>> [1]http://git.savannah.gnu.org/cgit/config.git/tree/config.guess?id=c003e5cb947924ca5edd25c3b840aaa373c66b28 >> >> There are also similar confusions and differences between projects and >> distros >> about use of x86_64 (or x86-64) and amd64. You may have come across others. >> > > I'm only concerned with Cygwin at the moment. As I understand it the we > should distribute x86[_64]-unknown-cygwin-*.exe and not as > x86[_64]-pc-cygwin-*.exe We also need to correct config.guess for the > i*:CYGWIN*:* match. It seems that i686-pc-... on lines 840... is common, probably for historical reasons, and that may be okay for 32 bit builds but I don't know the Cygwin history here, and x86_64-unknown-... should be selected for 64 bit builds in lines 870... Packages for current 32 and 64 bit binutils, cygwin32-..., and gcc... are prefixed with or found under {i686,x86_64}-pc-cygwin, so you might have to change the vendor field in config.guess, if you want to stay consistent. Packages emacs, octave, and pkg-config are the only ones I can find using x86_64-unknown-cygwin prefix on 64 bit, none with i686-unknown-cygwin on 32 bit. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Which is it -pc- or -unknown-
On 18/10/2017 05:29, cyg Simple wrote: On 10/17/2017 7:49 PM, Brian Inglis wrote: On 2017-10-17 13:16, cyg Simple wrote: I'm only concerned with Cygwin at the moment. As I understand it the we should distribute x86[_64]-unknown-cygwin-*.exe and not as x86[_64]-pc-cygwin-*.exe We also need to correct config.guess for the i*:CYGWIN*:* match. it is irrelevant as x86[_64]-unknown-cygwin-*.exe and x86[_64]-pc-cygwin-*.exe are equivalent. And usually it is not x86 but i686 $ arch i686 For a regex pattern you should include both. I do not bore which one is built and distributed on my packages. E.G. on octave /usr/lib/octave/site/oct/i686-pc-cygwin /usr/lib/octave/site/oct/x86_64-unknown-cygwin Regards Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Which is it -pc- or -unknown-
On 2017-10-18 00:45, Marco Atzeri wrote: > On 18/10/2017 05:29, cyg Simple wrote: >> On 10/17/2017 7:49 PM, Brian Inglis wrote: >>> On 2017-10-17 13:16, cyg Simple wrote: >> I'm only concerned with Cygwin at the moment. As I understand it the we >> should distribute x86[_64]-unknown-cygwin-*.exe and not as >> x86[_64]-pc-cygwin-*.exe We also need to correct config.guess for the >> i*:CYGWIN*:* match. > it is irrelevant as x86[_64]-unknown-cygwin-*.exe and > x86[_64]-pc-cygwin-*.exe are equivalent. > And usually it is not x86 but i686 > $ arch > i686 > For a regex pattern you should include both. > I do not care which one is built and distributed on my packages. > E.G. on octave > /usr/lib/octave/site/oct/i686-pc-cygwin > /usr/lib/octave/site/oct/x86_64-unknown-cygwin Do gcc... and binutils have to match so the front end can find the build tools or are there config options for binutils triplet or vendor? -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Which is it -pc- or -unknown-
On 10/17/2017 3:16 PM, cyg Simple wrote: > The config.guess file[1] is confused. > > 840i*:CYGWIN*:*) > 841 echo ${UNAME_MACHINE}-pc-cygwin > 842 exit ;; > - > 870amd64:CYGWIN*:*:* | x86_64:CYGWIN*:*:*) > 871 echo x86_64-unknown-cygwin > 872 exit ;; > > The GCC executable is x86_64-pc-cygwin-gcc.exe but config.guess on my > system gives x86_64-unknown-cygwin so specifying a fully qualified host > doesn't find the executable file. So which should it be? > > [1]http://git.savannah.gnu.org/cgit/config.git/tree/config.guess?id=c003e5cb947924ca5edd25c3b840aaa373c66b28 > Does anyone care if a patch to config.guess changes the i*:CYGWIN*:* filter to echo ${UNAME_MACHINE}-unknown-cygwin? -- cyg Simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Which is it -pc- or -unknown-
On 2017-10-18 09:05, cyg Simple wrote: > Does anyone care if a patch to config.guess changes the i*:CYGWIN*:* > filter to echo ${UNAME_MACHINE}-unknown-cygwin? That would be incorrect. config.guess is fine as it is. -- Yaakov signature.asc Description: OpenPGP digital signature
Re: Which is it -pc- or -unknown-
On 10/18/2017 1:11 PM, Yaakov Selkowitz wrote: > On 2017-10-18 09:05, cyg Simple wrote: >> Does anyone care if a patch to config.guess changes the i*:CYGWIN*:* >> filter to echo ${UNAME_MACHINE}-unknown-cygwin? > > That would be incorrect. config.guess is fine as it is. > So the corrective action is to distribute GCC and friends as x86_64-unknown-cygwin-*.exe instead of x86_64-pc-cygwin-*.exe. MAINTAINERS: Please take note for your next releases. -- cyg Simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Which is it -pc- or -unknown-
On 2017-10-18 13:10, cyg Simple wrote: > On 10/18/2017 1:11 PM, Yaakov Selkowitz wrote: >> On 2017-10-18 09:05, cyg Simple wrote: >>> Does anyone care if a patch to config.guess changes the i*:CYGWIN*:* >>> filter to echo ${UNAME_MACHINE}-unknown-cygwin? >> >> That would be incorrect. config.guess is fine as it is. >> > > So the corrective action is to distribute GCC and friends as > x86_64-unknown-cygwin-*.exe instead of x86_64-pc-cygwin-*.exe. > > MAINTAINERS: Please take note for your next releases. Does this mean 64 bit binutils needs rebuilt with current config.guess to be found by an updated gcc, or is there a different config option for that triplet? -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Which is it -pc- or -unknown-
On 2017-10-18 14:10, cyg Simple wrote: > On 10/18/2017 1:11 PM, Yaakov Selkowitz wrote: >> On 2017-10-18 09:05, cyg Simple wrote: >>> Does anyone care if a patch to config.guess changes the i*:CYGWIN*:* >>> filter to echo ${UNAME_MACHINE}-unknown-cygwin? >> >> That would be incorrect. config.guess is fine as it is. > > So the corrective action is to distribute GCC and friends as > x86_64-unknown-cygwin-*.exe instead of x86_64-pc-cygwin-*.exe. Incorrect. GCC is also fine as is. -- Yaakov signature.asc Description: OpenPGP digital signature
Re: Which is it -pc- or -unknown-
On 10/18/2017 10:41 PM, Yaakov Selkowitz wrote: > On 2017-10-18 14:10, cyg Simple wrote: >> On 10/18/2017 1:11 PM, Yaakov Selkowitz wrote: >>> On 2017-10-18 09:05, cyg Simple wrote: Does anyone care if a patch to config.guess changes the i*:CYGWIN*:* filter to echo ${UNAME_MACHINE}-unknown-cygwin? >>> >>> That would be incorrect. config.guess is fine as it is. >> >> So the corrective action is to distribute GCC and friends as >> x86_64-unknown-cygwin-*.exe instead of x86_64-pc-cygwin-*.exe. > > Incorrect. GCC is also fine as is. > I agree with Yaakov, why does it need to change? signature.asc Description: OpenPGP digital signature
Re: Which is it -pc- or -unknown-
On Wed, 18 Oct 2017 08:45:11, Marco Atzeri wrote: For a regex pattern you should include both. I do not bore which one is built and distributed on my packages. E.G. on octave /usr/lib/octave/site/oct/i686-pc-cygwin /usr/lib/octave/site/oct/x86_64-unknown-cygwin This is certainly not right. I can understand that we will have some discrepancies across packages, but having a different vendor in the same package is unacceptable. It suggests that x86_64-unknown-cygwin and i686-pc-cygwin differ in more ways that one, which they dont. you let it slide, then people start asking: - where is x86_64-pc-cygwin? - where is i686-unknown-cygwin? which are both valid questions when a package maintainer does dumb stuff like this. just realized that for octave package, that is you: http://cygwin.com/cygwin-pkg-maint point still stands -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Which is it -pc- or -unknown-
On 2017-10-18 18:26, Steven Penny wrote: > On Wed, 18 Oct 2017 08:45:11, Marco Atzeri wrote: >> For a regex pattern you should include both. >> I do not bore which one is built and distributed on my packages. >> >> E.G. on octave >> >> /usr/lib/octave/site/oct/i686-pc-cygwin >> /usr/lib/octave/site/oct/x86_64-unknown-cygwin > > This is certainly not right. I can understand that we will have some > discrepancies across packages, but having a different vendor in the same > package is unacceptable. According to whom? 'pc' is the default vendor for i*86 for historical reasons, but 'unknown' is the default for most other architectures. There really isn't anything unusual here. -- Yaakov signature.asc Description: OpenPGP digital signature
Re: Which is it -pc- or -unknown-
On 10/18/2017 6:41 PM, Yaakov Selkowitz wrote: > On 2017-10-18 14:10, cyg Simple wrote: >> On 10/18/2017 1:11 PM, Yaakov Selkowitz wrote: >>> On 2017-10-18 09:05, cyg Simple wrote: Does anyone care if a patch to config.guess changes the i*:CYGWIN*:* filter to echo ${UNAME_MACHINE}-unknown-cygwin? >>> >>> That would be incorrect. config.guess is fine as it is. >> >> So the corrective action is to distribute GCC and friends as >> x86_64-unknown-cygwin-*.exe instead of x86_64-pc-cygwin-*.exe. > > Incorrect. GCC is also fine as is. > No it is not! The below example should work out of the box and it doesn't. ./configure --host=x86_64-unknown-cygwin --build=x86_64-unknown-cygwin -- cyg Simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Which is it -pc- or -unknown-
On 10/18/2017 6:58 PM, JonY wrote: > On 10/18/2017 10:41 PM, Yaakov Selkowitz wrote: >> On 2017-10-18 14:10, cyg Simple wrote: >>> On 10/18/2017 1:11 PM, Yaakov Selkowitz wrote: On 2017-10-18 09:05, cyg Simple wrote: > Does anyone care if a patch to config.guess changes the i*:CYGWIN*:* > filter to echo ${UNAME_MACHINE}-unknown-cygwin? That would be incorrect. config.guess is fine as it is. >>> >>> So the corrective action is to distribute GCC and friends as >>> x86_64-unknown-cygwin-*.exe instead of x86_64-pc-cygwin-*.exe. >> >> Incorrect. GCC is also fine as is. >> > > I agree with Yaakov, why does it need to change? > See my response to Yaakov. If you supply explicit host and build to configure it does not work. -- cyg Simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Which is it -pc- or -unknown-
On 10/18/2017 7:26 PM, Steven Penny wrote: > On Wed, 18 Oct 2017 08:45:11, Marco Atzeri wrote: >> For a regex pattern you should include both. >> I do not bore which one is built and distributed on my packages. >> >> E.G. on octave >> >> /usr/lib/octave/site/oct/i686-pc-cygwin >> /usr/lib/octave/site/oct/x86_64-unknown-cygwin > > This is certainly not right. I can understand that we will have some > discrepancies across packages, but having a different vendor in the same > package > is unacceptable. It suggests that x86_64-unknown-cygwin and i686-pc-cygwin > differ in more ways that one, which they dont. you let it slide, then > people > start asking: > I can live with the historical i*-pc-cygwin mishap. > - where is x86_64-pc-cygwin? This I cannot live with and the package maintainers need to target x86_64-unknown-cygwin instead. GCC has a target build of x86_64-pc-cygwin, it needs corrected! > - where is i686-unknown-cygwin? > This should never exist under the current scheme. It should always be i*-pc-cygwin. -- cyg Simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Which is it -pc- or -unknown-
On 10/19/2017 9:19 AM, cyg Simple wrote: On 10/18/2017 6:58 PM, JonY wrote: I agree with Yaakov, why does it need to change? See my response to Yaakov. If you supply explicit host and build to configure it does not work. So don't do that. Specifying host is for cross-compilation. Specifying build without host is for overriding the result of config.guess (never necessary on Cygwin). See https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Specifying-Target-Triplets.html In particular: "If you mean to override the result of config.guess, use --build, not --host, since the latter enables cross-compilation." Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Which is it -pc- or -unknown-
On 19/10/2017 15:17, cyg Simple wrote: So the corrective action is to distribute GCC and friends as x86_64-unknown-cygwin-*.exe instead of x86_64-pc-cygwin-*.exe. Incorrect. GCC is also fine as is. No it is not! The below example should work out of the box and it doesn't. ./configure --host=x86_64-unknown-cygwin --build=x86_64-unknown-cygwin the correct way is ./configure don't add what you don't need.. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Which is it -pc- or -unknown-
On 19/10/2017 15:25, cyg Simple wrote: On 10/18/2017 7:26 PM, Steven Penny wrote: On Wed, 18 Oct 2017 08:45:11, Marco Atzeri wrote: For a regex pattern you should include both. I do not bore which one is built and distributed on my packages. E.G. on octave /usr/lib/octave/site/oct/i686-pc-cygwin /usr/lib/octave/site/oct/x86_64-unknown-cygwin This is certainly not right. I can understand that we will have some discrepancies across packages, but having a different vendor in the same package is unacceptable. It suggests that x86_64-unknown-cygwin and i686-pc-cygwin differ in more ways that one, which they dont. you let it slide, then people start asking: I can live with the historical i*-pc-cygwin mishap. - where is x86_64-pc-cygwin? This I cannot live with and the package maintainers need to target x86_64-unknown-cygwin instead. GCC has a target build of x86_64-pc-cygwin, it needs corrected! It seems all cygwin package maintainers have no problem. So are you causing yourself a not-existing problem ? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Which is it -pc- or -unknown-
On 2017-10-19 08:25, cyg Simple wrote: > On 10/18/2017 7:26 PM, Steven Penny wrote: >> On Wed, 18 Oct 2017 08:45:11, Marco Atzeri wrote: >>> For a regex pattern you should include both. >>> I do not bore which one is built and distributed on my packages. >>> >>> E.G. on octave >>> >>> /usr/lib/octave/site/oct/i686-pc-cygwin >>> /usr/lib/octave/site/oct/x86_64-unknown-cygwin >> >> This is certainly not right. I can understand that we will have some >> discrepancies across packages, but having a different vendor in the same >> package >> is unacceptable. It suggests that x86_64-unknown-cygwin and i686-pc-cygwin >> differ in more ways that one, which they dont. you let it slide, then >> people >> start asking: >> > > I can live with the historical i*-pc-cygwin mishap. > >> - where is x86_64-pc-cygwin? > > This I cannot live with and the package maintainers need to target > x86_64-unknown-cygwin instead. GCC has a target build of > x86_64-pc-cygwin, it needs corrected! We've been building packages for 64-bit Cygwin for years now without a problem. Maybe you could just tell what you're trying to do and the problem you're seeing so that we can assist you, instead of this circular discussion of a nonexistent problem. -- Yaakov signature.asc Description: OpenPGP digital signature
Re: Which is it -pc- or -unknown-
On 10/19/2017 10:18 AM, Ken Brown wrote: > On 10/19/2017 9:19 AM, cyg Simple wrote: >> On 10/18/2017 6:58 PM, JonY wrote: >>> I agree with Yaakov, why does it need to change? >>> >> >> See my response to Yaakov. If you supply explicit host and build to >> configure it does not work. > > So don't do that. Specifying host is for cross-compilation. Specifying > build without host is for overriding the result of config.guess (never > necessary on Cygwin). See > > > https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Specifying-Target-Triplets.html > > > In particular: "If you mean to override the result of config.guess, use > --build, not --host, since the latter enables cross-compilation." > So?! It is still incorrect for the --target of the GCC build to be x86_64-pc-cygwin. My example didn't specify a different build from host. I ran across this from a package that was refusing to accept the config.guess build triplet so I tried specifying both. At that point it failed to find x86_64-unknown-cygwin-gcc. And ./configure --build=`/path/to/config.guess` will not work either as currently delivered. x86_64-pc-cygwin IS NOT CORRECT. It needs fixed in the build process. -- cyg Simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Which is it -pc- or -unknown-
On 10/19/2017 10:41 AM, Marco Atzeri wrote: > On 19/10/2017 15:17, cyg Simple wrote: >> >> > So the corrective action is to distribute GCC and friends as x86_64-unknown-cygwin-*.exe instead of x86_64-pc-cygwin-*.exe. >>> >>> Incorrect. GCC is also fine as is. >>> >> >> No it is not! The below example should work out of the box and it >> doesn't. >> >> ./configure --host=x86_64-unknown-cygwin --build=x86_64-unknown-cygwin > > > the correct way is > ./configure > Normally yes, but ... > don't add what you don't need.. I was trying to help a package refusing the config.guess triplet so I needed it. Regardless delivering a target build of x86_64-pc-cygwin is not correct! It needs to be x86_64-unknown-cygwin. -- cyg Simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Which is it -pc- or -unknown-
On 19/10/2017 18:21, cyg Simple wrote: ./configure --host=x86_64-unknown-cygwin --build=x86_64-unknown-cygwin the correct way is ./configure Normally yes, but ... don't add what you don't need.. I was trying to help a package refusing the config.guess triplet so I needed it. Regardless delivering a target build of x86_64-pc-cygwin is not correct! It needs to be x86_64-unknown-cygwin. may we know which package ? If it refuses triplet has a strange way to use Autoconf/Automake and changing the compiler seems the wrong way to solve the issue Regards Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Which is it -pc- or -unknown-
On 10/19/2017 11:04 AM, Yaakov Selkowitz wrote: > On 2017-10-19 08:25, cyg Simple wrote: >> On 10/18/2017 7:26 PM, Steven Penny wrote: >>> On Wed, 18 Oct 2017 08:45:11, Marco Atzeri wrote: For a regex pattern you should include both. I do not bore which one is built and distributed on my packages. E.G. on octave /usr/lib/octave/site/oct/i686-pc-cygwin /usr/lib/octave/site/oct/x86_64-unknown-cygwin >>> >>> This is certainly not right. I can understand that we will have some >>> discrepancies across packages, but having a different vendor in the same >>> package >>> is unacceptable. It suggests that x86_64-unknown-cygwin and i686-pc-cygwin >>> differ in more ways that one, which they dont. you let it slide, then >>> people >>> start asking: >>> >> >> I can live with the historical i*-pc-cygwin mishap. >> >>> - where is x86_64-pc-cygwin? >> >> This I cannot live with and the package maintainers need to target >> x86_64-unknown-cygwin instead. GCC has a target build of >> x86_64-pc-cygwin, it needs corrected! > > We've been building packages for 64-bit Cygwin for years now without a > problem. Maybe you could just tell what you're trying to do and the > problem you're seeing so that we can assist you, instead of this > circular discussion of a nonexistent problem. > And I've used the products for years as well, that doesn't make the product without fallacies. It is either that config.guess is wrong and the guess should be x86_64-pc-cygwin or the maintainers are wrong and should provide host/target for x86_64-unknown-cygwin. It is that simple. It has nothing to do with what I was trying to do when I discovered the issue; it is an issue. The scenario occurred when I was trying to configure a package and that package was refusing to accept the config.guess build triplet. So I decided to do cyg=`/path/to/config.guess`; ./configure --host=$cyg --build=$cyg The configure couldn't find x86_64-unknown-cygwin-gcc. When I looked in /usr/bin I found x86_64-pc-cygwin-gcc instead!! So which is it, it cannot be both! -- cyg Simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Which is it -pc- or -unknown-
On 10/19/2017 12:41 PM, Marco Atzeri wrote: > On 19/10/2017 18:21, cyg Simple wrote: > ./configure --host=x86_64-unknown-cygwin --build=x86_64-unknown-cygwin >>> >>> >>> the correct way is >>> ./configure >>> >> >> Normally yes, but ... >> >>> don't add what you don't need.. >> >> I was trying to help a package refusing the config.guess triplet so I >> needed it. Regardless delivering a target build of x86_64-pc-cygwin is >> not correct! It needs to be x86_64-unknown-cygwin. > > may we know which package ? > > If it refuses triplet has a strange way to use Autoconf/Automake > and changing the compiler seems the wrong way to solve the issue No, it doesn't matter. Delivering x86_64-pc-cygwin anything is wrong since the triplet is x86_64-unknown-cygwin. -- cyg Simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Which is it -pc- or -unknown-
On Thu, 19 Oct 2017 12:47:29, cyg Simple wrote: > may we know which package ? > > If it refuses triplet has a strange way to use Autoconf/Automake > and changing the compiler seems the wrong way to solve the issue No, it doesn't matter. Delivering x86_64-pc-cygwin anything is wrong since the triplet is x86_64-unknown-cygwin. Wrong. It does matter. By failing to provide a package you are in violation of MCVE: http://stackoverflow.com/help/mcve and deserve 0 help. If you want help, you need to give people enough so that they can help you. Otherwise Yaakov is right: circular discussion of a nonexistent problem -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Which is it -pc- or -unknown-
On 10/19/2017 2:37 PM, Steven Penny wrote: > On Thu, 19 Oct 2017 12:47:29, cyg Simple wrote: >> > may we know which package ? >> > > If it refuses triplet has a strange way to use Autoconf/Automake >> > and changing the compiler seems the wrong way to solve the issue >> >> No, it doesn't matter. Delivering x86_64-pc-cygwin anything is wrong >> since the triplet is x86_64-unknown-cygwin. > > Wrong. It does matter. By failing to provide a package you are in > violation of > MCVE: > > http://stackoverflow.com/help/mcve > > and deserve 0 help. If you want help, you need to give people enough so > that > they can help you. Otherwise Yaakov is right: > >> circular discussion of a nonexistent problem > So you support the maintainers supplying an incorrect triplet? x86_64-pc-cygwin is just not correct regardless of the lack of past issues. -- cyg Simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Which is it -pc- or -unknown-
On 2017-10-19 11:44, cyg Simple wrote: > On 10/19/2017 11:04 AM, Yaakov Selkowitz wrote: >> We've been building packages for 64-bit Cygwin for years now without a >> problem. Maybe you could just tell what you're trying to do and the >> problem you're seeing so that we can assist you, instead of this >> circular discussion of a nonexistent problem. > > The scenario occurred when I was trying to configure a package and that > package was refusing to accept the config.guess build triplet. While you're still being vague (in terms of which package you are building and exactly what the error is), that sounds like an issue with (usually old) sources bundling an ancient config.{guess,sub} which doesn't know about 64-bit Cygwin. I have several packages like this. cygport's gnuconfigize command is intended to help with such cases. > So I decided to do > > cyg=`/path/to/config.guess`; ./configure --host=$cyg --build=$cyg This is incorrect. > The configure couldn't find x86_64-unknown-cygwin-gcc. When I looked in > /usr/bin I found x86_64-pc-cygwin-gcc instead!! So which is it, it > cannot be both! When you *really* need to use --build and/or --host, then you need to use x86_64-pc-cygwin, as that is our chosen name. -- Yaakov signature.asc Description: OpenPGP digital signature
Re: Which is it -pc- or -unknown-
On 2017-10-19 13:40, cyg Simple wrote: > x86_64-pc-cygwin is just not correct regardless of the lack of past issues. As I have said several times, this assertion is incorrect. You need to use the triplet which matches the toolchain with which you are building. For example, Fedora and RHEL all use $arch-redhat-linux as their triplet, and there is nothing wrong with that. -- Yaakov signature.asc Description: OpenPGP digital signature
Re: Which is it -pc- or -unknown-
On 10/19/2017 2:59 PM, Yaakov Selkowitz wrote: > On 2017-10-19 13:40, cyg Simple wrote: >> x86_64-pc-cygwin is just not correct regardless of the lack of past issues. > > As I have said several times, this assertion is incorrect. You need to > use the triplet which matches the toolchain with which you are building. > For example, Fedora and RHEL all use $arch-redhat-linux as their > triplet, and there is nothing wrong with that. Yaakov, you have already stated that the triplet for Cygwin on x86_64 should be x86_64-unknown-cygwin. That in itself makes it imperative that the maintainers distribute a triplet toolchain that matches it. -- cyg Simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Which is it -pc- or -unknown-
On 10/19/2017 2:51 PM, Yaakov Selkowitz wrote: > > When you *really* need to use --build and/or --host, then you need to > use x86_64-pc-cygwin, as that is our chosen name. Then config.guess needs to change to match the chosen name!! Why confuse everyone? Make up your mind and choose one. I can submit the patches to the config maintainer. -- cyg Simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Which is it -pc- or -unknown-
On 2017-10-19 12:59, Yaakov Selkowitz wrote: > On 2017-10-19 13:40, cyg Simple wrote: >> x86_64-pc-cygwin is just not correct regardless of the lack of past issues. > > As I have said several times, this assertion is incorrect. You need to > use the triplet which matches the toolchain with which you are building. > For example, Fedora and RHEL all use $arch-redhat-linux as their > triplet, and there is nothing wrong with that. Vendor -unknown- is just a default in various config cases, so specifying -pc- for consistency on Cygwin builds is a valid choice by the maintainers. Perhaps a statement on the cygwin-apps list could clarify what should be done by maintainers to ensure this override, and maybe retire the use of -unknown- by any Cygwin apps in future, with a notice to this (cygwin) list for those who choose to build packages from net sources. Perhaps also patches should be submitted to the config and automake maintainers to ensure that {i*,x86_64}:CYGWIN*:*... always produce vendor -pc-. Not sure about vendors for {amd64,powerpcle}:CYGWIN*:*... in config.guess, which are currently also set to -unknown-. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Which is it -pc- or -unknown-
> On Oct 19, 2017, at 2:08 PM, cyg Simple wrote: > > On 10/19/2017 2:51 PM, Yaakov Selkowitz wrote: >> >> When you *really* need to use --build and/or --host, then you need to >> use x86_64-pc-cygwin, as that is our chosen name. > > Then config.guess needs to change to match the chosen name!! > > Why confuse everyone? Make up your mind and choose one. I can submit > the patches to the config maintainer. It's not confusing everyone. You're the only one jumping up and down, you have refused to provide information needed to help you, and in spite of that, Yaakov has given you a reasonable guess at a solution. I can only conclude you just like to hear yourself scream. If only we were in space… -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Which is it -pc- or -unknown-
On 10/19/2017 3:54 PM, Brian Inglis wrote: > On 2017-10-19 12:59, Yaakov Selkowitz wrote: >> On 2017-10-19 13:40, cyg Simple wrote: >>> x86_64-pc-cygwin is just not correct regardless of the lack of past issues. >> >> As I have said several times, this assertion is incorrect. You need to >> use the triplet which matches the toolchain with which you are building. >> For example, Fedora and RHEL all use $arch-redhat-linux as their >> triplet, and there is nothing wrong with that. > > Vendor -unknown- is just a default in various config cases, so specifying -pc- > for consistency on Cygwin builds is a valid choice by the maintainers. > FINE! But config.guess should match the CHOSEN one. > Perhaps a statement on the cygwin-apps list could clarify what should be done > by > maintainers to ensure this override, and maybe retire the use of -unknown- by > any Cygwin apps in future, with a notice to this (cygwin) list for those who > choose to build packages from net sources. > I don't care which is used as long as config.guess matches what is chosen. > Perhaps also patches should be submitted to the config and automake > maintainers > to ensure that {i*,x86_64}:CYGWIN*:*... always produce vendor -pc-. Not sure > about vendors for {amd64,powerpcle}:CYGWIN*:*... in config.guess, which are > currently also set to -unknown-. > Exactly what I'm saying. It needs to match what is being distributed just for consistency and to avoid confusion. -- cyg Simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Which is it -pc- or -unknown-
On 10/19/2017 4:02 PM, Vince Rice wrote: >> On Oct 19, 2017, at 2:08 PM, cyg Simple wrote: >> >> On 10/19/2017 2:51 PM, Yaakov Selkowitz wrote: >>> >>> When you *really* need to use --build and/or --host, then you need to >>> use x86_64-pc-cygwin, as that is our chosen name. >> >> Then config.guess needs to change to match the chosen name!! >> >> Why confuse everyone? Make up your mind and choose one. I can submit >> the patches to the config maintainer. > > It's not confusing everyone. You're the only one jumping up and down, you > have refused to provide information needed to help you, and in spite of that, > Yaakov has given you a reasonable guess at a solution. > I'm not providing the name of the package because I don't need help configuring it and I don't want the discussion to become how to do that. > I can only conclude you just like to hear yourself scream. If only we were in > space… I would float near you and SCREAM in your ear. At least I have Brian thinking that config.guess needs to change so it has helped some. So, Vince, what is the triplet you like for x86_64 Cygwin? -- cyg Simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Which is it -pc- or -unknown-
On 2017-10-19 14:08, cyg Simple wrote: > On 10/19/2017 2:51 PM, Yaakov Selkowitz wrote: >> >> When you *really* need to use --build and/or --host, then you need to >> use x86_64-pc-cygwin, as that is our chosen name. > > Then config.guess needs to change to match the chosen name!! No, it doesn't. Don't confuse the default triplet with the chosen one. > Why confuse everyone? Make up your mind and choose one. We have chosen one, and this is what everyone needs to use, and it does NOT have to match the default. > I can submit the patches to the config maintainer. The code is correct as it is; the only thing needing to be changed here is incorrect assumptions. -- Yaakov signature.asc Description: OpenPGP digital signature
Re: Which is it -pc- or -unknown-
On 10/19/2017 4:21 PM, Yaakov Selkowitz wrote: > On 2017-10-19 14:08, cyg Simple wrote: >> On 10/19/2017 2:51 PM, Yaakov Selkowitz wrote: >>> >>> When you *really* need to use --build and/or --host, then you need to >>> use x86_64-pc-cygwin, as that is our chosen name. >> >> Then config.guess needs to change to match the chosen name!! > > No, it doesn't. Don't confuse the default triplet with the chosen one. > >> Why confuse everyone? Make up your mind and choose one. > > We have chosen one, and this is what everyone needs to use, and it does > NOT have to match the default. > >> I can submit the patches to the config maintainer. > > The code is correct as it is; the only thing needing to be changed here > is incorrect assumptions. My assumption is because of config.guess' default. It isn't incorrect, it is a valid assumption. You cannot have both, it is one or the other. I've Cc Ben Elliston to give his opinion. Sorry, Ben. -- cyg Simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Which is it -pc- or -unknown-
On 2017-10-19 15:21, cyg Simple wrote: > I'm not providing the name of the package because I don't need help > configuring it and I don't want the discussion to become how to do that. This is *exactly* what this discussion *should* have been about from the beginning, because that would have been a productive discussion. This, unfortunately, has not been. > I would float near you and SCREAM in your ear. At least I have Brian > thinking that config.guess needs to change so it has helped some. > > So, Vince, what is the triplet you like for x86_64 Cygwin? This isn't a matter for debate and we're not taking a vote on it. For (hopefully) the last time: 1) our chosen toolchain triplet is x86_64-pc-cygwin. This is what you need to use when specifying --build and/or --host. 2) the output of config.guess is a default and does NOT reflect, or need to match, our chosen triplet. There is nothing to fix in config.guess. 3) the *correct* course of action if config.{guess,sub} do not recognize 64-bit Cygwin is to update those files (e.g. with gnuconfigize in cygport). -- Yaakov signature.asc Description: OpenPGP digital signature
Re: Which is it -pc- or -unknown-
> On Oct 19, 2017, at 3:21 PM, cyg Simple wrote: > > On 10/19/2017 4:02 PM, Vince Rice wrote: >>> On Oct 19, 2017, at 2:08 PM, cyg Simple wrote: >>> >>> On 10/19/2017 2:51 PM, Yaakov Selkowitz wrote: When you *really* need to use --build and/or --host, then you need to use x86_64-pc-cygwin, as that is our chosen name. >>> >>> Then config.guess needs to change to match the chosen name!! >>> >>> Why confuse everyone? Make up your mind and choose one. I can submit >>> the patches to the config maintainer. >> >> It's not confusing everyone. You're the only one jumping up and down, you >> have refused to provide information needed to help you, and in spite of >> that, Yaakov has given you a reasonable guess at a solution. >> > > I'm not providing the name of the package because I don't need help > configuring it and I don't want the discussion to become how to do that. > >> I can only conclude you just like to hear yourself scream. If only we were >> in space… > > I would float near you and SCREAM in your ear. At least I have Brian > thinking that config.guess needs to change so it has helped some. > > So, Vince, what is the triplet you like for x86_64 Cygwin? You missed the point of the joke, just like you've missed the point of this entire conversation. I'll leave you to Yaakov. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Which is it -pc- or -unknown-
On 2017-10-19 15:02, cyg Simple wrote: > On 10/19/2017 3:54 PM, Brian Inglis wrote: >> On 2017-10-19 12:59, Yaakov Selkowitz wrote: >>> On 2017-10-19 13:40, cyg Simple wrote: x86_64-pc-cygwin is just not correct regardless of the lack of past issues. >>> >>> As I have said several times, this assertion is incorrect. You need to >>> use the triplet which matches the toolchain with which you are building. >>> For example, Fedora and RHEL all use $arch-redhat-linux as their >>> triplet, and there is nothing wrong with that. >> >> Vendor -unknown- is just a default in various config cases, so specifying >> -pc- >> for consistency on Cygwin builds is a valid choice by the maintainers. > > FINE! But config.guess should match the CHOSEN one. Incorrect assumption. >> Perhaps a statement on the cygwin-apps list could clarify what should be >> done by >> maintainers to ensure this override, and maybe retire the use of -unknown- by >> any Cygwin apps in future, with a notice to this (cygwin) list for those who >> choose to build packages from net sources. > > I don't care which is used as long as config.guess matches what is chosen. That is not a requirement. >> Perhaps also patches should be submitted to the config and automake >> maintainers >> to ensure that {i*,x86_64}:CYGWIN*:*... always produce vendor -pc-. Not sure >> about vendors for {amd64,powerpcle}:CYGWIN*:*... in config.guess, which are >> currently also set to -unknown-. > > Exactly what I'm saying. It needs to match what is being distributed > just for consistency and to avoid confusion. No patch is needed here. -- Yaakov signature.asc Description: OpenPGP digital signature
Re: Which is it -pc- or -unknown-
On 2017-10-19 15:26, cyg Simple wrote: > My assumption is because of config.guess' default. It isn't incorrect, > it is a valid assumption. You cannot have both, it is one or the other. Your assumption that the default provided by config.guess must match the one we have chosen is incorrect. Once you are prepared to accept that, then we can help address whatever real-world issues you are encountering. > I've Cc Ben Elliston to give his opinion. Sorry, Ben. As the Cygwin maintainer of autotools (and, for that matter, the majority of our packages), I assure you that no changes are necessary. Trying to go over my head to upstream to tell me what our triplet should or shouldn't be is not the way to go about this. -- Yaakov signature.asc Description: OpenPGP digital signature
Re: Which is it -pc- or -unknown-
On 10/19/2017 4:35 PM, Yaakov Selkowitz wrote: > On 2017-10-19 15:02, cyg Simple wrote: >> On 10/19/2017 3:54 PM, Brian Inglis wrote: >>> On 2017-10-19 12:59, Yaakov Selkowitz wrote: On 2017-10-19 13:40, cyg Simple wrote: > x86_64-pc-cygwin is just not correct regardless of the lack of past > issues. As I have said several times, this assertion is incorrect. You need to use the triplet which matches the toolchain with which you are building. For example, Fedora and RHEL all use $arch-redhat-linux as their triplet, and there is nothing wrong with that. >>> >>> Vendor -unknown- is just a default in various config cases, so specifying >>> -pc- >>> for consistency on Cygwin builds is a valid choice by the maintainers. >> >> FINE! But config.guess should match the CHOSEN one. > > Incorrect assumption. > You keep saying my assumption is incorrect but that isn't the case. My assumption is based on data supplied by the configure process. >>> Perhaps a statement on the cygwin-apps list could clarify what should be >>> done by >>> maintainers to ensure this override, and maybe retire the use of -unknown- >>> by >>> any Cygwin apps in future, with a notice to this (cygwin) list for those who >>> choose to build packages from net sources. >> >> I don't care which is used as long as config.guess matches what is chosen. > > That is not a requirement. > >>> Perhaps also patches should be submitted to the config and automake >>> maintainers >>> to ensure that {i*,x86_64}:CYGWIN*:*... always produce vendor -pc-. Not sure >>> about vendors for {amd64,powerpcle}:CYGWIN*:*... in config.guess, which are >>> currently also set to -unknown-. >> >> Exactly what I'm saying. It needs to match what is being distributed >> just for consistency and to avoid confusion. > > No patch is needed here. So says you! The vendor portion has been agreed to be -pc- and it isn't -unknown-, a patch then should be created for config.guess to match the agreed upon vendor. The config.guess script supplies the default to configure for the build and host. The fact that config.guess supplies x86_64-unknown-cygwin is used by configure is the reason my assumptions are correct. If -pc- should be used then config.guess needs to change. -- cyg Simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Which is it -pc- or -unknown-
On 2017-10-19 16:00, cyg Simple wrote: > On 10/19/2017 4:35 PM, Yaakov Selkowitz wrote: >> On 2017-10-19 15:02, cyg Simple wrote: >>> On 10/19/2017 3:54 PM, Brian Inglis wrote: On 2017-10-19 12:59, Yaakov Selkowitz wrote: > On 2017-10-19 13:40, cyg Simple wrote: >> x86_64-pc-cygwin is just not correct regardless of the lack of past >> issues. > > As I have said several times, this assertion is incorrect. You need to > use the triplet which matches the toolchain with which you are building. > For example, Fedora and RHEL all use $arch-redhat-linux as their > triplet, and there is nothing wrong with that. Vendor -unknown- is just a default in various config cases, so specifying -pc- for consistency on Cygwin builds is a valid choice by the maintainers. >>> >>> FINE! But config.guess should match the CHOSEN one. >> >> Incorrect assumption. > > You keep saying my assumption is incorrect but that isn't the case. My > assumption is based on data supplied by the configure process. Your assumption is that the default and chosen triplets must be one and the same. They are not, they need not be, and we are far from being alone in this regard. Once you accept *that*, then the rest of this will make sense. Several of us with years of experience in these matters have tried to help explain this to you. Repeatedly pointing to the same piece of "evidence" as supposed proof for your "case", as if it were up for debate, isn't helping you to understand how things actually work. This discussion would be better served by being specific about the package you are trying to build, how you are trying to build it, and the exact error message you are seeing. -- Yaakov signature.asc Description: OpenPGP digital signature
Re: Which is it -pc- or -unknown-
On 10/19/2017 04:18 PM, cyg Simple wrote: > On 10/19/2017 10:18 AM, Ken Brown wrote: >> On 10/19/2017 9:19 AM, cyg Simple wrote: >>> On 10/18/2017 6:58 PM, JonY wrote: I agree with Yaakov, why does it need to change? >>> >>> See my response to Yaakov. If you supply explicit host and build to >>> configure it does not work. >> >> So don't do that. Specifying host is for cross-compilation. Specifying >> build without host is for overriding the result of config.guess (never >> necessary on Cygwin). See >> >> >> https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Specifying-Target-Triplets.html >> >> >> In particular: "If you mean to override the result of config.guess, use >> --build, not --host, since the latter enables cross-compilation." >> > > So?! It is still incorrect for the --target of the GCC build to be > x86_64-pc-cygwin. My example didn't specify a different build from > host. I ran across this from a package that was refusing to accept the > config.guess build triplet so I tried specifying both. At that point it > failed to find x86_64-unknown-cygwin-gcc. > > And ./configure --build=`/path/to/config.guess` will not work either as > currently delivered. > > x86_64-pc-cygwin IS NOT CORRECT. It needs fixed in the build process. > If it means that much to you, use -pc- instead. signature.asc Description: OpenPGP digital signature
Re: Which is it -pc- or -unknown-
On 2017-10-19 15:14, Yaakov Selkowitz wrote: > On 2017-10-19 16:00, cyg Simple wrote: >> On 10/19/2017 4:35 PM, Yaakov Selkowitz wrote: >>> On 2017-10-19 15:02, cyg Simple wrote: On 10/19/2017 3:54 PM, Brian Inglis wrote: > On 2017-10-19 12:59, Yaakov Selkowitz wrote: >> On 2017-10-19 13:40, cyg Simple wrote: >>> x86_64-pc-cygwin is just not correct regardless of the lack of past >>> issues. >> >> As I have said several times, this assertion is incorrect. You need to >> use the triplet which matches the toolchain with which you are building. >> For example, Fedora and RHEL all use $arch-redhat-linux as their >> triplet, and there is nothing wrong with that. > > Vendor -unknown- is just a default in various config cases, so specifying > -pc- > for consistency on Cygwin builds is a valid choice by the maintainers. FINE! But config.guess should match the CHOSEN one. >>> >>> Incorrect assumption. >> >> You keep saying my assumption is incorrect but that isn't the case. My >> assumption is based on data supplied by the configure process. > > Your assumption is that the default and chosen triplets must be one and > the same. They are not, they need not be, and we are far from being > alone in this regard. Once you accept *that*, then the rest of this > will make sense. > > Several of us with years of experience in these matters have tried to > help explain this to you. Repeatedly pointing to the same piece of > "evidence" as supposed proof for your "case", as if it were up for > debate, isn't helping you to understand how things actually work. This > discussion would be better served by being specific about the package > you are trying to build, how you are trying to build it, and the exact > error message you are seeing. I think the OP's problem is he knows no way to override the default and use only the standard ./configure && make build approach. This seems to be explained somewhat by running $ info autoconf "Site Defaults". The OP could take a build config.cache and save it in /etc/config.cache, change all -unknown-cygwin to -pc-cygwin, then create a shell script /etc/config.site like: # /etc/config.site for configure # # setup with export CONFIG_SITE=/etc/config.site in ~/.*profile # # Give Autoconf 2.x generated configure scripts a shared default # cache file for feature test results, architecture-specific. [ "$cache_file" = "/dev/null" ] && cache_file="/etc/config.cache" then as noted above add "export CONFIG_SITE=/etc/config.site" to some ~/.*profile so it gets set up automatically. He could also set up the script and cache files under $prefix/share/ for any specific install targets, and not export CONFIG_SITE. Or he could use cygport with the Cygwin source packages. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Which is it -pc- or -unknown-
On 2017-10-19 18:21, Brian Inglis wrote: > I think the OP's problem is he knows no way to override the default and use > only > the standard ./configure && make build approach. Which works just fine btw, so there's no need to override it. > The OP could take a build config.cache and save it in /etc/config.cache, > change > all -unknown-cygwin to -pc-cygwin, then create a shell script /etc/config.site > like: [snip] None of this is necessary. > Or he could use cygport with the Cygwin source packages. And as much as I'd recommend it, it's not strictly necessary for sources that one is building for themselves. Even cygport only specifies --build and --host when cross-compiling, not normally. -- Yaakov signature.asc Description: OpenPGP digital signature
Re: Which is it -pc- or -unknown-
On Thu, 19 Oct 2017 17:00:12, cyg Simple wrote: So says you! The vendor portion has been agreed to be -pc- and it isn't -unknown-, a patch then should be created for config.guess to match the agreed upon vendor. The config.guess script supplies the default to configure for the build and host. The fact that config.guess supplies x86_64-unknown-cygwin is used by configure is the reason my assumptions are correct. If -pc- should be used then config.guess needs to change. Let us bring some sanity to this discussion/argument. With this repository: git clone --depth 1 git://github.com/php/php-src cd php-src ./buildconf Test 1: $ ./configure --host x86_64-pc-cygwin checking build system type... x86_64-unknown-cygwin checking host system type... x86_64-pc-cygwin checking for x86_64-pc-cygwin-gcc... x86_64-pc-cygwin-gcc checking whether the C compiler works... yes Test 2: $ ./configure --host x86_64-unknown-cygwin checking build system type... x86_64-unknown-cygwin checking host system type... x86_64-unknown-cygwin checking for x86_64-unknown-cygwin-gcc... no checking for cc... cc checking whether the C compiler works... yes So yes, specifying "--host x86_64-unknown-cygwin" causes it to not find "x86_64-unknown-cygwin-gcc.exe", which makes sense because that doesnt exist. However notice carefully in the next step that it finds "x86_64-pc-cygwin-gcc.exe: $ ls -l /bin/cc lrwxrwxrwx 1 Steven None 7 Sep 9 17:18 /bin/cc -> gcc.exe $ find /bin -samefile /bin/gcc /bin/gcc.exe /bin/x86_64-pc-cygwin-gcc-6.4.0.exe /bin/x86_64-pc-cygwin-gcc.exe -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Which is it -pc- or -unknown-
On 2017-10-19 18:49, Steven Penny wrote: > On Thu, 19 Oct 2017 17:00:12, cyg Simple wrote: >> So says you! The vendor portion has been agreed to be -pc- and it isn't >> -unknown-, a patch then should be created for config.guess to match the >> agreed upon vendor. The config.guess script supplies the default to >> configure for the build and host. The fact that config.guess supplies >> x86_64-unknown-cygwin is used by configure is the reason my assumptions >> are correct. If -pc- should be used then config.guess needs to change. > > Let us bring some sanity to this discussion/argument. With this repository: > > git clone --depth 1 git://github.com/php/php-src > cd php-src > ./buildconf > > Test 1: > > $ ./configure --host x86_64-pc-cygwin > checking build system type... x86_64-unknown-cygwin > checking host system type... x86_64-pc-cygwin > checking for x86_64-pc-cygwin-gcc... x86_64-pc-cygwin-gcc > checking whether the C compiler works... yes Two things wrong with this: 1) If you specify --host, you need to specify --build as well. 2) If you're not cross-compiling or building a toolchain package, you shouldn't be specifying either. > Test 2: > > $ ./configure --host x86_64-unknown-cygwin > checking build system type... x86_64-unknown-cygwin > checking host system type... x86_64-unknown-cygwin > checking for x86_64-unknown-cygwin-gcc... no > checking for cc... cc > checking whether the C compiler works... yes > > So yes, specifying "--host x86_64-unknown-cygwin" causes it to not find > "x86_64-unknown-cygwin-gcc.exe", which makes sense because that doesnt > exist. True, when you *need* to specify --build/--host, then x86_64-pc-cygwin should be used. When not (as in this case), then omit them. -- Yaakov signature.asc Description: OpenPGP digital signature
Re: Which is it -pc- or -unknown-
On 2017-10-19 19:11, Yaakov Selkowitz wrote: > On 2017-10-19 18:49, Steven Penny wrote: >> On Thu, 19 Oct 2017 17:00:12, cyg Simple wrote: >>> So says you! The vendor portion has been agreed to be -pc- and it isn't >>> -unknown-, a patch then should be created for config.guess to match the >>> agreed upon vendor. The config.guess script supplies the default to >>> configure for the build and host. The fact that config.guess supplies >>> x86_64-unknown-cygwin is used by configure is the reason my assumptions >>> are correct. If -pc- should be used then config.guess needs to change. >> Let us bring some sanity to this discussion/argument. With this repository: >> git clone --depth 1 git://github.com/php/php-src >> cd php-src >> ./buildconf >> Test 1: >> $ ./configure --host x86_64-pc-cygwin >> checking build system type... x86_64-unknown-cygwin >> checking host system type... x86_64-pc-cygwin >> checking for x86_64-pc-cygwin-gcc... x86_64-pc-cygwin-gcc >> checking whether the C compiler works... yes > Two things wrong with this: > 1) If you specify --host, you need to specify --build as well. > 2) If you're not cross-compiling or building a toolchain package, you > shouldn't be specifying either. >> Test 2: >> $ ./configure --host x86_64-unknown-cygwin >> checking build system type... x86_64-unknown-cygwin >> checking host system type... x86_64-unknown-cygwin >> checking for x86_64-unknown-cygwin-gcc... no >> checking for cc... cc >> checking whether the C compiler works... yes >> So yes, specifying "--host x86_64-unknown-cygwin" causes it to not find >> "x86_64-unknown-cygwin-gcc.exe", which makes sense because that doesnt >> exist. > True, when you *need* to specify --build/--host, then x86_64-pc-cygwin > should be used. When not (as in this case), then omit them. So if autoconf does not find the triplet prefixed build tool, it should use the non-triplet prefixed build tool, and if it doesn't do that, then there is an issue either with the package autoconf setup or the autoconf package being used? If that is the case with the OP's build, they should report it to the upstream package maintainer. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Which is it -pc- or -unknown-
On 10/19/2017 4:33 PM, Yaakov Selkowitz wrote: > 2) the output of config.guess is a default and does NOT reflect, or need > to match, our chosen triplet. There is nothing to fix in config.guess. Fine, it doesn't have to match, why don't you want it to? Don't give me the historical reasons idea. Scenario: I know nothing of your *chosen* x86_64-pc-cygwin. I have found a new compiler toolchain I want to build from source. I use the defaults for the configure script. I end up with host tools of x86_64-unknown-cygwin. This now doesn't match your *chosen* x86_64-pc-cygwin. Scenario: I know nothing of your *chosen* x86_64-pc-cygwin. I download the latest version of binutils I use the defaults for the configure script. I end up with host tools of x86_64-unknown-cygwin. This now doesn't match your *chosen* x86-64-pc-cygwin. What is your angst toward changing the *default* to match the *chosen*? -- cyg Simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Which is it -pc- or -unknown-
On 2017-10-20 08:28, cyg Simple wrote: > On 10/19/2017 4:33 PM, Yaakov Selkowitz wrote: >> 2) the output of config.guess is a default and does NOT reflect, or need >> to match, our chosen triplet. There is nothing to fix in config.guess. > > Fine, it doesn't have to match, why don't you want it to? Because there is no correlation, is completely normal, and therefore no need to special case Cygwin. -- Yaakov signature.asc Description: OpenPGP digital signature
Re: Which is it -pc- or -unknown-
On 10/20/2017 11:24 AM, Yaakov Selkowitz wrote: > On 2017-10-20 08:28, cyg Simple wrote: >> On 10/19/2017 4:33 PM, Yaakov Selkowitz wrote: >>> 2) the output of config.guess is a default and does NOT reflect, or need >>> to match, our chosen triplet. There is nothing to fix in config.guess. >> >> Fine, it doesn't have to match, why don't you want it to? > > Because there is no correlation, is completely normal, and therefore no > need to special case Cygwin. > What is *normal* about it? Just because other's do it? I gave scenarios in the mail which you elided from your response which give credence to a reason to change it. There is nothing that is *normal* in any scenario of config.guess. It is what the maintainers decide. You've not given a reason for the decision to make the *default* not match the *chosen* vendor. You just stand on the podium of unreason to state something as normal that has no merit in being normal. Doing so doesn't make Cygwin a special case. Yes, I can override the default, but I shouldn't have to is my reasoning of normal. In my sense of reasoning the normal should be the *default* matching the *chosen*. Why is it different? Give a reason not just some lame excuse. -- cyg Simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Which is it -pc- or -unknown-
On 2017-10-20 10:44, cyg Simple wrote: > On 10/20/2017 11:24 AM, Yaakov Selkowitz wrote: >> On 2017-10-20 08:28, cyg Simple wrote: >>> On 10/19/2017 4:33 PM, Yaakov Selkowitz wrote: 2) the output of config.guess is a default and does NOT reflect, or need to match, our chosen triplet. There is nothing to fix in config.guess. >>> >>> Fine, it doesn't have to match, why don't you want it to? >> >> Because there is no correlation, is completely normal, and therefore no >> need to special case Cygwin. > > What is *normal* about it? Just because other's do it? I gave > scenarios in the mail which you elided from your response which give > credence to a reason to change it. You are still looking at these from the same perspective you were yesterday. Let me restate this one (hopefully last) time: Your assumption is that the default and chosen triplets must/should be one and the same. They are not, they need not be, and we are far from being alone in this regard. Once you accept *that*, then the rest of this will make sense. Further insistence that they should be is counter-productive at this point. -- Yaakov signature.asc Description: OpenPGP digital signature
Re: Which is it -pc- or -unknown-
On 10/20/2017 11:54 AM, Yaakov Selkowitz wrote: > On 2017-10-20 10:44, cyg Simple wrote: >> On 10/20/2017 11:24 AM, Yaakov Selkowitz wrote: >>> On 2017-10-20 08:28, cyg Simple wrote: On 10/19/2017 4:33 PM, Yaakov Selkowitz wrote: > 2) the output of config.guess is a default and does NOT reflect, or need > to match, our chosen triplet. There is nothing to fix in config.guess. Fine, it doesn't have to match, why don't you want it to? >>> >>> Because there is no correlation, is completely normal, and therefore no >>> need to special case Cygwin. >> >> What is *normal* about it? Just because other's do it? I gave >> scenarios in the mail which you elided from your response which give >> credence to a reason to change it. > > You are still looking at these from the same perspective you were > yesterday. Let me restate this one (hopefully last) time: > > Your assumption is that the default and chosen triplets must/should be > one and the same. No, I assume no such thing. > They are not, they need not be, and we are far from > being alone in this regard. Once you accept *that*, then the rest of > this will make sense. Further insistence that they should be is > counter-productive at this point. You still skirt a reasoning for it to be so. They don't need to be but why aren't they? You've failed to answer the question by assuming I need to be educated on how it is and refusing to give me a reason of why it is. I know that I can specify something other than the default. I don't know why the default is not the same as the chosen. You keep failing to answer that question. Why does it *need* to stay -unknown- instead of -pc-? -- cyg Simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Which is it -pc- or -unknown-
On 10/20/2017 12:11 PM, cyg Simple wrote: > On 10/20/2017 11:54 AM, Yaakov Selkowitz wrote: >> On 2017-10-20 10:44, cyg Simple wrote: >>> On 10/20/2017 11:24 AM, Yaakov Selkowitz wrote: On 2017-10-20 08:28, cyg Simple wrote: > On 10/19/2017 4:33 PM, Yaakov Selkowitz wrote: >> 2) the output of config.guess is a default and does NOT reflect, or need >> to match, our chosen triplet. There is nothing to fix in config.guess. > > Fine, it doesn't have to match, why don't you want it to? Because there is no correlation, is completely normal, and therefore no need to special case Cygwin. >>> >>> What is *normal* about it? Just because other's do it? I gave >>> scenarios in the mail which you elided from your response which give >>> credence to a reason to change it. >> >> You are still looking at these from the same perspective you were >> yesterday. Let me restate this one (hopefully last) time: >> >> Your assumption is that the default and chosen triplets must/should be >> one and the same. > > No, I assume no such thing. > >> They are not, they need not be, and we are far from >> being alone in this regard. Once you accept *that*, then the rest of >> this will make sense. Further insistence that they should be is >> counter-productive at this point. > > You still skirt a reasoning for it to be so. They don't need to be but > why aren't they? You've failed to answer the question by assuming I > need to be educated on how it is and refusing to give me a reason of why > it is. I know that I can specify something other than the default. I > don't know why the default is not the same as the chosen. You keep > failing to answer that question. Why does it *need* to stay -unknown- > instead of -pc-? > And to further my proposal that -pc- should be the correct config.guess vendor I find the following comment in config.sub. # We use `pc' rather than `unknown' # because (1) that's what they normally are, and # (2) the word "unknown" tends to confuse beginning users. i*86 | x86_64) basic_machine=$basic_machine-pc ;; I also find in the config.guess file the following filter for Linux on x86_64. x86_64:Linux:*:*) echo ${UNAME_MACHINE}-pc-linux-${LIBC} exit ;; -- cyg Simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Which is it -pc- or -unknown-
On 20/10/2017 17:44, cyg Simple wrote: On 10/20/2017 11:24 AM, Why is it different? Give a reason not just some lame excuse. This is extremely rude, in my opinion. Yaakov has been extremely patient with you but you are always disregarding our point of view, that only shows us that you have a bad understanding of the triplet concept. Please consider one point, that clearly you are missing, about who has the experience and knowledge on the matter. We have around 3800 packages on cygwin, and on https://www.cygwin.com/cygwin-pkg-maint you will see who is the maintainer of each one The top contributors are: 2717 Yaakov Selkowitz 212 Achim Gratz 169 Jari Aalto 149 Marco Atzeri 82 Ken Brown 70 Achim Gratz/Yaakov Selkowitz You don't tell the brewer how to make the beer. Cheers from Munich Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Which is it -pc- or -unknown-
On 10/20/2017 11:11 AM, cyg Simple wrote: I may regret joining this thread, but here goes. >> Your assumption is that the default and chosen triplets must/should be >> one and the same. > > No, I assume no such thing. > >> They are not, they need not be, and we are far from >> being alone in this regard. Once you accept *that*, then the rest of >> this will make sense. Further insistence that they should be is >> counter-productive at this point. > > You still skirt a reasoning for it to be so. They don't need to be but > why aren't they? Because Cygwin is not the only platform where there is this discrepancy. Having a different guess from the chosen triplet is nothing unique to Cygwin, and therefore, downstream Cygwin need not make any effort to change things. Our reasoning for them to be different can thus be termed "inertia", if you'd like. But it's not a bug, because it doesn't break correct usage, and therefore it does not urgently need to be changed, certainly not with a downstream-only patch. > You've failed to answer the question by assuming I > need to be educated on how it is and refusing to give me a reason of why > it is. I know that I can specify something other than the default. I > don't know why the default is not the same as the chosen. You keep > failing to answer that question. Why does it *need* to stay -unknown- > instead of -pc-? No one says the default NEEDs to stay -unknown-, but the point we're making is that no one has yet provided proof of why it CANNOT stay -unknown-, and that absent any proof for a reason to change, it's better to leave well enough alone. You are more than welcome to propose a patch to upstream config.guess that provides a different default (config.guess is Free Software, after all - as long as you abide by the license terms, you can write and post any patch you like, whether or not we agree with it; but in turn, you have to be prepared that upstream may reject your patch which leaves you with carrying your patch in your personal downstream only); but be aware that your patch may go nowhere upstream. Part of that is that upstream already knows about MULTIPLE platforms where the default string guesses differently than the chosen triple (so Cygwin is not special in that regards), and part of that is that upstream tends to prefer deferring to the developers of a given platform where that is practical, and this thread on the Cygwin list is a good case where the developers of Cygwin have stated that such a patch is not necessary (it might not be harmful, but it is not necessary). Or, if upstream does, for some reason, agree with your patch, it still is not something so urgent that we would backport it downstream any faster than normal propagation of other upstream packages slowly picking up newer config.guess as they release new tarballs. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org signature.asc Description: OpenPGP digital signature
Re: Which is it -pc- or -unknown-
On 2017-10-20 11:41, Marco Atzeri wrote: > On 20/10/2017 17:44, cyg Simple wrote: >> On 10/20/2017 11:24 AM, >> Why is it different? Give a reason not just some lame excuse. > This is extremely rude, in my opinion. He's not asking the question he needs answered and is getting exasperated. > You don't tell the brewer how to make the beer. I think the home brewer wants to make the standard brew, but no one is explaining how to get "./configure && make" to produce the *PC* product, instead of some /unknown/ swill. ;^> "Euch ist bekannt was wir bedürfen, wir wollen starke Getränke schlürfen!" Bayern ist toll - Alles Gute - Prost! Slainthe! Cheers! -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Which is it -pc- or -unknown-
On 10/20/2017 2:34 PM, Eric Blake wrote: > On 10/20/2017 11:11 AM, cyg Simple wrote: > > I may regret joining this thread, but here goes. > But thanks for doing so anyway. >>> Your assumption is that the default and chosen triplets must/should be >>> one and the same. >> >> No, I assume no such thing. >> >>> They are not, they need not be, and we are far from >>> being alone in this regard. Once you accept *that*, then the rest of >>> this will make sense. Further insistence that they should be is >>> counter-productive at this point. >> >> You still skirt a reasoning for it to be so. They don't need to be but >> why aren't they? > > Because Cygwin is not the only platform where there is this discrepancy. But only very few. Even Linux on x86_64 has a guess of vendor -pc-. x86_64:Linux:*:*) echo ${UNAME_MACHINE}-pc-linux-${LIBC} exit ;; > Having a different guess from the chosen triplet is nothing unique to > Cygwin, and therefore, downstream Cygwin need not make any effort to > change things. Our reasoning for them to be different can thus be > termed "inertia", if you'd like. But it's not a bug, because it doesn't > break correct usage, and therefore it does not urgently need to be > changed, certainly not with a downstream-only patch. > I have backed off of the idea of downstream changes ever since Yaakov stated that the chosen vendor is -pc- for the packages. Yes, I was under the impression that the default and chosen should match but I corrected my thinking on that. >> You've failed to answer the question by assuming I >> need to be educated on how it is and refusing to give me a reason of why >> it is. I know that I can specify something other than the default. I >> don't know why the default is not the same as the chosen. You keep >> failing to answer that question. Why does it *need* to stay -unknown- >> instead of -pc-? > > No one says the default NEEDs to stay -unknown-, but the point we're > making is that no one has yet provided proof of why it CANNOT stay > -unknown-, and that absent any proof for a reason to change, it's better > to leave well enough alone. > But if it is a default and all the maintainers choose -pc- instead of -unknown- during the configure process then it doesn't matter what the default is except in the case of the default providing a different host tool set than what is delivered by setup. So if someone else build binutils or some other package providing host named tools using the default host and build then the host tool set is named x86_64-unknown-cygwin instead of x86_64-pc-cygwin. This is why I am so adamant for changing config.guess. Currently for me to build binutils and match what is supplied by setup.exe without using cygport and using just configure then I must supply --host and --build to configure so that I get a matching host set. > You are more than welcome to propose a patch to upstream config.guess > that provides a different default (config.guess is Free Software, after > all - as long as you abide by the license terms, you can write and post > any patch you like, whether or not we agree with it; but in turn, you > have to be prepared that upstream may reject your patch which leaves you > with carrying your patch in your personal downstream only); but be aware > that your patch may go nowhere upstream. Part of that is that upstream > already knows about MULTIPLE platforms where the default string guesses > differently than the chosen triple (so Cygwin is not special in that > regards), and part of that is that upstream tends to prefer deferring to > the developers of a given platform where that is practical, and this > thread on the Cygwin list is a good case where the developers of Cygwin > have stated that such a patch is not necessary (it might not be harmful, > but it is not necessary). Or, if upstream does, for some reason, agree > with your patch, it still is not something so urgent that we would > backport it downstream any faster than normal propagation of other > upstream packages slowly picking up newer config.guess as they release > new tarballs. And I'm willing to supply that patch. Config.guess needs a one line change and no change to config.sub. Config.sub already provides the -pc- vendor for the x86_64-cygwin input. Yet another reason for the patch to config.guess. Once the patch is applied then attrition will take care of downstream use. -- cyg Simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Which is it -pc- or -unknown-
On 10/20/2017 2:44 PM, Brian Inglis wrote: > On 2017-10-20 11:41, Marco Atzeri wrote: >> On 20/10/2017 17:44, cyg Simple wrote: >>> On 10/20/2017 11:24 AM, >>> Why is it different? Give a reason not just some lame excuse. >> This is extremely rude, in my opinion. > > He's not asking the question he needs answered and is getting exasperated. > I asked the question I wanted to ask, it was answered. >> You don't tell the brewer how to make the beer. > > I think the home brewer wants to make the standard brew, but no one is > explaining how to get "./configure && make" to produce the *PC* product, > instead > of some /unknown/ swill. ;^> > This isn't the question that needed answered. Sorry but I'm only talking about the default vendor from config.guess versus the chosen vendor and don't need help with ./configure && make. Erik Blake finally supplied a modicum of a reason why -unknown- is used but wasn't insistent that it needed to stay -unknown-. Feel free to tell me why you think config.guess should supply a default vendor of -unknown- for Cygwin even when config.sub doesn't? The purpose of config.guess is to supply configure the default build environment. If the host isn't supplied to configure then it defaults to match the build string. Since the build environment for Cygwin is x86_64-pc-cygwin then config.guess should default to that. This isn't a problem with most packages because they don't provide tools based on the host triplet. However, there are packages that do use the host triplet to provide a hosted set of tools. -- cyg Simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Which is it -pc- or -unknown-
On 10/20/2017 1:41 PM, Marco Atzeri wrote: > On 20/10/2017 17:44, cyg Simple wrote: >> On 10/20/2017 11:24 AM, > >> Why is it different? Give a reason not just >> some lame excuse. > > This is extremely rude, in my opinion. > Thanks for your opinion. I reworded most of my original text in the mail but missed this one. > Yaakov has been extremely patient with you but you are always > disregarding our point of view, that only shows us that > you have a bad understanding of the triplet concept. > > Please consider one point, that clearly you are missing, > about who has the experience and knowledge on the matter. > You don't know how much experience I also have. Really, it isn't about that. > We have around 3800 packages on cygwin, > and on https://www.cygwin.com/cygwin-pkg-maint > you will see who is the maintainer of each one > > The top contributors are: > > 2717 Yaakov Selkowitz I appreciate what Yaakov does but I bet these are not built in native Cygwin mode so a host must be supplied. In native mode the default is typically used and currently it doesn't match the expected host environment. > 212 Achim Gratz > 169 Jari Aalto > 149 Marco Atzeri > 82 Ken Brown > 70 Achim Gratz/Yaakov Selkowitz > > > You don't tell the brewer how to make the beer. The brewer is using a recipe to make the beer. That doesn't mean the recipe cannot be improved. But in this case the brewer doesn't need to change anything other than the suggestion of which host the recipe is brewed on. -- cyg Simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Which is it -pc- or -unknown-
On 2017-10-20 14:53, cyg Simple wrote: > I appreciate what Yaakov does but I bet these are not built in native > Cygwin mode so a host must be supplied. In native mode the default is > typically used and currently it doesn't match the expected host environment. You lose the bet. Every single package I ship is built natively(*) on Cygwin -- and hence without specifying build or host -- without any such problems. (Yes, I do provide a Fedora-to-Cygwin cross-compiler toolchain, but that is used primarily by those working on the newlib-cygwin code; I don't use it myself.) Now, can we start discussing whatever specific issue you encountered, rather than being stuck on misconceptions? (*) Obviously my mingw64-* packages aren't "native" but cross-compiled with --build and --host specified, but they too are built on Cygwin, with our mingw64 toolchain. -- Yaakov signature.asc Description: OpenPGP digital signature
Re: Which is it -pc- or -unknown-
On Fri, 20 Oct 2017 15:53:28, cyg Simple wrote: I appreciate what Yaakov does but I bet these are not built in native Cygwin mode so a host must be supplied. In native mode the default is typically used and currently it doesn't match the expected host environment. Really this discussion boils down to a single question: What does not patching this break? Currently the answer is nothing, per my previous post: http://cygwin.com/ml/cygwin/2017-10/msg00227.html so the onus is not on Yaakov or whoever, the onus is on you to answer that question. Until then, you are breathing air that is not cold. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Which is it -pc- or -unknown-
On 10/20/2017 6:47 PM, Steven Penny wrote: > On Fri, 20 Oct 2017 15:53:28, cyg Simple wrote: >> I appreciate what Yaakov does but I bet these are not built in native >> Cygwin mode so a host must be supplied. In native mode the default is >> typically used and currently it doesn't match the expected host >> environment. > > Really this discussion boils down to a single question: > > What does not patching this break? > As Yakoov has already pointed out, nothing is broken. > Currently the answer is nothing, per my previous post: > > http://cygwin.com/ml/cygwin/2017-10/msg00227.html > > so the onus is not on Yaakov or whoever, the onus is on you to answer that > question. Until then, you are breathing air that is not cold. > Changing the default does improve the speed of configure because configure no longer needs to execute GCC to figure out where the build files are. Yes the time saved is small but time is expensive so any saving is a big deal, especially with such a small change. -- cyg Simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Which is it -pc- or -unknown-
On Sat, 21 Oct 2017 13:29:43, cyg Simple wrote: Changing the default does improve the speed of configure because configure no longer needs to execute GCC to figure out where the build files are. Yes the time saved is small but time is expensive so any saving is a big deal, especially with such a small change. I would argue that the difference you are talking about is less than 5 seconds. Which in a build like FFmpeg or similar, is statistically 0. So perhaps you have some data to show a non-trivial amount of time saved that would make this worth it? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Which is it -pc- or -unknown-
On 10/21/2017 3:26 PM, Steven Penny wrote: > On Sat, 21 Oct 2017 13:29:43, cyg Simple wrote: >> Changing the default does improve the speed of configure because >> configure no longer needs to execute GCC to figure out where the build >> files are. Yes the time saved is small but time is expensive so any >> saving is a big deal, especially with such a small change. > > I would argue that the difference you are talking about is less than 5 > seconds. 5 sec * 2300 packages = 11,500 sec 11,500 sec is 3.19 hours > Which in a build like FFmpeg or similar, is statistically 0. > 1 package once in a while doesn't matter. > So perhaps you have some data to show a non-trivial amount of time saved > that > would make this worth it? 3.19 hours * many builds is equal to days and weeks. The 5 sec is your guess, probably less but ... Minutia ends up being quite a large sum when you repeat a process over and over. The 2300 packages is a round of the number of packages Yaakov supports. -- cyg Simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Which is it -pc- or -unknown-
On Sat, 21 Oct 2017 16:17:13, cyg Simple wrote: 5 sec * 2300 packages = 11,500 sec 11,500 sec is 3.19 hours > Which in a build like FFmpeg or similar, is statistically 0. > 1 package once in a while doesn't matter. > So perhaps you have some data to show a non-trivial amount of time saved > that > would make this worth it? 3.19 hours * many builds is equal to days and weeks. The 5 sec is your guess, probably less but ... Minutia ends up being quite a large sum when you repeat a process over and over. The 2300 packages is a round of the number of packages Yaakov supports. I was wondering when your side of the discussion would finally fail, and here we have it. 1. You have provided no concrete examples, just some numbers pulled out of the air. Look, I can do that too! 5 sec * 1,000,000 packages = 5,000,000 sec! OMG PATCH IT NOW! 2. You specifically mention Yaakav, and you are right, he above probably anyone would have the most incentive to see this "fixed". However he has made it vividly clear that this "patch" (im quoting because you have also failed to produce one so far) isnt need and wont be accepted even if you wrote it. Good day. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple