From: Keith M. <kei...@to...> - 2005-04-25 09:45:37
|
Max T. Woodbury wrote: > 2) There is a recommendation to get GnuWin32 bison. There is a MinGW > bison package. I suspect that the MinGW version is specifically > adapted to MSys/MinGW, so why get the non-MinGW version? (Also, > there is an implication that FLex is needed. Is this true?) I once tried to build a CVS version of GNU troff, with the MinGW version of bison installed; it failed miserably :( IIRC, the MinGW version is bison-1.875. There is a note in groff's README.CVS, suggesting that bison-1.875b is required. I installed the GnuWin32 bison-1.35, and groff CVS built perfectly :) On querying the stated requirement for bison-1.875b, I was advised that it was because bison-1.875 specifically should *not* be used; it contains a critical bug, fixed in 1.875b, which made it unusable in this case. Thus, I would recommend the earlier GnuWin32 bison over the potentially buggy MinGW version, unless the MinGW version has been updated in the meantime; however, it still appears to be the buggy 1.875 version :( Don't know about Flex though; it isn't needed for groff. Regards, Keith. |
From: Michael S. Z. <ms...@mo...> - 2005-04-25 13:12:29
|
On Mon April 25 2005 04:43, Keith MARSHALL wrote: > Max T. Woodbury wrote: > > 2) There is a recommendation to get GnuWin32 bison. There is a MinGW > > bison package. I suspect that the MinGW version is specifically > > adapted to MSys/MinGW, so why get the non-MinGW version? (Also, > > there is an implication that FLex is needed. Is this true?) > > I once tried to build a CVS version of GNU troff, with the MinGW version > of bison installed; it failed miserably :( > Max, Good you do me a favor? Would you drop the stock Bash-3.0+Bash_Patches into the msys source tree, see if it builds? Bash is in the msys source tree by version numbered directory. Version 3.0 should go into the tree parallel to the 2.04 without any changes to the source of either. I.E: you would end up with a bash/2.4/..... and a bash/3.0/.... If this is successful, you should end up with a sh.exe(2.04) and a bash.exe(3.0-p16). Mike |
From: Max T. W. <max...@ve...> - 2005-04-25 21:07:04
|
"Michael S. Zick" wrote: > > On Mon April 25 2005 04:43, Keith MARSHALL wrote: > > Max T. Woodbury wrote: > > > 2) There is a recommendation to get GnuWin32 bison. There is a MinGW > > > bison package. I suspect that the MinGW version is specifically > > > adapted to MSys/MinGW, so why get the non-MinGW version? (Also, > > > there is an implication that FLex is needed. Is this true?) > > > > I once tried to build a CVS version of GNU troff, with the MinGW version > > of bison installed; it failed miserably :( > > > Max, > Good you do me a favor? > Would you drop the stock Bash-3.0+Bash_Patches into the msys > source tree, see if it builds? > > Bash is in the msys source tree by version numbered directory. > Version 3.0 should go into the tree parallel to the 2.04 without > any changes to the source of either. > I.E: you would end up with a bash/2.4/..... > and a bash/3.0/.... > > If this is successful, you should end up with a sh.exe(2.04) > and a bash.exe(3.0-p16). > It will be a little while, but that was on my 'to be done' list... [I spent the morning recovering from a power outage. Three of my servers failed to came back with the power. One hung in the BIOS (easily fixed), another hung in grub (I'd half expected that one.) and the third has been messed up for a month. The only one that came up clean was the ancient 486DX!] I need to be able to get a clean build on everything before I start making changes. The closest I've come so far is m4 - after a few hours of fiddling I got it down to the point where it only produces two warnings. It took another 90 minutes to get it to the point where it passed the regression test. (Is anybody interested in couple bug reports on this with the understanding that some of this may be 'my bad'?) ma...@mt... |
From: Michael S. Z. <ms...@mo...> - 2005-04-26 12:26:01
|
On Mon April 25 2005 16:06, Max T. Woodbury wrote: > > It will be a little while, but that was on my 'to be done' list... > Understand. > > I need to be able to get a clean build on everything before I > start making changes. > Good plan. Please keep posting your notes on this thread. I will be reading and learning from them. Thanks Mike |
From: Max T. W. <max...@ve...> - 2005-05-08 01:34:45
|
"Max T. Woodbury" wrote: > > I need to be able to get a clean build on everything before I > start making changes. The closest I've come so far is m4 - after > a few hours of fiddling I got it down to the point where it only > produces two warnings. It took another 90 minutes to get it to > the point where it passed the regression test. (Is anybody > interested in couple bug reports on this with the understanding > that some of this may be 'my bad'?) I think a progress report is probably in order. I was able to build automake and autoconf from CVS. Autoconf 'failed' one series of checks and ran into resource problems on a whole bunch but reported 'ok'. Got Mingw runtime to build OK. The definitive sources seem to be at FSF but their 'bootstrap' process blows up on me. I forget if its their build environment or the one at GnuWin32 that is so horrid... Fell back to the packages specifically designated as being for MSYS. Tackled the MSYS set. I didn't find a CVS tag set on 1.0.11 but did find one for 1.1.0. I'm trying to get the 'rt' branch of the tree to build and making a mess of it. I'm going to reread the wiki and see if there is something I missed. On the wiki - I think I understand the directory structure being used and most of the reasons for it. One substantial limitation is the size of the command line that can be passed to the compiler. Deep directory trees waste that resource. I've put a couple entries in my /etc/fstab to make things more compact. The first is the target or --prefix - I've called it /new. The other is for the directory where I've stuck the distribution - I've called it /xxx. If I ever get this working I will probably submit a new description of the build process to this list and ask if I can post it on the web site for other peoples 'edification'. Latest hangup is something in memory allocation in newlib. It looks like I'm missing a preprocessor token that describes the host system. I suspect that the shell script that I have avoided using so far includes a bunch of stuff specifically to deal with this, but I really hate not knowing what I'm doing and the script contained a lot of stuff that shouted 'legacy'. I suspect that I'll tackle it soon and add gobs of comments. Which brings up an issue -- the commentary on the code seems a bit sparse. I can figure out what's going on in most cases, but it means I've got to learn this stuff instead of just reading it. Would posting a bunch of patches that just add comments be accepted? Sorry for rambling... ma...@mt... |
From: Earnie B. <ea...@us...> - 2005-05-08 10:02:55
|
On 1:34:28 am 2005-05-08 "Max T. Woodbury" <max...@ve...> wrote: > "Max T. Woodbury" wrote: > > > > I need to be able to get a clean build on everything before I > > start making changes. The closest I've come so far is m4 - after > > a few hours of fiddling I got it down to the point where it only > > produces two warnings. It took another 90 minutes to get it to > > the point where it passed the regression test. (Is anybody > > interested in couple bug reports on this with the understanding > > that some of this may be 'my bad'?) > > I think a progress report is probably in order. > > I was able to build automake and autoconf from CVS. Autoconf 'failed' > one series of checks and ran into resource problems on a whole bunch > but reported 'ok'. Got Mingw runtime to build OK. The definitive > sources seem to be at FSF but their 'bootstrap' process blows up on > me. I forget if its their build environment or the one at GnuWin32 > that is so horrid... Fell back to the packages specifically > designated as being for MSYS. > I'm not sure exactly what your doing. > Tackled the MSYS set. I didn't find a CVS tag set on 1.0.11 but did > find one for 1.1.0. I'm trying to get the 'rt' branch of the tree to > build and making a mess of it. I'm going to reread the wiki and see > if there is something I missed. > MSYS 1.0.11 is the HEAD branch. The 1.1.0 branch is my playground for a potential future release. > On the wiki - I think I understand the directory structure being used > and most of the reasons for it. One substantial limitation is the > size of the command line that can be passed to the compiler. Deep > directory trees waste that resource. I've put a couple entries in my > /etc/fstab to make things more compact. The first is the target or > --prefix - I've called it /new. The other is for the directory where > I've stuck the distribution - I've called it /xxx. If I ever get > this working I will probably submit a new description of the build > process to this list and ask if I can post it on the web site for > other peoples 'edification'. > > Latest hangup is something in memory allocation in newlib. It looks > like I'm missing a preprocessor token that describes the host system. > I suspect that the shell script that I have avoided using so far > includes a bunch of stuff specifically to deal with this, but I > really hate not knowing what I'm doing and the script contained a lot > of stuff that shouted 'legacy'. I suspect that I'll tackle it soon > and add gobs of comments. > What script? If you mean configure, you must use it; the package will not build without executing configure. > Which brings up an issue -- the commentary on the code seems a bit > sparse. I can figure out what's going on in most cases, but it > means I've got to learn this stuff instead of just reading it. Would > posting a bunch of patches that just add comments be accepted? > Are you talking MSYS? Submit to the patch tracker and see what happens. Earnie -- MinGW - http://www.mingw.org/ Wiki - http://www.mingw.org/MinGWiki/ Bug Report - http://sourceforge.net/tracker/?group_id=2435&atid=102435 Submit Patch - http://sourceforge.net/tracker/?group_id=2435&atid=302435 SF Project - http://sourceforge.net/projects/mingw Job Listing - http://sf.net/people/viewjob.php?group_id=2435&job_id=21643 |
From: Max T. W. <max...@ve...> - 2005-05-08 22:42:51
|
Earnie Boyd wrote: > "Max T. Woodbury" wrote: > > ... > > I'm not sure exactly what your doing. Unfortunately, neither am I. I'll start over from scratch... > > Tackled the MSYS set. I didn't find a CVS tag set on 1.0.11 but did > > find one for 1.1.0. I'm trying to get the 'rt' branch of the tree to > > build and making a mess of it. I'm going to reread the wiki and see > > if there is something I missed. > > > > MSYS 1.0.11 is the HEAD branch. The 1.1.0 branch is my playground for a > potential future release. OK 1.1.0 understood. I understand that 1.0.11 'snapshot' was 'HEAD' when it was created, but the current 'HEAD' is not the same as the 1.0.11 snapshot. When you take a 'snapshot' could you record the time so it can be recreated later for testing... > What script? If you mean configure, you must use it; the package will not > build without executing configure. Not configure. I can read configure. I even know that it is largely or completely the product of autoconf even though I haven't read up on autoconf and I know I need to do that sometime soon. Someplace I saw a script that set a whole lot of environmental variables. Not bootstrap, config.status, configure or a Makefile. Anyway, I didn't know what all of it was intended to do so I didn't use it and tried to set up the build by hand. (That is set environmental variables and select options for configure and make.) > > Which brings up an issue -- the commentary on the code seems a bit > > sparse. I can figure out what's going on in most cases, but it > > means I've got to learn this stuff instead of just reading it. Would > > posting a bunch of patches that just add comments be accepted? > > > > Are you talking MSYS? Submit to the patch tracker and see what happens. Errrr. I'll take that as an "I'll think about it...". I was hoping for a "It's not something I'd do myself but if you do it, I'll consider it...". Oh, well, I'll see what I turn up... ma...@mt... |
From: Earnie B. <ea...@us...> - 2005-05-09 10:17:02
|
On 10:42:33 pm 2005-05-08 "Max T. Woodbury" <max...@ve...> wrote: > Earnie Boyd wrote: > > "Max T. Woodbury" wrote: > > > ... > > > > I'm not sure exactly what your doing. > > Unfortunately, neither am I. I'll start over from scratch... > > > > Tackled the MSYS set. I didn't find a CVS tag set on 1.0.11 but > > > did find one for 1.1.0. I'm trying to get the 'rt' branch of > > > the tree to build and making a mess of it. I'm going to reread > > > the wiki and see if there is something I missed. > > > > > > > MSYS 1.0.11 is the HEAD branch. The 1.1.0 branch is my playground > > for a potential future release. > > OK 1.1.0 understood. I understand that 1.0.11 'snapshot' was 'HEAD' > when it was created, but the current 'HEAD' is not the same as the > 1.0.11 snapshot. When you take a 'snapshot' could you record the time > so it can be recreated later for testing... > uname -a would give that. > > What script? If you mean configure, you must use it; the package > > will not build without executing configure. > > Not configure. I can read configure. I even know that it is largely > or completely the product of autoconf even though I haven't read up on > autoconf and I know I need to do that sometime soon. > > Someplace I saw a script that set a whole lot of environmental > variables. Not bootstrap, config.status, configure or a Makefile. > Anyway, I didn't know what all of it was intended to do so I didn't > use it and tried to set up the build by hand. (That is set > environmental variables and select options for configure and make.) > Did you follow http://www.mingw.org/MinGWiki/index.php/Build%20MSYS instructions? Many now have used them. > > > Which brings up an issue -- the commentary on the code seems a > > > bit sparse. I can figure out what's going on in most cases, but > > > it means I've got to learn this stuff instead of just reading > > > it. Would posting a bunch of patches that just add comments be > > > accepted? > > > > Are you talking MSYS? Submit to the patch tracker and see what > happens. > > Errrr. I'll take that as an "I'll think about it...". I was hoping > for a "It's not something I'd do myself but if you do it, I'll > consider it...". Oh, well, I'll see what I turn up... > That's what I said, just different words. I will consider any patch to MSYS as something beneficial. The cautions I must take are, does it break in general and does it work on all platforms from Win98 upward. Earnie -- MinGW - http://www.mingw.org/ Wiki - http://www.mingw.org/MinGWiki/ Bug Report - http://sourceforge.net/tracker/?group_id=2435&atid=102435 Submit Patch - http://sourceforge.net/tracker/?group_id=2435&atid=302435 SF Project - http://sourceforge.net/projects/mingw Job Listing - http://sf.net/people/viewjob.php?group_id=2435&job_id=21643 |
From: Max T. W. <max...@ve...> - 2005-05-09 18:25:11
|
Earnie Boyd wrote: > > On 10:42:33 pm 2005-05-08 "Max T. Woodbury" <max...@ve...> wrote: > > Earnie Boyd wrote: > > > "Max T. Woodbury" wrote: > > > > ... > > > > Tackled the MSYS set. I didn't find a CVS tag set on 1.0.11 but > > > > did find one for 1.1.0. I'm trying to get the 'rt' branch of > > > > the tree to build and making a mess of it. I'm going to reread > > > > the wiki and see if there is something I missed. > > > > > > > > > > MSYS 1.0.11 is the HEAD branch. The 1.1.0 branch is my playground > > > for a potential future release. > > > > OK 1.1.0 understood. I understand that 1.0.11 'snapshot' was 'HEAD' > > when it was created, but the current 'HEAD' is not the same as the > > 1.0.11 snapshot. When you take a 'snapshot' could you record the time > > so it can be recreated later for testing... > > > > uname -a would give that. Ahha! Thanks. > > > > What script? If you mean configure, you must use it; the package > > > will not build without executing configure. > > > > Not configure. I can read configure. I even know that it is largely > > or completely the product of autoconf even though I haven't read up on > > autoconf and I know I need to do that sometime soon. > > > > Someplace I saw a script that set a whole lot of environmental > > variables. Not bootstrap, config.status, configure or a Makefile. > > Anyway, I didn't know what all of it was intended to do so I didn't > > use it and tried to set up the build by hand. (That is set > > environmental variables and select options for configure and make.) > > > > Did you follow http://www.mingw.org/MinGWiki/index.php/Build%20MSYS > instructions? Many now have used them. I was trying the set labeled 'Building MSYS from scratch'. I'll give the other set a shot... > > > > Which brings up an issue -- the commentary on the code seems a > > > > bit sparse. I can figure out what's going on in most cases, but > > > > it means I've got to learn this stuff instead of just reading > > > > it. Would posting a bunch of patches that just add comments be > > > > accepted? > > > > > > Are you talking MSYS? Submit to the patch tracker and see what > > happens. > > > > Errrr. I'll take that as an "I'll think about it...". I was hoping > > for a "It's not something I'd do myself but if you do it, I'll > > consider it...". Oh, well, I'll see what I turn up... > > > > That's what I said, just different words. I will consider any patch to > MSYS as something beneficial. The cautions I must take are, does it break > in general and does it work on all platforms from Win98 upward. OK. We seem to be talking past each other... I was just going to add comments so someone coming along later could get up to speed faster, not change any code... ma...@mt... |
From: Earnie B. <ea...@us...> - 2005-05-09 20:53:53
|
On 6:24:22 pm 2005-05-09 "Max T. Woodbury" <max...@ve...> wrote: > Earnie Boyd wrote: > > OK. We seem to be talking past each other... I was just going to add > comments so someone coming along later could get up to speed faster, > not change any code... > Comments added in the source will still require a patch. If you meant comments outside of the source, sorry for the confusion. Earnie -- MinGW - http://www.mingw.org/ Wiki - http://www.mingw.org/MinGWiki/ Bug Report - http://sourceforge.net/tracker/?group_id=2435&atid=102435 Submit Patch - http://sourceforge.net/tracker/?group_id=2435&atid=302435 SF Project - http://sourceforge.net/projects/mingw Job Listing - http://sf.net/people/viewjob.php?group_id=2435&job_id=21643 |
From: Max T. W. <max...@ve...> - 2005-05-11 15:59:33
|
Earnie Boyd wrote: > > Comments added in the source will still require a patch. If you meant > comments outside of the source, sorry for the confusion. Yep, but the review and acceptance should be pretty trivial... ma...@mt... |
From: Max T. W. <max...@ve...> - 2005-05-12 05:23:04
|
Earnie Boyd wrote: > > Did you follow http://www.mingw.org/MinGWiki/index.php/Build%20MSYS > instructions? Many now have used them. I did get the .dll built using the instructions on that page. They needed a little bit of adaptation and were just a little confusing. The first problem was that MSYS is not usable after its initial installation on 98SE. There is already a bug report on this. I've added a comment and posted a request here for other people to see if they can provide more information. The second problem is that strace.exe, which the web page says should be built, isn't. It needs mingw32-g++ and mingw32-gcc. The trouble shooting section says to disable these commands. If you do that, 'make install' aborts before it is complete. I fixed that problem by having mingw32-g++ and mingw32-gcc do 'g++ $@' and 'gcc $@' respectively. I also had to comment out the declaration on strace.cc:27 to get it to work. I suspect that MinGW has to be installed and kluged to get this to work really right. Correct? The trouble shooting section of the web page is a bit confusing as I said above. It would help if the text between the problem description bullets was at the same indentation level as the bullets text. I've started exploring the other sub-trees. The documentation on the dvlpr sub-tree is chopped off at then beginning of item 5. I'll be looking at what is in there shortly but if any can provide a description before I've spent a lot of time digging I'd appreciate it. Is there any thing special to be done with the package sub-trees? Specifically, they will almost certainly need to reference the newlib stuff, the new .dll, possibly libiberty and the include files. Has this already been included in the configure files or is there something else that should be done? A find/grep search showed up a newlib-mb and newlib-hw-fp option. Are these stable? ma...@mt... |
From: Earnie B. <ea...@us...> - 2005-05-12 11:20:57
|
On 5:22:42 am 2005-05-12 "Max T. Woodbury" <max...@ve...> wrote: > Earnie Boyd wrote: > > > > Did you follow http://www.mingw.org/MinGWiki/index.php/Build%20MSYS > > instructions? Many now have used them. > > I did get the .dll built using the instructions on that page. They > needed a little bit of adaptation and were just a little confusing. > > The first problem was that MSYS is not usable after its initial > installation on 98SE. There is already a bug report on this. I've > added a comment and posted a request here for other people to see > if they can provide more information. > > The second problem is that strace.exe, which the web page says > should be built, isn't. It needs mingw32-g++ and mingw32-gcc. > The trouble shooting section says to disable these commands. > If you do that, 'make install' aborts before it is complete. > I fixed that problem by having mingw32-g++ and mingw32-gcc > do 'g++ $@' and 'gcc $@' respectively. I also had to comment > out the declaration on strace.cc:27 to get it to work. > I'll try to look at this. Strace should be built with the mingw32-gcc so that the things traced aren't the things used. Strace itself is nothing more than a parser of OutputDebugString info looking for specific string patterns to identify it as MSYS debug information. You can also use sysinternals.com DbgView to see the information GUI realtime. You can apply filters to limit the output in DbgView. You can also specify output to a log file or save the buffered text to a file. > I suspect that MinGW has to be installed and kluged to get > this to work really right. Correct? > Yes. Someone commented that you must modify the generated makefile in the i?86-pc-msys/winsup/utils directory so that mingw32-g[c+][c+] uses -mms-bitfields instead of -fnative-struct. > The trouble shooting section of the web page is a bit confusing > as I said above. It would help if the text between the problem > description bullets was at the same indentation level as the > bullets text. > So fix it. Some other user added that section. I was more than happy that the page had been contributed to. > I've started exploring the other sub-trees. The documentation > on the dvlpr sub-tree is chopped off at then beginning of item > 5. I'll be looking at what is in there shortly but if any can > provide a description before I've spent a lot of time digging > I'd appreciate it. > Time is a valuable item these days. I won't get to it soon. I am glad you are exploring it. I had started it to store items I used to create the distributed package. > Is there any thing special to be done with the package sub-trees? > Specifically, they will almost certainly need to reference the > newlib stuff, the new .dll, possibly libiberty and the include > files. Has this already been included in the configure files > or is there something else that should be done? > If a header file changes or a new function added to the library then the header would need to be copied to the /include directory and the library archive in i?86-pc-msys/winsup/cygwin would need copied to /lib. If no headers or functions were changed or added then you should be set to build the packages. Some need help along the build. RXVT in particular is a pain; build the W11 library first. > A find/grep search showed up a newlib-mb and newlib-hw-fp option. > Are these stable? > I've never worried with newlib beyond the top configure or some msys function that calls a specific reentrant function (_r_*) and I needed to take a look into to follow the code flow. I don't have the time to look at specific newlib options. Max, thanks for your interest in plugging through on this. I very much appreciate it. Earnie -- MinGW - http://www.mingw.org/ Wiki - http://www.mingw.org/MinGWiki/ Bug Report - http://sourceforge.net/tracker/?group_id=2435&atid=102435 Submit Patch - http://sourceforge.net/tracker/?group_id=2435&atid=302435 SF Project - http://sourceforge.net/projects/mingw Job Listing - http://sf.net/people/viewjob.php?group_id=2435&job_id=21643 |
From: Max T. W. <max...@ve...> - 2005-05-12 15:23:51
|
Earnie Boyd wrote: > > On 5:22:42 am 2005-05-12 "Max T. Woodbury" <max...@ve...> wrote: > > > > ... > > > > The second problem is that strace.exe, which the web page says > > should be built, isn't. It needs mingw32-g++ and mingw32-gcc. > > The trouble shooting section says to disable these commands. > > If you do that, 'make install' aborts before it is complete. > > I fixed that problem by having mingw32-g++ and mingw32-gcc > > do 'g++ $@' and 'gcc $@' respectively. I also had to comment > > out the declaration on strace.cc:27 to get it to work. > > > > I'll try to look at this. Strace should be built with the mingw32-gcc so > that the things traced aren't the things used. Strace itself is nothing > more than a parser of OutputDebugString info looking for specific string > patterns to identify it as MSYS debug information. You can also use > sysinternals.com DbgView to see the information GUI realtime. You can > apply filters to limit the output in DbgView. You can also specify output > to a log file or save the buffered text to a file. Yes. I'm sure that what I did was not correct in that the resulting program would not be usable because of recursion, but something was needed to get 'make install' over this particular hurdle. > > I suspect that MinGW has to be installed and kluged to get > > this to work really right. Correct? > > Yes. Someone commented that you must modify the generated makefile in the > i?86-pc-msys/winsup/utils directory so that mingw32-g[c+][c+] uses > -mms-bitfields instead of -fnative-struct. OK, I'll wing it and take notes. > > The trouble shooting section of the web page is a bit confusing > > as I said above. It would help if the text between the problem > > description bullets was at the same indentation level as the > > bullets text. > > So fix it. Some other user added that section. I was more than happy that > the page had been contributed to. I'm reluctant to tromp on other people's work without talking to them first. It seems impolite, but I guess that's the idea behind wiki. Someone is doing a recast on it as we speak. Trying to follow the new description was some of what got me in trouble. > > I've started exploring the other sub-trees. The documentation > > on the dvlpr sub-tree is chopped off at then beginning of item > > 5. I'll be looking at what is in there shortly but if any can > > provide a description before I've spent a lot of time digging > > I'd appreciate it. > > Time is a valuable item these days. I won't get to it soon. I am glad you > are exploring it. I had started it to store items I used to create the > distributed package. Ah. Nuf said. I'll dig in. > > Is there any thing special to be done with the package sub-trees? > > Specifically, they will almost certainly need to reference the > > newlib stuff, the new .dll, possibly libiberty and the include > > files. Has this already been included in the configure files > > or is there something else that should be done? > > If a header file changes or a new function added to the library then the > header would need to be copied to the /include directory and the library > archive in i?86-pc-msys/winsup/cygwin would need copied to /lib. If no > headers or functions were changed or added then you should be set to build > the packages. Some need help along the build. RXVT in particular is a > pain; build the W11 library first. Thanks. Is there a script for this in the 'dvlpr' sub-tree or does it need to be done 'by hand'? > > A find/grep search showed up a newlib-mb and newlib-hw-fp option. > > Are these stable? > > > > I've never worried with newlib beyond the top configure or some msys > function that calls a specific reentrant function (_r_*) and I needed to > take a look into to follow the code flow. I don't have the time to look at > specific newlib options. OK. FYI the 'newlib-hw-fp' option causes 'make all' to blow up. The 'newlib-mb' option completes 'make all' without error. I cleaned up my install target and am letting 'make install' have at the rebuild with 'enable-newlib-mb' as I type this. > Max, thanks for your interest in plugging through on this. I very much > appreciate it. And thank you for telling me that. I've been figuratively beaten for 'arrogance' in presuming to know more than my 'betters' even though I really want to help. I'm pretty good at finding ways to screw things up AND ways to unscrew them. The result is that I can make procedures much less 'brittle' if given some latitude to fix things that are only marginally broken. (I spent 11 years doing telephone support at DEC. I could fix things over the phone that guys on site had trouble with! And it was FUN much of the time when it wasn't depressing.) ma...@mt... |
From: Earnie B. <ea...@us...> - 2005-05-12 18:02:26
|
On 3:23:28 pm 2005-05-12 "Max T. Woodbury" --8<-- > > > The trouble shooting section of the web page is a bit confusing > > > as I said above. It would help if the text between the problem > > > description bullets was at the same indentation level as the > > > bullets text. > > > > So fix it. Some other user added that section. I was more than > > happy that the page had been contributed to. > > I'm reluctant to tromp on other people's work without talking to them > first. It seems impolite, but I guess that's the idea behind wiki. > Someone is doing a recast on it as we speak. Trying to follow the > new description was some of what got me in trouble. > I've added a permissive statement to the page. :) > > > I've started exploring the other sub-trees. The documentation > > > on the dvlpr sub-tree is chopped off at then beginning of item > > > 5. I'll be looking at what is in there shortly but if any can > > > provide a description before I've spent a lot of time digging > > > I'd appreciate it. > > > > Time is a valuable item these days. I won't get to it soon. I am > > glad you are exploring it. I had started it to store items I used > > to create the distributed package. > > Ah. Nuf said. I'll dig in. > > > > Is there any thing special to be done with the package sub-trees? > > > Specifically, they will almost certainly need to reference the > > > newlib stuff, the new .dll, possibly libiberty and the include > > > files. Has this already been included in the configure files > > > or is there something else that should be done? > > > > If a header file changes or a new function added to the library > > then the header would need to be copied to the /include directory > > and the library archive in i?86-pc-msys/winsup/cygwin would need > > copied to /lib. If no headers or functions were changed or added > > then you should be set to build the packages. Some need help > > along the build. RXVT in particular is a pain; build the W11 > library first. > > Thanks. Is there a script for this in the 'dvlpr' sub-tree or does it > need to be done 'by hand'? > Not really. You can study script/msysrls.sh to determine how I set mine up. Earnie |
From: Max T. W. <max...@ve...> - 2005-05-14 05:36:11
|
I've found that the following sequence seems to be the one needed: 1) Install MinGW into its own directory. The default directory is fine. 2) Install MSys into its own directory and connect it to the MinGW directory in the post install processing. There's a problem with the MSYS.BAT file. I'll post the patch shortly. There is also a work around that I've noted in the existing bug report. 3) Install msysDTK into the same directory MSys was installed into. 4) Unpack msysDVLPR in the MSYS root. 5) Get the msys sources. At this point you can build the MSYS .dll after you've invoked msysdvlpr. It is a little confusing which packages need to be build under MSYS and which need to be build under MINGW32 but generally if it says MSYS, it builds under MSYS and if it does not, it builds under MINGW32. Building the packages requires additional pieces, not all of which are working. In particular bison seems to be messed up and is key to several other packages. There are a few text pieces that might be useful: 'man' and the related packages - possibly out of CygWin. 'TeX' for 'ps' and 'dvi' - possibly out of tetex. 'db2html' - I'm not sure where it comes from... ma...@mt... |
From: Michael S. Z. <ms...@mo...> - 2005-05-14 12:29:40
|
On Sat May 14 2005 00:35, Max T. Woodbury wrote: - - - - - > > 'man' and the related packages - possibly out of CygWin. > 'TeX' for 'ps' and 'dvi' - possibly out of tetex. > For use under windows - give this a try: <http://www.miktex.org> All I can say is the usual: "works well for me" Mike > 'db2html' - I'm not sure where it comes from... > > ma...@mt... |
From: Max T. W. <max...@ve...> - 2005-05-15 11:55:28
|
"Max T. Woodbury" wrote: > > The first problem was that MSYS is not usable after its initial > installation on 98SE. There is already a bug report on this. I've > added a comment and posted a request here for other people to see > if they can provide more information. I just posted patch #1202271 to fix this... |
From: Max T. W. <max...@ve...> - 2005-05-22 17:42:07
Attachments:
Scratch.txt
|
Progress report -- I've got 'byacc' working as a substitute for 'bison' when building 'bash'. (Again Thank you Earnie for taking the time to update 'bison'. I'll be trying the new version very soon.) The configuration script has lots of options. I think I saw a note someplace that you can get 'bash' to tell you which options it was built with. I'll be checking that out shortly. In the mean while, I started with nothing but a --prefix specification, configured it and did a 'make'. It blew with a missing header file. I've a huge chronicle of what I've done so far with running comments that I will try to attach to this post. A note on the process I am using -- I'm trying to build the whole MSys kit from scratch and I mean starting without anything but a basic Windows 98SE installation and a network link. If I make too big a mess, I strip back down to the bare system and try again. I've done that at least three times now. I've got the basic MSys run-time build working and documented. I'm in the process of doing the same for the packages. I consider this a kind of apprenticeship. When I can do this all correctly, I should be able to help with most problems, but until I get this right, I'll probably be more trouble than help. I thank you all for putting up with my fumbling. Max |
From: Michael S. Z. <ms...@mo...> - 2005-05-22 19:31:06
|
On Sun May 22 2005 12:41, Max T. Woodbury wrote: > Progress report -- > > I've got 'byacc' working as a substitute for 'bison' when building > 'bash'. (Again Thank you Earnie for taking the time to update 'bison'. > I'll be trying the new version very soon.) The configuration script > has lots of options. I think I saw a note someplace that you can get > 'bash' to tell you which options it was built with. I'll be checking > that out shortly. In the mean while, I started with nothing but a > --prefix specification, configured it and did a 'make'. It blew with > a missing header file. Max Header file: pwd.h perhaps? I stole one from uwin. I don't think the password structure varies from POSIX. It is small and OSS, I could post if you like. Mike |
From: Max T. W. <max...@ve...> - 2005-05-22 20:10:41
|
"Michael S. Zick" wrote: > > On Sun May 22 2005 12:41, Max T. Woodbury wrote: > > Progress report -- > > > > I've got 'byacc' working as a substitute for 'bison' when building > > 'bash'. (Again Thank you Earnie for taking the time to update 'bison'. > > I'll be trying the new version very soon.) The configuration script > > has lots of options. I think I saw a note someplace that you can get > > 'bash' to tell you which options it was built with. I'll be checking > > that out shortly. In the mean while, I started with nothing but a > > --prefix specification, configured it and did a 'make'. It blew with > > a missing header file. > Max > Header file: pwd.h perhaps? > I stole one from uwin. I don't think the password structure varies > from POSIX. > > It is small and OSS, I could post if you like. No, not that one. 'tail' of make-all.log -- gcc -DPROGRAM='"bash.exe"' -DCONF_HOSTTYPE='"i686"' -DCONF_OSTYPE='"msys"' -DCONF_MACHTYPE='"i686-pc-msys"' -DCONF_VENDOR='"pc"' -DSHELL -DHAVE_CONFIG_H -I. -I/xxx/packages/bash/2.04 -I/xxx/packages/bash/2.04/include -I/xxx/packages/bash/2.04/lib -I/new/msys/bash/include -g -O2 -c /xxx/packages/bash/2.04/jobs.c In file included from /xxx/packages/bash/2.04/jobs.c:54: /xxx/packages/bash/2.04/include/shtty.h:61: sgtty.h: No such file or directory make: *** [jobs.o] Error 1 make: Leaving directory `/yyy/bash' $ find / -name sgtty.h didn't find anything, but it doesn't look in the /xxx and so on trees. I've got family stuff going at the moment so I'm not going to be able to get back to this till evening. Max |
From: Earnie B. <ea...@us...> - 2005-05-23 11:14:45
|
On 8:10:22 pm 2005-05-22 "Max T. Woodbury" <max...@ve...> wrote: > "Michael S. Zick" wrote: > > > > On Sun May 22 2005 12:41, Max T. Woodbury wrote: > > > Progress report -- > > > > > > I've got 'byacc' working as a substitute for 'bison' when > > > building 'bash'. (Again Thank you Earnie for taking the time to > > > update 'bison'. I'll be trying the new version very soon.) The > > > configuration script has lots of options. I think I saw a note > > > someplace that you can get 'bash' to tell you which options it > > > was built with. I'll be checking that out shortly. In the mean > > > while, I started with nothing but a --prefix specification, > > > configured it and did a 'make'. It blew with a missing header > > file. Max > > Header file: pwd.h perhaps? > > I stole one from uwin. I don't think the password structure varies > > from POSIX. > > > > It is small and OSS, I could post if you like. > > No, not that one. 'tail' of make-all.log -- > > gcc -DPROGRAM='"bash.exe"' -DCONF_HOSTTYPE='"i686"' > -DCONF_OSTYPE='"msys"' -DCONF_MACHTYPE='"i686-pc-msys"' -DCONF_VENDOR='"pc"' -DSHELL -DHAVE_CONFIG_H -I. -I/xxx/packages/bash > /2.04 -I/xxx/packages/bash/2.04/include -I/xxx/packages/bash/2.04/lib -I > /new/msys/bash/include -g -O2 -c /xxx/packages/bash/2.04/jobs.c > In file included from /xxx/packages/bash/2.04/jobs.c:54: > /xxx/packages/bash/2.04/include/shtty.h:61: sgtty.h: No such file or > directory make: *** [jobs.o] Error 1 > make: Leaving directory `/yyy/bash' > > $ find / -name sgtty.h > didn't find anything, but it doesn't look in the /xxx and so on trees. > I've got family stuff going at the moment so I'm not going to be able > to get back to this till evening. > This is an indication of one of two things: 1) You've not properly installed msysDVLPR 2) You're not in the MSYS environment during the configure process. ``uname -s'' should yield a system name beginning with MSYS_ if you are in the MSYS environment. Earnie |
From: Max T. W. <max...@ve...> - 2005-05-23 15:55:14
|
Earnie Boyd wrote: > > On 8:10:22 pm 2005-05-22 "Max T. Woodbury" <max...@ve...> wrote: > > "Michael S. Zick" wrote: > > > > > > On Sun May 22 2005 12:41, Max T. Woodbury wrote: > > > > Progress report -- > > > > > > > > I've got 'byacc' working as a substitute for 'bison' when > > > > building 'bash'. (Again Thank you Earnie for taking the time to > > > > update 'bison'. I'll be trying the new version very soon.) The Sorry, I really hadn't looked at what you'd put up when I wrote that. You put up a new version of 'bash' which Michael S. Zick asked for. I said I'd try working on it when I got a complete 'from source' build so you have saved me from having to do that, so thanks again. > > > > configuration script has lots of options. I think I saw a note > > > > someplace that you can get 'bash' to tell you which options it > > > > was built with. I'll be checking that out shortly. In the mean > > > > while, I started with nothing but a --prefix specification, > > > > configured it and did a 'make'. It blew with a missing header > > > > file. Max > > > > > > ... > > This is an indication of one of two things: > > 1) You've not properly installed msysDVLPR > 2) You're not in the MSYS environment during the configure process. > > ``uname -s'' should yield a system name beginning with MSYS_ if you are in > the MSYS environment. > Umm I stripped the old tail so I could post the one from 2.05b (I'll throw in a few <nl>s so it will wrap where I want) -- > gcc -DPROGRAM='"bash.exe"' -DCONF_HOSTTYPE='"i686"' -DCONF_OSTYPE='"msys"' ^^^^ > -DCONF_MACHTYPE='"i686-pc-msys"' -DCONF_VENDOR='"pc"' -DSHELL -DHAVE_CONFIG_H ^^^^ > -I. -I/xxx/packages/bash/2.05b -I/xxx/packages/bash/2.05b/include > -I/xxx/packages/bash/2.05b/lib -g -O2 -c /xxx/packages/bash/2.05b/jobs.c > In file included from /xxx/packages/bash/2.05b/jobs.c:52: > /xxx/packages/bash/2.05b/include/shtty.h:61: sgtty.h: No such file or directory > make: *** [jobs.o] Error 1 > make: Leaving directory `/yyy/bash' On (1), IIRC a MINGW/MSYS/msysDTK install sequence does not produce a /include directory. It comes out of unpacking msysDVLPR. I'll not include a 'ls /include' listing because it is quite large, but it is definitely there now. I remember this because of the instructions to copy 'wincon.h' from '/ming/include' could not be done until the unpacking of msysDVLPR had been done. On (2), I've marked a couple of points in the new 'tail'. They were in the old one too. So the problem persists. I'll look at the '#include' context to see what is going on. later... Max |
From: Earnie B. <ea...@us...> - 2005-05-23 16:05:05
|
On 3:54:48 pm 2005-05-23 "Max T. Woodbury" > > So the problem persists. I'll look at the '#include' context to see > what is going on. > > later... The build should never include sgtty as termios.h should have been found by configure. Earnie |
From: Max T. W. <max...@ve...> - 2005-05-23 20:14:34
|
Earnie Boyd wrote: > > On 3:54:48 pm 2005-05-23 "Max T. Woodbury" > > > > > So the problem persists. I'll look at the '#include' context to see > > what is going on. > > > > later... > > The build should never include sgtty as termios.h should have been found by > configure. OK. $ find / -name termios.h /lib/gcc-lib/i686-pc-msys/2.95.3-1/include/sys/termios.h /include/sys/termios.h /include/termios.h /new/msys/rt/i686-pc-msys/include/termios.h /new/msys/rt/i686-pc-msys/include/sys/termios.h Max@STRIDER /yyy/bash $ grep -u2 termios configure.log config.log configure.log-checking for termcap.h... yes configure.log-checking for termio.h... no configure.log:checking for termios.h... no ^^ configure.log-checking for dlfcn.h... yes configure.log-checking for stddef.h... yes -- ... -- configure.log-checking for presence of necessary job control definitions... present configure.log-checking for presence of named pipes... present configure.log:checking POSIX termios... no ^^ configure.log-checking for TIOCSTAT in sys/ioctl.h... no configure.log-checking for FIONREAD in sys/ioctl.h... no -- config.log- from /usr/include/termio.h:14, config.log- from configure:2916: config.log:/bin/../lib/gcc-lib/i686-pc-msys/2.95.3-1/include/sys/termios.h:48: badly punctuated parameter list in `#define' <<<<<!!!!! config.log-configure:2928: result: no config.log-configure:3401: checking for a BSD compatible install -- config.log- from /usr/include/termio.h:14, config.log- from configure:4624: config.log:/bin/../lib/gcc-lib/i686-pc-msys/2.95.3-1/include/sys/termios.h:48: badly punctuated parameter list in `#define' <<<<<!!!!! config.log-configure:4633: $? = 1 config.log-configure: failed program was: -- config.log-#include <termio.h> config.log-configure:4652: result: no config.log:configure:4617: checking for termios.h config.log-configure:4627: gcc -E conftest.c config.log:In file included from /usr/include/termios.h:4, config.log- from configure:4624: config.log:/bin/../lib/gcc-lib/i686-pc-msys/2.95.3-1/include/sys/termios.h:48: badly punctuated parameter list in `#define' <<<<<!!!!! config.log-configure:4633: $? = 1 config.log-configure: failed program was: config.log-#line 4623 "configure" config.log-#include "confdefs.h" config.log:#include <termios.h> config.log-configure:4652: result: no ^^ config.log-configure:4617: checking for dlfcn.h -- config.log-configure:12855: $? = 0 config.log-configure:12909: result: rlim_t config.log:configure:12923: checking for struct termios.c_line config.log-configure:12946: gcc -c -g -O2 conftest.c >&5 config.log:In file included from /usr/include/termios.h:4, config.log- from configure:12932: config.log:/bin/../lib/gcc-lib/i686-pc-msys/2.95.3-1/include/sys/termios.h:48: badly punctuated parameter list in `#define' <<<<<!!!!! config.log-configure:12949: $? = 1 config.log-configure: failed program was: -- ... -- config.log- from /usr/include/termio.h:14, config.log- from configure:12983: config.log:/bin/../lib/gcc-lib/i686-pc-msys/2.95.3-1/include/sys/termios.h:48: badly punctuated parameter list in `#define' <<<<<!!!!! config.log-configure:13000: $? = 1 config.log-configure: failed program was: -- ... -- config.log-} config.log-configure:13211: gcc -c -g -O2 conftest.c >&5 config.log:In file included from /usr/include/termios.h:4, config.log- from configure:13200: config.log:/bin/../lib/gcc-lib/i686-pc-msys/2.95.3-1/include/sys/termios.h:48: badly punctuated parameter list in `#define' <<<<<!!!!! config.log-configure:13214: $? = 1 config.log-configure: failed program was: -- ... -- config.log-configure:14480: $? = 0 config.log-configure:14493: result: present config.log:configure:14502: checking POSIX termios config.log-configure:14523: gcc -o conftest.exe -g -O2 conftest.c >&5 config.log:In file included from /usr/include/termios.h:4, config.log- from configure:14511: config.log:/bin/../lib/gcc-lib/i686-pc-msys/2.95.3-1/include/sys/termios.h:48: badly punctuated parameter list in `#define' <<<<<!!!!! config.log-configure:14526: $? = 1 config.log-configure: failed program was: -- ... -- config.log-ac_cv_header_termcap_h=yes config.log-ac_cv_header_termio_h=no config.log:ac_cv_header_termios_h=no ^^ config.log-ac_cv_header_time=yes config.log-ac_cv_header_unistd_h=yes -- config.log-ac_cv_member_struct_stat_st_blocks=yes config.log-ac_cv_member_struct_termio_c_line=no config.log:ac_cv_member_struct_termios_c_line=no ^^ config.log-ac_cv_member_struct_tm_tm_zone=no config.log-ac_cv_objext=o -- config.log-ac_cv_sys_large_files=no config.log-ac_cv_sys_largefile_CC=no config.log:ac_cv_sys_posix_termios=no ^^ config.log-ac_cv_type_bits16_t=no config.log-ac_cv_type_bits32_t=no HooKay... 48+(10/2)=53... $ head -n53 /lib/gcc-lib/i686-pc-msys/2.95.3-1/include/sys/termios.h | tail #define TIOCPKT_DOSTOP 32 #define FIONBIO 0x8004667e /* To be compatible with socket version */ #define CTRL(c'h') ((ch)&0x1F) ^^^^ #define CNUL 0 #define CDEL 0x0007f #define CESC '\\' #define CINTR CTRL('C') Same thing in /new.../sys and /include/sys. What it should be is more than I want to guess at this point, so I'll comment it out and try again... $ cd /yyy/bash $ rm -fr * $ /xxx/packages/bash/2.05b/configure --prefix=/new/msys/bash 2>&1 | \ tee configure.log and it's off... ... checking for termcap.h... yes checking for termio.h... yes checking for termios.h... yes checking for dlfcn.h... yes checking for stddef.h... yes later... max |