From: Chris W. <ch...@qw...> - 2008-07-18 11:25:37
|
Hi all, I have been using MinGW for many years and I'm very happy that it exists and very grateful for all your work. Thank you. Now I would like to try MSYS in order to port some software that currently runs on Linux to Windows. I found the process so confusing that I have given up. I hope that you will take the following as constructive criticism rather than a random rant. If you prefer to take offence at my message, please delete it now, thank you. I am happy to update the wiki(s) once I have the necessary information and if I have permission to do so. So I knew that MSYS was a MinGW project and visited mingw.org to try to download it. I find the mingw.org front page difficult to navigate. The "Navigation Links" are not useful to me. I would find a set of links more like a standard project (about us, news, downloads, support, screenshots, etc.) much easier to use. "New MinGWiki" and "Old MinGWiki" mean nothing to me. I don't care who's online, not what documents were "last viewed" by some random user. Since I cannot find a "Download" link anywhere, I try MSYS, which takes me to "http://www.mingw.org/node/18". Again I cannot see any link to download anything here. "Getting Started" says nothing about MSYS. HOWTO links to this page on the old wiki: http://www.mingw.org/MinGWiki/index.php/MSYSBuildEnvironment. That page is most definitely not easy to follow. Perhaps the only useful line is "So the first exciting thing is to install the msysDVLPR-1.0.0-alpha-1.tar.gz file unarchiving it into the /msys directory." This contradicts other information that I have read online, more on that in a minute. Also, that file dates back to 2003 on Sourceforge. Frustrated, I try googling for "Installing MSYS". The only official page I can find, and the first link on Google, is this one: http://www.mingw.org/MinGWiki/index.php/Install%20MSYS. This is also from the old wiki. It says "Installing MSYS is as easy as executing a program. The installation is provided by means of a Win32 installer. Currently the installer compiler is INNO Setup version 2." I cannot find that Win32 installer anywhere. I don't even know what it's name is. It contradicts the previous instructions which say I have to download and extract a tarball. The page also says "Choose the version of the package you want; Snapshot, Candidate or Current;" but those links don't take me to download files, nor to Sourceforge FRS, nor to a page which contains a link to either of these. The only way I have found to actually download anything is via the front page of the website, right hand side, "Recent File Releases". The MinGW page (http://www.mingw.org/node/19) needs reformatting for the changed wiki syntax. Many links are broken (e.g. [history project history]) and bad formatting makes others difficult to read (e.g. !Links How to install MinGW How to get started with MinGW Building a Linux hosted Windows compiler Building a Windows hosted cross-compiler When will the next release be supported?). Still no link to sourceforge. Going back to the front page, I spy a link to "Updated: MinGW Automated Installer 5.1.4". This looks promising so I click on it. Finally I get to Sourceforget. I click "Downloads" and "Browse all files". There are a million different subprojects in MinGW. I find this very confusing. I have not much idea what I need to download. But I do see three projects starting with the word MSYS, and this reminds me of the MSYS installer comments above, so I investigate them. The first is "MSYS Base System: Technology Preview: MSYS-1.0.11". It is also the most recent. However, clicking the Download link gives me another huge raft of files, none of which I know if I need or not. I do not relish the prospect of downloading them all one by one from sourceforge. I would be here all day. MSYS-1.0.11-20071204.tar.bz2 looks the most promising, but it's a tar.bz2 not an installer, and I don't even know if I have a bunzip2 or tar on this system, and don't want to damage the archives by unpacking them with winzip. Also there is a msysCORE-1.0.11-2007.01.19-1.tar.bz2. How this is different to the previous file, I have no idea. The MSYS Supplementary Tools has no msys* files whatsoever. MSYS System Builder contains the msysDVLPR-1.0.0-alpha-1.tar.gz referred to above, but it's five years old, and again I suspect I will have problems with unpacking the tarball with winzip. I have not found an easy way to install MSYS. I give up. I'd like to make the following requests for changes to the website: * Please provide the standard links in your Navigation menu * Please provide download documentation for MSYS. * Please link to the promised holy grail "MSYS installer" if it exists * Please create one if it does not * Please do not expect people like me to navigate your massive file structure on Sourceforge to download anything; or * Please make the structure 100x simpler if you do. e.g. two projects, MinGW and MSYS; one file under each, which is the latest automated installer; hide everything else. Thank you for listening to my rant. I'm glad to get it off my chest. I hope that this situation can be improved and that I can help in some way to do so. Otherwise I'm afraid that MSYS, however good it is, will remain far out of reach for people who simply want tools that work. Now I'm going to download cygwin. Which is absolutely trivial by comparison. Cheers, Chris. -- _____ __ _ \ __/ / ,__(_)_ | Chris Wilson <0000 at qwirx.com> - Cambs UK | / (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Ruby/Perl/SQL Developer | \ _/_/_/_//_/___/ | We are GNU : free your mind & your software | |
From: Vincent T. <vt...@un...> - 2008-07-18 11:43:04
|
On Fri, 18 Jul 2008, Chris Wilson wrote: > Hi all, > > I have been using MinGW for many years and I'm very happy that it exists > and very grateful for all your work. Thank you. > > Now I would like to try MSYS in order to port some software that currently > runs on Linux to Windows. I found the process so confusing that I have > given up. I hope that you will take the following as constructive > criticism rather than a random rant. If you prefer to take offence at my > message, please delete it now, thank you. I am happy to update the wiki(s) > once I have the necessary information and if I have permission to do so. > > So I knew that MSYS was a MinGW project and visited mingw.org to try to > download it. I find the mingw.org front page difficult to navigate. The > "Navigation Links" are not useful to me. I would find a set of links more > like a standard project (about us, news, downloads, support, screenshots, > etc.) much easier to use. "New MinGWiki" and "Old MinGWiki" mean nothing > to me. I don't care who's online, not what documents were "last viewed" by > some random user. > > Since I cannot find a "Download" link anywhere, I try MSYS, which takes me > to "http://www.mingw.org/node/18". Again I cannot see any link to download > anything here. "Getting Started" says nothing about MSYS. HOWTO links to > this page on the old wiki: > http://www.mingw.org/MinGWiki/index.php/MSYSBuildEnvironment. > > That page is most definitely not easy to follow. Perhaps the only useful > line is "So the first exciting thing is to install the > msysDVLPR-1.0.0-alpha-1.tar.gz file unarchiving it into the /msys > directory." This contradicts other information that I have read online, > more on that in a minute. Also, that file dates back to 2003 on > Sourceforge. > > Frustrated, I try googling for "Installing MSYS". The only official page I > can find, and the first link on Google, is this one: > http://www.mingw.org/MinGWiki/index.php/Install%20MSYS. This is also from > the old wiki. It says "Installing MSYS is as easy as executing a program. > The installation is provided by means of a Win32 installer. Currently the > installer compiler is INNO Setup version 2." I cannot find that Win32 > installer anywhere. I don't even know what it's name is. It contradicts > the previous instructions which say I have to download and extract a > tarball. > > The page also says "Choose the version of the package you want; Snapshot, > Candidate or Current;" but those links don't take me to download files, > nor to Sourceforge FRS, nor to a page which contains a link to either of > these. The only way I have found to actually download anything is via the > front page of the website, right hand side, "Recent File Releases". > > The MinGW page (http://www.mingw.org/node/19) needs reformatting for the > changed wiki syntax. Many links are broken (e.g. [history project > history]) and bad formatting makes others difficult to read (e.g. !Links > How to install MinGW How to get started with MinGW Building a Linux hosted > Windows compiler Building a Windows hosted cross-compiler When will the > next release be supported?). Still no link to sourceforge. > > Going back to the front page, I spy a link to "Updated: MinGW Automated > Installer 5.1.4". This looks promising so I click on it. Finally I get to > Sourceforget. I click "Downloads" and "Browse all files". There are a > million different subprojects in MinGW. I find this very confusing. I have > not much idea what I need to download. But I do see three projects > starting with the word MSYS, and this reminds me of the MSYS installer > comments above, so I investigate them. > > The first is "MSYS Base System: Technology Preview: MSYS-1.0.11". It is > also the most recent. However, clicking the Download link gives me another > huge raft of files, none of which I know if I need or not. I do not relish > the prospect of downloading them all one by one from sourceforge. I would > be here all day. > > MSYS-1.0.11-20071204.tar.bz2 looks the most promising, but it's a tar.bz2 > not an installer, and I don't even know if I have a bunzip2 or tar on this > system, and don't want to damage the archives by unpacking them with > winzip. Also there is a msysCORE-1.0.11-2007.01.19-1.tar.bz2. How this is > different to the previous file, I have no idea. > > The MSYS Supplementary Tools has no msys* files whatsoever. MSYS System > Builder contains the msysDVLPR-1.0.0-alpha-1.tar.gz referred to above, but > it's five years old, and again I suspect I will have problems with > unpacking the tarball with winzip. > > I have not found an easy way to install MSYS. I give up. > > I'd like to make the following requests for changes to the website: > > * Please provide the standard links in your Navigation menu > * Please provide download documentation for MSYS. > * Please link to the promised holy grail "MSYS installer" if it exists > * Please create one if it does not > * Please do not expect people like me to navigate your massive file > structure on Sourceforge to download anything; or > * Please make the structure 100x simpler if you do. e.g. two projects, > MinGW and MSYS; one file under each, which is the latest automated > installer; hide everything else. > > Thank you for listening to my rant. I'm glad to get it off my chest. I > hope that this situation can be improved and that I can help in some way > to do so. Otherwise I'm afraid that MSYS, however good it is, will remain > far out of reach for people who simply want tools that work. Now I'm going > to download cygwin. Which is absolutely trivial by comparison. It's not the solution you want, but here is a tutorial about libraries that I have ported. It begins with the installation of MSYS / MinGW: http://wiki.enlightenment.org/index.php/EFL_Windows_XP regards Vincent |
From: JonY <10...@gm...> - 2008-07-18 12:06:25
|
Chris Wilson wrote: > Hi all, > > I have been using MinGW for many years and I'm very happy that it exists > and very grateful for all your work. Thank you. > > Now I would like to try MSYS in order to port some software that currently > runs on Linux to Windows. I found the process so confusing that I have > given up. I hope that you will take the following as constructive > criticism rather than a random rant. If you prefer to take offence at my > message, please delete it now, thank you. I am happy to update the wiki(s) > once I have the necessary information and if I have permission to do so. > Hi, I sure hope you know what you're doing. MSYS is a totally different animal, you're probably better off with cygwin than MSYS for your goals. > So I knew that MSYS was a MinGW project and visited mingw.org to try to > download it. I find the mingw.org front page difficult to navigate. The > "Navigation Links" are not useful to me. I would find a set of links more > like a standard project (about us, news, downloads, support, screenshots, > etc.) much easier to use. "New MinGWiki" and "Old MinGWiki" mean nothing > to me. I don't care who's online, not what documents were "last viewed" by > some random user. > > Since I cannot find a "Download" link anywhere, I try MSYS, which takes me > to "http://www.mingw.org/node/18". Again I cannot see any link to download > anything here. "Getting Started" says nothing about MSYS. HOWTO links to > this page on the old wiki: > http://www.mingw.org/MinGWiki/index.php/MSYSBuildEnvironment. > > That page is most definitely not easy to follow. Perhaps the only useful > line is "So the first exciting thing is to install the > msysDVLPR-1.0.0-alpha-1.tar.gz file unarchiving it into the /msys > directory." This contradicts other information that I have read online, > more on that in a minute. Also, that file dates back to 2003 on > Sourceforge. Page needs updating. > > Frustrated, I try googling for "Installing MSYS". The only official page I > can find, and the first link on Google, is this one: > http://www.mingw.org/MinGWiki/index.php/Install%20MSYS. This is also from > the old wiki. It says "Installing MSYS is as easy as executing a program. > The installation is provided by means of a Win32 installer. Currently the > installer compiler is INNO Setup version 2." I cannot find that Win32 > installer anywhere. I don't even know what it's name is. It contradicts > the previous instructions which say I have to download and extract a > tarball. Previous page was about installing MSYS _build_ environment, the "installing MSYS" page talks about setting up MSYS for use _with_ MinGW. > > The page also says "Choose the version of the package you want; Snapshot, > Candidate or Current;" but those links don't take me to download files, > nor to Sourceforge FRS, nor to a page which contains a link to either of > these. The only way I have found to actually download anything is via the > front page of the website, right hand side, "Recent File Releases". > > The MinGW page (http://www.mingw.org/node/19) needs reformatting for the > changed wiki syntax. Many links are broken (e.g. [history project > history]) and bad formatting makes others difficult to read (e.g. !Links > How to install MinGW How to get started with MinGW Building a Linux hosted > Windows compiler Building a Windows hosted cross-compiler When will the > next release be supported?). Still no link to sourceforge. > > Going back to the front page, I spy a link to "Updated: MinGW Automated > Installer 5.1.4". This looks promising so I click on it. Finally I get to > Sourceforget. I click "Downloads" and "Browse all files". There are a > million different subprojects in MinGW. I find this very confusing. I have > not much idea what I need to download. But I do see three projects > starting with the word MSYS, and this reminds me of the MSYS installer > comments above, so I investigate them. > > The first is "MSYS Base System: Technology Preview: MSYS-1.0.11". It is > also the most recent. However, clicking the Download link gives me another > huge raft of files, none of which I know if I need or not. I do not relish > the prospect of downloading them all one by one from sourceforge. I would > be here all day. > > MSYS-1.0.11-20071204.tar.bz2 looks the most promising, but it's a tar.bz2 > not an installer, and I don't even know if I have a bunzip2 or tar on this > system, and don't want to damage the archives by unpacking them with > winzip. Also there is a msysCORE-1.0.11-2007.01.19-1.tar.bz2. How this is > different to the previous file, I have no idea. "MsysCORE" is the same as the MSYS installer, only its in tar.bz2 format. "MSYS" contains the updated msys support dlls. > > The MSYS Supplementary Tools has no msys* files whatsoever. MSYS System > Builder contains the msysDVLPR-1.0.0-alpha-1.tar.gz referred to above, but > it's five years old, and again I suspect I will have problems with > unpacking the tarball with winzip. That's the file you want if you want to build MSYS apps. The ancient MSYS system builder still uses gcc-2.95. > > I have not found an easy way to install MSYS. I give up. > > I'd like to make the following requests for changes to the website: > > * Please provide the standard links in your Navigation menu > * Please provide download documentation for MSYS. > * Please link to the promised holy grail "MSYS installer" if it exists > * Please create one if it does not > * Please do not expect people like me to navigate your massive file > structure on Sourceforge to download anything; or > * Please make the structure 100x simpler if you do. e.g. two projects, > MinGW and MSYS; one file under each, which is the latest automated > installer; hide everything else. > MSYS installer refers to the MSYS base package, its for use with MinGW. I think you meant MSYSdvlpr. I'd probably put up a new page about this soon. > Thank you for listening to my rant. I'm glad to get it off my chest. I > hope that this situation can be improved and that I can help in some way > to do so. Otherwise I'm afraid that MSYS, however good it is, will remain > far out of reach for people who simply want tools that work. Now I'm going > to download cygwin. Which is absolutely trivial by comparison. > You should if you want to port Linux programs easily and GPL is not an issue. MSYS is designed to support MinGW, its not a cygwin clone. > Cheers, Chris. |
From: Chris W. <ch...@qw...> - 2008-07-18 12:52:55
|
Hi JonY, On Fri, 18 Jul 2008, JonY wrote: > > Now I would like to try MSYS in order to port some software that currently > > runs on Linux to Windows. > > I sure hope you know what you're doing. MSYS is a totally different > animal, you're probably better off with cygwin than MSYS for your goals. I think I do know what I'm doing with porting, I've ported applications to MinGW before and develop under both Unix and Windows. I'm completely new to MSYS however. > > Frustrated, I try googling for "Installing MSYS". The only official page I > > can find, and the first link on Google, is this one: > > http://www.mingw.org/MinGWiki/index.php/Install%20MSYS. This is also from > > the old wiki. It says "Installing MSYS is as easy as executing a program. > > The installation is provided by means of a Win32 installer. Currently the > > installer compiler is INNO Setup version 2." I cannot find that Win32 > > installer anywhere. I don't even know what it's name is. It contradicts > > the previous instructions which say I have to download and extract a > > tarball. > > Previous page was about installing MSYS _build_ environment, the > "installing MSYS" page talks about setting up MSYS for use _with_ MinGW. Perhaps it does, but it's not helpful in actually getting MSYS installed in the first place. The distinction was also not made clear anywhere. I think I've made it clearer now on the MSYS page on the website. > "MsysCORE" is the same as the MSYS installer, only its in tar.bz2 > format. "MSYS" contains the updated msys support dlls. Is that documented anywhere at all? It's certainly not obvious from the file names or the FRS structure. Also I'm not sure what's the use of having an installer in tar.bz2 format which most users can't extract. > > The MSYS Supplementary Tools has no msys* files whatsoever. MSYS > > System Builder contains the msysDVLPR-1.0.0-alpha-1.tar.gz referred to > > above, but it's five years old, and again I suspect I will have > > problems with unpacking the tarball with winzip. > > That's the file you want if you want to build MSYS apps. The ancient > MSYS system builder still uses gcc-2.95. OK, thanks, I guess I may need that to install more recent autotools, etc. > MSYS installer refers to the MSYS base package, its for use with MinGW. > I think you meant MSYSdvlpr. I'd probably put up a new page about this > soon. I think I wasn't actually looking for MSYSdvlpr, I just wanted to compile native programs using their configure script and makefiles, but since the configure script will need changing and msys doesn't appear to come with autoconf.exe I guess I will have to build it if I want to use MSYS. > > Now I'm going to download cygwin. Which is absolutely trivial by > > comparison. > > You should if you want to port Linux programs easily and GPL is not an > issue. MSYS is designed to support MinGW, its not a cygwin clone. Cygwin sucks in a number of ways, fork and compile performance is awful. But since it has pthreads and some Unix headers, I guess it may be easier for me in the short term. In any case I was more referring to the difficulty of installing the environment than the difficulty of using it to port software. Cheers, Chris. -- _____ __ _ \ __/ / ,__(_)_ | Chris Wilson <0000 at qwirx.com> - Cambs UK | / (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Ruby/Perl/SQL Developer | \ _/_/_/_//_/___/ | We are GNU : free your mind & your software | |
From: Chris W. <ch...@qw...> - 2008-07-18 12:10:53
|
Hi Vincent, On Fri, 18 Jul 2008, Vincent Torri wrote: > It's not the solution you want, but here is a tutorial about libraries > that I have ported. It begins with the installation of MSYS / MinGW: > > http://wiki.enlightenment.org/index.php/EFL_Windows_XP Thanks, that made it very easy. I've copied the relevant parts (I hope) into the MSYS page on the MinGW site (http://www.mingw.org/node/18). Cheers, Chris. -- _____ __ _ \ __/ / ,__(_)_ | Chris Wilson <0000 at qwirx.com> - Cambs UK | / (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Ruby/Perl/SQL Developer | \ _/_/_/_//_/___/ | We are GNU : free your mind & your software | |
From: JonY <10...@gm...> - 2008-07-18 13:03:45
|
Chris Wilson wrote: > Hi Vincent, > > On Fri, 18 Jul 2008, Vincent Torri wrote: > >> It's not the solution you want, but here is a tutorial about libraries >> that I have ported. It begins with the installation of MSYS / MinGW: >> >> http://wiki.enlightenment.org/index.php/EFL_Windows_XP > > Thanks, that made it very easy. I've copied the relevant parts (I hope) > into the MSYS page on the MinGW site (http://www.mingw.org/node/18). > > Cheers, Chris. Hi, I find the information posted from the EFL page needs to be changed, but I would like to avoid an edit war, hence this discussion. 1. Install path Should follow installer defaults like "C:\MinGW" and "C:\MSYS\1.0", probably not a big issue. 2. MinGW installer link Should use a generic link to "Automated MinGW Installer" at: "http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=240780&release_id=595197" 3. "...MUST NOT install them in /usr, nor in /mingw. Install them in /usr/local" Probably should install to /mingw, so 3rd party tools and IDEs like Dev-cpp will pick them up automatically. Furthermore mingw libs installed to "/usr/local" will cause conflict with msysdvlpr, should the user choose to install it on a later date, the reason being msysdvlpr gcc is hard coded to search it. IMHO gcc specs file modifications should be avoided. |
From: Vincent T. <vt...@un...> - 2008-07-18 13:13:20
|
> I find the information posted from the EFL page needs to be changed, but > I would like to avoid an edit war, hence this discussion. feel free to update what you want in the mingw wiki. I won't maintain it. I only maintain my tutorial. I have done some choices in my tutorial because of personal experience with msys / mingw. In addition, it has been written for a specific purpose : the compilation of the libraries i have ported. It is in no way a perfect generic installation tutorial for msys / mingw. Vincent Torri > 1. Install path > Should follow installer defaults like "C:\MinGW" and "C:\MSYS\1.0", > probably not a big issue. > > 2. MinGW installer link > Should use a generic link to "Automated MinGW Installer" at: > > "http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=240780&release_id=595197" > > 3. "...MUST NOT install them in /usr, nor in /mingw. Install them in > /usr/local" > > Probably should install to /mingw, so 3rd party tools and IDEs like > Dev-cpp will pick them up automatically. > > Furthermore mingw libs installed to "/usr/local" will cause conflict > with msysdvlpr, should the user choose to install it on a later date, > the reason being msysdvlpr gcc is hard coded to search it. IMHO gcc > specs file modifications should be avoided. > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > > -- > Ce message a été vérifié par MailScanner > pour des virus ou des polluriels et rien de > suspect n'a été trouvé. > Message délivré par le serveur de messagerie de l'Université d'Evry. > > |
From: Chris W. <ch...@qw...> - 2008-07-18 13:37:50
|
Hi Jony, On Fri, 18 Jul 2008, JonY wrote: > I find the information posted from the EFL page needs to be changed, but > I would like to avoid an edit war, hence this discussion. Please, go ahead and change whatever you like, I didn't write the text and I'm not particularly attached to it. I just want MSYS to have good documentation that is ultra easy to follow, and the more improvements are made, by anyone, the better for everyone. Cheers, Chris. -- _____ __ _ \ __/ / ,__(_)_ | Chris Wilson <0000 at qwirx.com> - Cambs UK | / (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Ruby/Perl/SQL Developer | \ _/_/_/_//_/___/ | We are GNU : free your mind & your software | |
From: Keith M. <kei...@us...> - 2008-07-19 22:26:22
|
On Friday 18 July 2008 13:58:32 JonY wrote: > 2. MinGW installer link > Should use a generic link to "Automated MinGW Installer" at: > > "http://sourceforge.net/project/showfiles.php?group_id=2435&package_i >d=240780&release_id=595197" I agree that this should use a generic link, but this doesn't fit the bill, for it is by no means generic. It is in fact a specific link to just one version of the installer, and will immediately become obsolete as soon as the next version is released. It is this sort of built-in obsolescence that has led to the current situation, where most of the information on mingw.org, (the original site, which Earnie recently moved out of the way, to mingw.org/old), has become stale. A more suitable link, for this particular package is simply: https://sourceforge.net/project/showfiles.php?group_id=2435&package_id=240780 (i.e. omitting the release qualifier); with that change, the link will continue to lead to the appropriate location, whenever a new version of the package is released. Regards, Keith. |
From: JonY <10...@gm...> - 2008-07-20 00:46:05
|
Keith Marshall wrote: > On Friday 18 July 2008 13:58:32 JonY wrote: >> 2. MinGW installer link >> Should use a generic link to "Automated MinGW Installer" at: >> >> "http://sourceforge.net/project/showfiles.php?group_id=2435&package_i >> d=240780&release_id=595197" > > I agree that this should use a generic link, but this doesn't fit the > bill, for it is by no means generic. It is in fact a specific link to > just one version of the installer, and will immediately become obsolete > as soon as the next version is released. It is this sort of built-in > obsolescence that has led to the current situation, where most of the > information on mingw.org, (the original site, which Earnie recently > moved out of the way, to mingw.org/old), has become stale. > > A more suitable link, for this particular package is simply: > https://sourceforge.net/project/showfiles.php?group_id=2435&package_id=240780 > > (i.e. omitting the release qualifier); with that change, the link will > continue to lead to the appropriate location, whenever a new version of > the package is released. > > Regards, > Keith. > Ok, thanks for fixing it. |
From: Keith M. <kei...@nt...> - 2008-07-19 23:47:16
|
On Friday 18 July 2008 12:25:26 Chris Wilson wrote: > I have not found an easy way to install MSYS. I give up. I've snipped most of your rant, Chris. I'm sorry you have found your experience frustrating, but in our defence, I would like to point out that the MinGW.org website is currently undergoing a major overhaul, in the hope of making it more maintainable, and more usable. Currently, this is at a very early stage in the migration process, and most, maybe even all, of the work is being performed by one individual, Earnie; I'm sure he would appreciate some willing volunteers to assist him. Now, to return to your complaint; you could not find the MSYS installer on the Sourceforge download page. Well, I'd have to say that you didn't look very hard, because it is right there, in the MSYS Base System: Current Release, (just below the Technology Preview package you did look at). As an aside, I'd have to ask why, if you want to use bleeding edge technology previews, that you don't expect to maybe have to work that little bit harder, to make them work? > I'd like to make the following requests for changes to the website: > > * Please provide the standard links in your Navigation menu I'm sure Earnie plans to provide these. If you can't wait, then please offer your assistance, to make it happen quicker. > * Please provide download documentation for MSYS. AFAIK, that is already provided in MinGWiki; at present, the old version remains the more usable resource, (`Getting Started' might be a good entry point), although some of the information it provides has become stale, and during the site migration, some of its links may be broken. > * Please link to the promised holy grail "MSYS installer" if it > exists It does... https://sourceforge.net/project/showfiles.php?group_id=2435&package_id=24963 https://sourceforge.net/project/showfiles.php?group_id=2435&package_id=24963&release_id=89960 http://downloads.sourceforge.net/mingw/MSYS-1.0.10.exe?use_mirror=auto > * Please create one if it does not MSYS-1.0.11 is the latest Technology Preview version; it has not yet been finalised to the point where an integrated installer can be prepared; if you want one, use the `Current Release', which is MSYS-1.0.10. If you want more recent components, you can start with MSYS-1.0.10, then use its tar and bunzip2 tools to incrementally update, using the individual files from the MSYS-1.0.11 collection. > * Please do not expect people like me to navigate your massive file > structure on Sourceforge to download anything; If you don't like it, please complain to SourceForge site administration rather than to us; we already have, but our pleas for an improved structure have fallen on deaf ears. > or > * Please make the structure 100x simpler if you do. e.g. two > projects, MinGW and MSYS; But there is already only *one* project: MinGW. You seem to be confused by the distinction between packages and projects. > one file under each, which is the latest > automated installer; hide everything else. If I do that, will *you* personally field and reply to every single complaint of the `where is package foo? I can't find it' variety? At one time, we tried to group various different logical packages into just a few super-packages, to group by development status. That worked reasonably well at one time; then SourceForge changed the presentation style for the downloads page, (we don't control that, they do). The new style didn't suit our packaging strategy. No one could find anything, because 99% of everything was hidden away, behind `View previous releases of package foo' links, which no one thought to follow. The current arrangement is the best we found practicable, given the constraints of the current SF style. > Thank you for listening to my rant. I'm glad to get it off my chest. > I hope that this situation can be improved and that I can help in > some way to do so. Constructive criticism is always welcome, especially when accompanied by such offers to assist with improvements. Since Earnie is the taking the lead in the website reorganisation, I'll leave it to him to suggest how you may best help with that. Regards, Keith. |
From: Vincent T. <vt...@un...> - 2008-07-20 06:37:59
|
On Sun, 20 Jul 2008, Keith Marshall wrote: > Now, to return to your complaint; you could not find the MSYS installer > on the Sourceforge download page. Btw, I think that if there is a link that must appear in the mingw web site, it's "Download". Indeed, for MinGW, I have to go to "New MinGWiki", then "FAQ", then "... MinGW?" (the first link) and then I can see at the bottom the link to sourceforge download page. Maybe there should be a link in "New MinGWiki", very simple, with almost no text saying : if you want to download MinGW, go to that page (with the link of "... MinGW?") and same for MSYS. Two notes: * In "Getting Started", it seems that the link to the automated installer is not good. * In the MSYS page (New MinGWiki -> FAQ -> ... MSYS), it is said that one should install the programs (here, the autotools) in the MinGW directory. But, I was said to not to do so (maybe it was you, Keith). Is it the case, or is it safe to install programs in /mingw ? > MSYS-1.0.11 is the latest Technology Preview version; it has not yet > been finalised to the point where an integrated installer can be > prepared; Btw, is there a release plan, or a web page that says what should be done for a 1.0.11 release ? (maybe it's in a mail ?) >> * Please make the structure 100x simpler if you do. e.g. two >> projects, MinGW and MSYS; > > But there is already only *one* project: MinGW. You seem to be confused > by the distinction between packages and projects. I agree, here. The download page is huge and one may be lost when looking at it. Also, there is something that always annoyed me: the fact that we find the same "package"at different place there. For example, autoconf can be found in "MSYS Supplementary Tools", "MSYS System Builder", "User Contributed: mingwPORT", with different versions each time. A newbie user who sees that will certainly not know what to download. One remark: In the sourceforge download page, there is a small icon that shows the release notes when clicking on it. Although it works for the "Latest File Releases", it does not always work for the "File Releases". Is it a problem of Sourceforge ? Vincent Torri |
From: JonY <10...@gm...> - 2008-07-20 08:11:33
|
Vincent Torri wrote: > > On Sun, 20 Jul 2008, Keith Marshall wrote: > >> Now, to return to your complaint; you could not find the MSYS installer >> on the Sourceforge download page. > > Btw, I think that if there is a link that must appear in the mingw web > site, it's "Download". Indeed, for MinGW, I have to go to "New MinGWiki", > then "FAQ", then "... MinGW?" (the first link) and then I can see at the > bottom the link to sourceforge download page. Maybe there should be a link > in "New MinGWiki", very simple, with almost no text saying : if you want > to download MinGW, go to that page (with the link of "... MinGW?") and > same for MSYS. > > Two notes: > > * In "Getting Started", it seems that the link to the automated installer > is not good. > > * In the MSYS page (New MinGWiki -> FAQ -> ... MSYS), it is said that one > should install the programs (here, the autotools) in the MinGW directory. > But, I was said to not to do so (maybe it was you, Keith). Is it the case, > or is it safe to install programs in /mingw ? I suggested so because MinGW gcc (including some 3rd party devel-tools for use with MinGW) will automatically search /mingw for headers and libs. The problem arises when for some reason users _do_ install msysdvlpr. MSYS gcc is coded to search /usr and /usr/local for libs and headers. This would sure make a mess of things when porting some MSYS aware tools. Moving libs and headers around will cause problems for libraries which rely on pkg-config or libtool. IMHO, tools and libraries for MinGW residing under /mingw should not be visible when under msysdvlpr mode. An example would be autotools, where MSYS aware versions exists and should only be used when developing for MSYS tools, but should not be available when MSYSTEM=MINGW32. Do correct me if I'm wrong. > >> MSYS-1.0.11 is the latest Technology Preview version; it has not yet >> been finalised to the point where an integrated installer can be >> prepared; > > Btw, is there a release plan, or a web page that says what should be done > for a 1.0.11 release ? (maybe it's in a mail ?) > No idea about that but IMO it is stable enough for normal use. >>> * Please make the structure 100x simpler if you do. e.g. two >>> projects, MinGW and MSYS; >> But there is already only *one* project: MinGW. You seem to be confused >> by the distinction between packages and projects. > > I agree, here. The download page is huge and one may be lost when looking > at it. Also, there is something that always annoyed me: the fact that we > find the same "package"at different place there. For example, autoconf can > be found in "MSYS Supplementary Tools", "MSYS System Builder", "User > Contributed: mingwPORT", with different versions each time. A newbie user > who sees that will certainly not know what to download. > I agree that it should be clearer, maybe "MSYS System Builder" should be changed to "MSYS development". > One remark: In the sourceforge download page, there is a small icon that > shows the release notes when clicking on it. Although it works for the > "Latest File Releases", it does not always work for the "File Releases". > Is it a problem of Sourceforge ? > > Vincent Torri > |
From: Keith M. <kei...@nt...> - 2008-07-20 11:48:34
|
On Sunday 20 July 2008 09:06:19 JonY wrote: > > * In "Getting Started", it seems that the link to the automated > > installer is not good. Indeed, I too have noticed that several links have become broken, during the reorganisation phase of the website; hopefully these will be fixed, as work progresses. > > * In the MSYS page (New MinGWiki -> FAQ -> ... MSYS), it is said > > that one should install the programs (here, the autotools) in the > > MinGW directory. But, I was said to not to do so (maybe it was you, > > Keith). I can't remember the specific discussion. My own personal preference is to keep /mingw/bin exclusively for those binaries which comprise the compiler suite, and to put user added binaries in /usr/local/bin. > > Is it the case, or is it safe to install programs in /mingw ? If you prefer it otherwise, it is perfectly acceptable to put your own native binaries in /mingw/bin. A possible cause of confusion may be those binaries which are delivered as MSYS components, (i.e. are linked with msys-1.0.dll). These should go in /bin, (for which /usr/bin is an alias in MSYS); with MSYS-1.0.10 and earlier, no other binaries should ever be put in either of these two mutually aliased directories. > I suggested so because MinGW gcc (including some 3rd party > devel-tools for use with MinGW) will automatically search /mingw for > headers and libs. Libraries and headers are a different issue from binaries; if you want the compiler to find them, without you having to explicitly tell it where to find them every time, then you *must* install them in one of the default paths, which the compiler will search. In the case of MinGW, that means they should go in /mingw/lib and /mingw/include, respectively. > The problem arises when for some reason users _do_ install msysdvlpr. > MSYS gcc is coded to search /usr and /usr/local for libs and headers. > This would sure make a mess of things when porting some MSYS aware > tools. > > Moving libs and headers around will cause problems for libraries > which rely on pkg-config or libtool. > > IMHO, tools and libraries for MinGW residing under /mingw should not > be visible when under msysdvlpr mode. An example would be autotools, > where MSYS aware versions exists and should only be used when > developing for MSYS tools, but should not be available when > MSYSTEM=MINGW32. I don't feel qualified to comment on this. My own development work is hosted *exclusively* on GNU/Linux, using a mingw32 cross-compiler. I do not develop MSYS applications, primarily because I have not been able to set up a similar cross-hosted development environment to support it. I will make one comment, however. If the compiler environment is properly set up, the default include and library search paths should be unique to individual compiler tool chains, and many different compiler configurations should be able to peacefully co-exist in a single shell environment; this is how mingw32-gcc and native gcc co-exist on my Linux box. While there is nothing intrinsically wrong with the way Earnie has set up the msysDVLPR environment, it would not have been my choice; a properly configured cross-compiler invoked by ./configure build-mingw32 host=msys ... would have been infinitely preferable, IMO. Regards, Keith. |
From: JonY <10...@gm...> - 2008-07-20 13:22:38
|
Keith Marshall wrote: >> I suggested so because MinGW gcc (including some 3rd party >> devel-tools for use with MinGW) will automatically search /mingw for >> headers and libs. > > Libraries and headers are a different issue from binaries; if you want > the compiler to find them, without you having to explicitly tell it > where to find them every time, then you *must* install them in one of > the default paths, which the compiler will search. In the case of > MinGW, that means they should go in /mingw/lib and /mingw/include, > respectively. > Correct, the most convenient way to install libraries from autotools based packages would be to use "--prefix=/mingw" while running configure, their binaries just happen to end up in "/mingw/bin". >> The problem arises when for some reason users _do_ install msysdvlpr. >> MSYS gcc is coded to search /usr and /usr/local for libs and headers. >> This would sure make a mess of things when porting some MSYS aware >> tools. >> >> Moving libs and headers around will cause problems for libraries >> which rely on pkg-config or libtool. >> >> IMHO, tools and libraries for MinGW residing under /mingw should not >> be visible when under msysdvlpr mode. An example would be autotools, >> where MSYS aware versions exists and should only be used when >> developing for MSYS tools, but should not be available when >> MSYSTEM=MINGW32. > > I don't feel qualified to comment on this. My own development work is > hosted *exclusively* on GNU/Linux, using a mingw32 cross-compiler. I > do not develop MSYS applications, primarily because I have not been > able to set up a similar cross-hosted development environment to > support it. > > I will make one comment, however. If the compiler environment is > properly set up, the default include and library search paths should be > unique to individual compiler tool chains, and many different compiler > configurations should be able to peacefully co-exist in a single shell > environment; this is how mingw32-gcc and native gcc co-exist on my > Linux box. While there is nothing intrinsically wrong with the way > Earnie has set up the msysDVLPR environment, it would not have been my > choice; a properly configured cross-compiler invoked by > > ./configure build-mingw32 host=msys ... > > would have been infinitely preferable, IMO. > Apparently lots of things are more sane under Linux. Earnie probably did this to prevent MSYS from turning into another Cygwin, nothing worng with his stance IMO. It is only unfortunate that MSYS gcc searches "/usr" and "/usr/local" for libs and headers, where MinGW compiled libraries will probably be installed. My intention to encourage installing to "/mingw" was to prevent users who have both MinGW gcc and msysdvlpr installed (or will install it sometime in the future) from accidentally clobber/mix libraries and headers intended for different compilers. The first noticable symptoms are usually random segfaults and linking problems. > Regards, > Keith. > |
From: Charles W. <cwi...@us...> - 2008-07-20 14:09:00
|
Keith Marshall wrote: > I can't remember the specific discussion. My own personal preference is > to keep /mingw/bin exclusively for those binaries which comprise the > compiler suite, and to put user added binaries in /usr/local/bin. For those developers who intend to build *MSYS* components (e.g. creating tools which rely on the MSYS DLL), putting MinGW (that is, non-MSYS-dependent) libraries into /usr/local/{lib|include} is problematic, because the *MSYS* compiler automatically includes /usr/local/* in its search path. I wonder if a better 'default' for non-compiler-related native progs/libs/headers is /mingw/local/ rather than /usr/local. >> The problem arises when for some reason users _do_ install msysdvlpr. >> MSYS gcc is coded to search /usr and /usr/local for libs and headers. >> This would sure make a mess of things when porting some MSYS aware >> tools. Yeah, what he said. >> IMHO, tools and libraries for MinGW residing under /mingw should not >> be visible when under msysdvlpr mode. An example would be autotools, >> where MSYS aware versions exists and should only be used when >> developing for MSYS tools, but should not be available when >> MSYSTEM=MINGW32. This is not entirely true. There are actually *two* versions of the autotools provided in the 1.0.11 areas. One set is currently installed into /usr/bin. These are for use when building MSYS stuff -- they have been hacked so that config.guess recognizes MSYS, etc. There is another set of autotools that (currently) install into /usr/local. These are /intended/ for use when building mingw stuff (although, naturally, they only work if you are running the tools under an MSYS bash -- the bare cmd.exe only groks bat files, not the perl and bash scripts that comprise the autotools). However, your point about the MSYS versions being invisible when MSYSTEM=MINGW32 is well-taken. Perhaps there should be, by default, the following heirarchy: /usr/{bin|lib|include| MSYS stuff that is necessary regardless of MSYSTEM value This would include most of the actual binaries that currently comprise the base MSYS distro: msys.dll, coreutils, etc. /usr/msys/{bin|lib|include} Stuff for which there may be conflicting "native" versions This would include almost all existing "MSYS" libraries, headers, and DLLs except the MSYS dll itself. After all, if you have libz.dll.a for MSYS, you might also have a separate libz.dll.a for native mingw. /usr/local/ Just don't use this. /mingw/{bin|include|lib} Just the compiler stuff, as Keith mentioned /mingw/local/{bin|include|lib| This is where, by default, non-compiler-related but native win32 versions of libraries, headers, and tools should go. Now, this means that users would typically have to specify explicitly -L/mingw/local/lib and -I/mingw/local/include (when using the mingw compiler from within msys), or -LC:/native/path/to/mingw/local/lib and -IC:/native/path/to/mingw/local/include when using the mingw compiler without msys. I'm thinking this would be where, for instance, mingwPORTs of (e.g.) zlib etc would end up. Ditto the "official" versions of the autotools (including libiconv and gettext) for native mingw use, which I have provided and which currently go into /usr/local. For this last proposal, the end user can, of course, always choose instead: > Libraries and headers are a different issue from binaries; if you want > the compiler to find them, without you having to explicitly tell it > where to find them every time, then you *must* install them in one of > the default paths, which the compiler will search. In the case of > MinGW, that means they should go in /mingw/lib and /mingw/include, > respectively. except for pre-compiled stuff like the autotools (and gettext/libiconv) as mentioned above. <ASIDE> maybe, we could 'enhance' the mingw compiler to include in its seach path the "deduced" mingw/local. Currently, mingw deduces /mingw/include and /mingw/lib via a relative path from its own data dire (/mingw/lib/gcc/<VER>/ + ../../../include, or + ../../../lib) Maybe it could also use + ../../../local/include and + ../../../local/lib? </ASIDE> [snip Keith's discussion of the msys compiler as a "cross" compiler] It would be nice, eventually, if anybody has sufficient roundtuits, if the msysDVLPR gcc were (a) updated beyond 2.95.3 (b) and turned into a "cross" compiler as Keith mentions. However, this is really strange: (1) the "native" mingw compiler, even when run from inside MSYS, is treated as a regular hosted compiler (that is, non-cross). (2) the "MSYS" compiler, when run from inside MSYS, which would ordinarily be considered a regular hosted compiler, would be treated as and called a "cross" compiler. Odd. -- Chuck |
From: JonY <10...@gm...> - 2008-07-20 16:30:13
|
Charles Wilson wrote: > Keith Marshall wrote: >> I can't remember the specific discussion. My own personal preference is >> to keep /mingw/bin exclusively for those binaries which comprise the >> compiler suite, and to put user added binaries in /usr/local/bin. > > For those developers who intend to build *MSYS* components (e.g. > creating tools which rely on the MSYS DLL), putting MinGW (that is, > non-MSYS-dependent) libraries into /usr/local/{lib|include} is > problematic, because the *MSYS* compiler automatically includes > /usr/local/* in its search path. > > I wonder if a better 'default' for non-compiler-related native > progs/libs/headers is /mingw/local/ rather than /usr/local. > >>> The problem arises when for some reason users _do_ install msysdvlpr. >>> MSYS gcc is coded to search /usr and /usr/local for libs and headers. >>> This would sure make a mess of things when porting some MSYS aware >>> tools. > > Yeah, what he said. >>> IMHO, tools and libraries for MinGW residing under /mingw should not >>> be visible when under msysdvlpr mode. An example would be autotools, >>> where MSYS aware versions exists and should only be used when >>> developing for MSYS tools, but should not be available when >>> MSYSTEM=MINGW32. > > This is not entirely true. There are actually *two* versions of the > autotools provided in the 1.0.11 areas. One set is currently installed > into /usr/bin. These are for use when building MSYS stuff -- they have > been hacked so that config.guess recognizes MSYS, etc. > > There is another set of autotools that (currently) install into > /usr/local. These are /intended/ for use when building mingw stuff > (although, naturally, they only work if you are running the tools under > an MSYS bash -- the bare cmd.exe only groks bat files, not the perl and > bash scripts that comprise the autotools). > I should have been clearer about stating MSYS having its own custom set of autotools for itself, but you are completely right. > However, your point about the MSYS versions being invisible when > MSYSTEM=MINGW32 is well-taken. Perhaps there should be, by default, the > following heirarchy: > > /usr/{bin|lib|include| > MSYS stuff that is necessary regardless of MSYSTEM value > This would include most of the actual binaries that currently > comprise the base MSYS distro: msys.dll, coreutils, etc. > > /usr/msys/{bin|lib|include} > Stuff for which there may be conflicting "native" versions > This would include almost all existing "MSYS" libraries, headers, > and DLLs except the MSYS dll itself. After all, if you have > libz.dll.a for MSYS, you might also have a separate libz.dll.a > for native mingw. > This is what I personally did, MSYS gcc and tools living in another subdirectory. Currently requires specs file hack to pick up headers and libs, MSYS g++ not picking up libstdc++ headers. Maybe I'm too paranoid about tool chain contamination. > /usr/local/ > Just don't use this. > I place 3rd party MSYS ported tools such as svn for MSYS here, libs and headers moved by hand to "/usr/msys", tedious when dealing with libtool and pkg-config files. > /mingw/{bin|include|lib} > Just the compiler stuff, as Keith mentioned > > /mingw/local/{bin|include|lib| > This is where, by default, non-compiler-related but native win32 > versions of libraries, headers, and tools should go. Now, this > means that users would typically have to specify explicitly > -L/mingw/local/lib and -I/mingw/local/include (when using the > mingw compiler from within msys), or > -LC:/native/path/to/mingw/local/lib and > -IC:/native/path/to/mingw/local/include when using the mingw > compiler without msys. > > I'm thinking this would be where, for instance, mingwPORTs of > (e.g.) zlib etc would end up. Ditto the "official" versions of > the autotools (including libiconv and gettext) for native mingw > use, which I have provided and which currently go into /usr/local. > I don't know how others see it, but I never liked requiring users manually to specify CFLAGS for things to work. > > For this last proposal, the end user can, of course, always choose instead: > > > Libraries and headers are a different issue from binaries; if you want > > the compiler to find them, without you having to explicitly tell it > > where to find them every time, then you *must* install them in one of > > the default paths, which the compiler will search. In the case of > > MinGW, that means they should go in /mingw/lib and /mingw/include, > > respectively. > > except for pre-compiled stuff like the autotools (and gettext/libiconv) > as mentioned above. > > <ASIDE> maybe, we could 'enhance' the mingw compiler to include in its > seach path the "deduced" mingw/local. Currently, mingw deduces > /mingw/include and /mingw/lib via a relative path from its own data dire > (/mingw/lib/gcc/<VER>/ + ../../../include, or + ../../../lib) > > Maybe it could also use + ../../../local/include and + ../../../local/lib? > </ASIDE> > I always thought that lib and include paths were decided when gcc was compiled, unless it involves changing the specs file. For some reason the same hack only works for gcc (C frontend) but not for g++ and friends on my system. > [snip Keith's discussion of the msys compiler as a "cross" compiler] > > It would be nice, eventually, if anybody has sufficient roundtuits, if > the msysDVLPR gcc were (a) updated beyond 2.95.3 (b) and turned into a > "cross" compiler as Keith mentions. However, this is really strange: > > (1) the "native" mingw compiler, even when run from inside MSYS, is > treated as a regular hosted compiler (that is, non-cross). > > (2) the "MSYS" compiler, when run from inside MSYS, which would > ordinarily be considered a regular hosted compiler, would be treated as > and called a "cross" compiler. Odd. > Because the "native" gcc churns out native executables for Win32 and MSYSTEM=MINGW32 is the default? :) I would sure like the msysDVLPR gcc and binutils to be updated and set up as a cross-compiler too, but it looks to be a huge undertaking for a side project. Anyone have any pointers where to start? |
From: Keith M. <kei...@nt...> - 2008-07-20 20:29:40
|
On Sunday 20 July 2008 15:08:47 Charles Wilson wrote: > Keith Marshall wrote: > > I can't remember the specific discussion. My own personal > > preference is to keep /mingw/bin exclusively for those binaries > > which comprise the compiler suite, and to put user added binaries > > in /usr/local/bin. > > For those developers who intend to build *MSYS* components (e.g. > creating tools which rely on the MSYS DLL), putting MinGW (that is, > non-MSYS-dependent) libraries into /usr/local/{lib|include} is > problematic, because the *MSYS* compiler automatically includes > /usr/local/* in its search path. But I didn't suggest putting either headers or libraries, for use with MinGW, into /usr/local/{include,lib}; the MinGW compiler does not look for them there. I did suggest that such headers and libraries would best be put directly into /mingw/{include,lib}, which is where the compiler *will* look for them. > I wonder if a better 'default' for non-compiler-related native > progs/libs/headers is /mingw/local/ rather than /usr/local. Maybe. Here's how header searches work on my GNU/Linux hosted setup:-- $ gcc -v -c -xc /dev/null Using built-in specs. Target: i486-linux-gnu Configured with:... [...snip...] gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7) [...snip...] #include "..." search starts here: #include <...> search starts here: /usr/local/include /usr/lib/gcc/i486-linux-gnu/4.2.3/include /usr/include End of search list. [...snip...] $ mingw32-gcc -v -c -xc /dev/null Reading specs from /home/keith/mingw32/lib/gcc/mingw32/3.4.5/specs Configured with:... [...snip...] gcc version 3.4.5 (mingw-vista special r2) [...snip...] #include "..." search starts here: #include <...> search starts here: /home/keith/mingw32/usr/local/include /home/keith/mingw32/lib/gcc/mingw32/3.4.5/include End of search list. [...snip...] Note how the native compiler uses the conventional search paths, while the mingw32 cross uses paths localised to its own installation prefix. (Similar segregation is apparent for program and library searches, as indicated by `{mingw32-,}gcc -print-search-dirs'). The point is that the paths are appropriately segregated, as determined when the compiler itself is configured, so whatever we choose to support must be defined at that point in the tool chain build. > >> The problem arises when for some reason users _do_ install > >> msysdvlpr. MSYS gcc is coded to search /usr and /usr/local for > >> libs and headers. This would sure make a mess of things when > >> porting some MSYS aware tools. > > Yeah, what he said. > > >> IMHO, tools and libraries for MinGW residing under /mingw should > >> not be visible when under msysdvlpr mode. An example would be > >> autotools, where MSYS aware versions exists and should only be > >> used when developing for MSYS tools, but should not be available > >> when MSYSTEM=MINGW32. > > This is not entirely true. There are actually *two* versions of the > autotools provided in the 1.0.11 areas. I've never completely understood why this is necessary. Certainly in the case of autoconf, one native installation suffices for my cross hosted build environment, and I suspect that the same would be true of automake, (which I personally dislike, and do not use); perhaps libtool would require distinct tool chain specific installations, but I do not have the experience to make that judgement. > One set is currently > installed into /usr/bin. These are for use when building MSYS stuff > -- they have been hacked so that config.guess recognizes MSYS, etc. But config.guess is a component of the package being built, *not* of the autotools used to generate the package scripts. Customisation of config.guess, (and config.sub), is required individually, for each package being built as an MSYS component; (maybe that is as simple as substituting MSYS aware variants for these files, in each package source tree, but that substitution isn't performed by the autotools). > [snipped completely reasonable suggestion for an install hierarchy] > For this last proposal, the end user can, of course, always choose > instead: > > Libraries and headers are a different issue from binaries; if you > > want the compiler to find them, without you having to explicitly > > tell it where to find them every time, then you *must* install > > them in one of the default paths, which the compiler will search. > > In the case of MinGW, that means they should go in /mingw/lib and > > /mingw/include, respectively. > > except for pre-compiled stuff like the autotools (and > gettext/libiconv) as mentioned above. I don't understand this; I use GNU libiconv with my mingw32 cross, compiled using the cross tool chain itself -- the headers and libraries go in $HOME/mingw32[/usr[/local]]/{include,lib}. (The m4 files, which support the autotools, can go anywhere; if I want to use aclocal, I can tell it where to look for them). The only autotools I use are the GNU/Linux host's native versions. > <ASIDE> maybe, we could 'enhance' the mingw compiler to include in > its seach path the "deduced" mingw/local. Currently, mingw deduces > /mingw/include and /mingw/lib via a relative path from its own data > dire (/mingw/lib/gcc/<VER>/ + ../../../include, or + ../../../lib) > > Maybe it could also use + ../../../local/include and + > ../../../local/lib? </ASIDE> For those who like to keep added library and header components separate from those which are supplied with the compiler itself, this would be a useful enhancement; perhaps Aaron could comment on the feasibility of implementing it. > [snip Keith's discussion of the msys compiler as a "cross" compiler] > > It would be nice, eventually, if anybody has sufficient roundtuits, > if the msysDVLPR gcc were (a) updated beyond 2.95.3 (b) and turned > into a "cross" compiler as Keith mentions. Since MSYS is not an official GCC target, (and unlikely to ever be one), there is a significant effort required to accomplish this, and then to maintain it through future version evolutions. A while ago I did try to create a GNU/Linux hosted build, using Earnie's patchset, and the same binutils and GCC versions as he used, but it refused to build; I gave up, thinking that it would be more productive to work on the basis of more recent versions, but I never found the round tuits to pursue the idea further. > However, this is really strange: > > (1) the "native" mingw compiler, even when run from inside MSYS, is > treated as a regular hosted compiler (that is, non-cross). It may appear anomalous, but this is entirely consistent with the stated objective of MSYS: to provide a POSIXy shell environment for native hosting of the MinGW compiler suite... > (2) the "MSYS" compiler, when run from inside MSYS, which would > ordinarily be considered a regular hosted compiler, would be treated > as and called a "cross" compiler. Odd. Yep, but if the MinGW compiler is to be considered native, (and for the majority of users this is the natural choice), then the MSYS target has to be viewed as the cross, in order to distinguish it. Regards, Keith. |
From: Keith M. <kei...@us...> - 2008-07-23 22:18:49
Attachments:
gcc-3.4.5-mingw32-specs.diff.gz
|
On Sunday 20 July 2008 21:29:27 Keith Marshall wrote: > > <ASIDE> maybe, we could 'enhance' the mingw compiler to include in > > its seach path the "deduced" mingw/local. Currently, mingw deduces > > /mingw/include and /mingw/lib via a relative path from its own data > > dire (/mingw/lib/gcc/<VER>/ + ../../../include, or + ../../../lib) > > > > Maybe it could also use + ../../../local/include and + > > ../../../local/lib? </ASIDE> > > For those who like to keep added library and header components > separate from those which are supplied with the compiler itself, this > would be a useful enhancement; perhaps Aaron could comment on the > feasibility of implementing it. While I am not Aaron, I'd like to develop this idea a little further. Yesterday, I indulged in a bit of specs file hacking, (for the unrelated purpose of selecting libmsvcr80.a in preference to libmsvcrt.a), and it occurred to me that addition of something like /mingw/local/... to the compilers search paths could probably be readily accomplished in like fashion. It may not be as closely bound to the compiler's installation directory as ../../../local/{include,lib}, but the attached patch shows how I've added d:/usr/local/{include,lib} for my gcc-3.4.5-mingw32 installation, on the Win2K box at work; change the `local_prefix' spec string definition to say: *local_prefix: d:/mingw/local/ (or whatever substitution for d:/mingw is appropriate for the end user's installation), and the effect is similar to having /mingw/local/... in the compiler's default search path. Regards, Keith. |
From: Earnie B. <ea...@us...> - 2008-07-24 03:04:29
|
Quoting Keith Marshall <kei...@us...>: > fashion. It may not be as closely bound to the compiler's installation > directory as ../../../local/{include,lib}, but the attached patch shows > how I've added d:/usr/local/{include,lib} for my gcc-3.4.5-mingw32 > installation, on the Win2K box at work; change the `local_prefix' spec > string definition to say: > > *local_prefix: > d:/mingw/local/ > > (or whatever substitution for d:/mingw is appropriate for the end user's > installation), and the effect is similar to having /mingw/local/... in > the compiler's default search path. > Just a FLI; make sure you have a backup copy of the specs file. The GCC spec file isn't that difficult to understand and changing can have great benefits to the users of GCC. There is also a GCC switch -specs=<file> to override the default file with one of your own. Earnie |
From: JonY <10...@gm...> - 2008-07-25 00:48:28
|
Earnie Boyd wrote: > Quoting Keith Marshall<kei...@us...>: > > >> fashion. It may not be as closely bound to the compiler's installation >> directory as ../../../local/{include,lib}, but the attached patch shows >> how I've added d:/usr/local/{include,lib} for my gcc-3.4.5-mingw32 >> installation, on the Win2K box at work; change the `local_prefix' spec >> string definition to say: >> >> *local_prefix: >> d:/mingw/local/ >> >> (or whatever substitution for d:/mingw is appropriate for the end user's >> installation), and the effect is similar to having /mingw/local/... in >> the compiler's default search path. >> > > Just a FLI; make sure you have a backup copy of the specs file. The > GCC spec file isn't that difficult to understand and changing can have > great benefits to the users of GCC. There is also a GCC switch > -specs=<file> to override the default file with one of your own. > > Earnie > A nice way to have gcc automatically pick it up is to place the modified specs file in "/mingw/lib/gcc/<platform>/<version>/specs". More documentation at: http://gcc.gnu.org/onlinedocs/gcc-4.3.0/gcc/Spec-Files.html I'm willing to put up a stub article on the MinGW wiki but where should it be placed or linked? |
From: Earnie B. <ea...@us...> - 2008-07-25 12:55:29
|
Quoting JonY <10...@gm...>: > > I'm willing to put up a stub article on the MinGW wiki but where should > it be placed or linked? > Perhaps the HOWTO section of the wiki? http://mingw.org/wiki/HOWTO Earnie |
From: JonY <10...@gm...> - 2008-07-25 14:32:36
|
Earnie Boyd wrote: > Quoting JonY<10...@gm...>: > >> I'm willing to put up a stub article on the MinGW wiki but where should >> it be placed or linked? >> > > Perhaps the HOWTO section of the wiki? http://mingw.org/wiki/HOWTO > > Earnie > Hi, The article is now up at: http://mingw.org/wiki/HOWTO_Use_the_GCC_specs_file Currently, it is very much a copy and paste job. It needs a cleaner approach to demonstrate specs file mods, suggestions welcome. |
From: Chris W. <ch...@qw...> - 2008-07-20 20:48:39
|
Hi Keith, On Sun, 20 Jul 2008, Keith Marshall wrote: > I've snipped most of your rant, Chris. I'm sorry you have found your > experience frustrating, but in our defence, I would like to point out > that the MinGW.org website is currently undergoing a major overhaul, in > the hope of making it more maintainable, and more usable. OK, but I'd like to say in my defence that this was not obvious from the site. The only clue that I saw that this is happening is the fact that there are still links to the old wiki lying around. I saw no statement advising people that a migration was in progress, or that the new site was not fully functional. > Currently, this is at a very early stage in the migration process, and > most, maybe even all, of the work is being performed by one individual, > Earnie; I'm sure he would appreciate some willing volunteers to assist > him. I would be happy to help. Earnie, please assign me a task and I will do it. > Now, to return to your complaint; you could not find the MSYS installer > on the Sourceforge download page. Well, I'd have to say that you didn't > look very hard, because it is right there, in the MSYS Base System: > Current Release, (just below the Technology Preview package you did look > at). OK, starting on the MinGW download page [http://sourceforge.net/project/showfiles.php?group_id=2435] I can see three MSYS-related packages: MSYS Base System Technology Preview: MSYS-1.0.11 MSYS Supplementary Tools Technology Preview: Tools for MSYS-1.0.11 MSYS System Builder Technology Preview: msysDVLPR-1.0.0-alpha-1 There is no stable package listed here. Clicking on "MSYS Base System", only the technology preview is listed by default, with all of its confusing packages. However, I admit that if I click on "Current Release" below, I do indeed see an executable, and far fewer confusing files in that package. I did overlook this link in my search. I feel that it's a shame that the technology preview must contain so many separate files, and not simply the three listed in the current release, and that the technology preview is the one that's open and listed by default. However, perhaps FRS provides no way to change the "default" version? > As an aside, I'd have to ask why, if you want to use bleeding edge > technology previews, that you don't expect to maybe have to work that > little bit harder, to make them work? I didn't want or intend to use a bleeding edge release, nor did I realise that the Technology Preview was such, because I couldn't see any other release to use. > > * Please provide the standard links in your Navigation menu > > I'm sure Earnie plans to provide these. If you can't wait, then please > offer your assistance, to make it happen quicker. I'd be very happy to help with this. > > * Please provide download documentation for MSYS. > > AFAIK, that is already provided in MinGWiki; at present, the old version > remains the more usable resource, (`Getting Started' might be a good > entry point), although some of the information it provides has become > stale, and during the site migration, some of its links may be broken. www.mingw.org appears to be down at the moment, so it's not easy to compare, but I could not find any information at all on the new site that related to installing MSYS. I didn't know how reliable or trustworthy the old site was, especially since the I could not find the "self contained, win32 style installation package" described on the Download page of the old website, MSYS-NNN.EXE described on the MinGWiki Getting Started page, or the "Win32 installer" described on the MinGWiki Install MSYS page. It would have helped if they actually had links to the appropriate part of FRS where those files were prominently listed, such as this one: > https://sourceforge.net/project/showfiles.php?group_id=2435&package_id=24963&release_id=89960 > > > * Please do not expect people like me to navigate your massive file > > structure on Sourceforge to download anything; > > If you don't like it, please complain to SourceForge site administration > rather than to us; we already have, but our pleas for an improved > structure have fallen on deaf ears. Many other projects manage to have easily understandable FRS structures. The MSYS Current Release is good enough for me. It's a shame that the Technology Preview is not so understandable and opens by default. > > or > > * Please make the structure 100x simpler if you do. e.g. two projects, > > MinGW and MSYS; > > But there is already only *one* project: MinGW. You seem to be confused > by the distinction between packages and projects. Sorry, I did use the wrong terminology here, but perhaps separating the Sourceforge project into two might make it easier to navigate. > > one file under each, which is the latest automated installer; hide > > everything else. > > If I do that, will *you* personally field and reply to every single > complaint of the `where is package foo? I can't find it' variety? I'm talking about the relative simplicity of the Current Release versus the relative complexity of the Technology Preview. This argument should apply equally to the Current Release. > At one time, we tried to group various different logical packages into > just a few super-packages, to group by development status. That worked > reasonably well at one time; then SourceForge changed the presentation > style for the downloads page, (we don't control that, they do). The new > style didn't suit our packaging strategy. No one could find anything, > because 99% of everything was hidden away, behind `View previous > releases of package foo' links, which no one thought to follow. The > current arrangement is the best we found practicable, given the > constraints of the current SF style. Would it be feasible to have an "MSYS installer" package (latest release: 1.0.10) and an "MSYS components" package (latest release: 1.0.11 Technology Preview)? Then I would have clicked on the "MSYS Installer" package instead, and seen the easy-to-understand view. > Constructive criticism is always welcome, especially when accompanied by > such offers to assist with improvements. Since Earnie is the taking the > lead in the website reorganisation, I'll leave it to him to suggest how > you may best help with that. Thanks for listening and for your advice. I hope to contribute in some way. Cheers, Chris. -- _____ __ _ \ __/ / ,__(_)_ | Chris Wilson <0000 at qwirx.com> - Cambs UK | / (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Ruby/Perl/SQL Developer | \ _/_/_/_//_/___/ | We are GNU : free your mind & your software | |
From: Earnie B. <ea...@us...> - 2008-07-21 17:39:19
|
Quoting Chris Wilson <ch...@qw...>: > Hi Keith, > > On Sun, 20 Jul 2008, Keith Marshall wrote: > >> I've snipped most of your rant, Chris. I'm sorry you have found your >> experience frustrating, but in our defence, I would like to point out >> that the MinGW.org website is currently undergoing a major overhaul, in >> the hope of making it more maintainable, and more usable. > > OK, but I'd like to say in my defence that this was not obvious from the > site. The only clue that I saw that this is happening is the fact that > there are still links to the old wiki lying around. I saw no statement > advising people that a migration was in progress, or that the new site was > not fully functional. > I'll probably respond to this thread in bits and pieces in multiple passes. The fact that one overlooks information isn't my problem. The website migration has been announced on this list, the first paragraph of the old site and the first sentence of the new site. Earnie |