From: Julien L. <lec...@fr...> - 2005-05-23 21:47:53
|
> -----Original Message----- > Subject: Re: [Mingw-msys] How do I recreate the MSYS distribution? > > <snip snip snip> > ^^^^ > > -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' > Here's a link to the problem and resolution: http://www.amanitamuscaria.org/content/view/10/0/ I'll (or if someone else wants to) put that on the MinGWiki. Julien Ps : About the subject "How do I recreate the MSYS distribution?"; I'm also trying to provide a clean and easy way to build what I call a "Msys From Scratch" Please contribute !!! At the current stage, it almost works (some headers aren't installed, and thus the new mSys doesn't yet really work) http://www.mingw.org/MinGWiki/index.php/mSysFromScratch |
From: Max T. W. <max...@ve...> - 2005-05-23 23:16:58
|
Julien Lecomte wrote: > > > Here's a link to the problem and resolution: > http://www.amanitamuscaria.org/content/view/10/0/ There are two items in there, one of which you patch in exactly the same way that I worked out a few minutes ago. A patch should be written for 'msys' and whoever wrote that header originally. I was going to do it, but you have priority if you want it. The note on 'termcap' is correct, but is not the whole story. Since the replacement 'termcap' is incorrect, either its generation has to be corrected or its proper source needs to be found. Then there needs to be a patch that puts the result in the generated package's space, not in the current system. The proximate patch for the placement is to 'configure', but the ultimate patch should be to the generation file. Since there is a work around, I was going to wait on it until I'd gotten a whole build done before going into that. > I'll (or if someone else wants to) put that on the MinGWiki. > > Julien > > Ps : About the subject "How do I recreate the MSYS distribution?"; I'm also > trying to provide a clean and easy way to build what I call a "Msys From > Scratch" > > Please contribute !!! At the current stage, it almost works (some headers > aren't installed, and thus the new mSys doesn't yet really work) > http://www.mingw.org/MinGWiki/index.php/mSysFromScratch You've set it that up as a 'howto'. There was already a much smaller 'howto' on part of it. I've been writing a chronicle and posted a part of it to this list a little while ago. You're welcome to use the information it contains with a 'thanks to' note. When I looked at what you've written so far, the biggest problem I have is the reference to GnuW32. Whoever is doing that is recreating the wheel and only doing a fair job of it. Their personal taste in build environments gets into their packages and will make it harder for someone else to use their basic work. Further, using it will slow down getting corrections to their proper point of application. I've tried to locate original distributions where I could. I guess I'm actually trying to go one step further than you are. When I say 'source' I mean a CVS or other network repository source, not just a tarball. A tarball will meet many requirements and will let someone make changes they need, but the result will be a forked project with the resulting contribution to the OSS community diluted. But that's getting pretty deep and I have a personal problem I have to take care of PDQ. Max |
From: Julien L. <lec...@fr...> - 2005-05-24 00:57:12
|
> -----Original Message----- > From: > Max T. Woodbury > Sent: mardi 24 mai 2005 01:17 > Julien Lecomte wrote: > > > > > > Here's a link to the problem and resolution: > > http://www.amanitamuscaria.org/content/view/10/0/ > > There are two items in there, one of which you patch in > exactly the same way that I worked out a few minutes ago. A > patch should be written for 'msys' and whoever wrote that > header originally. > I was going to do it, but you have priority if you want it. > Yeah, my inbox synchronized with the outbox... And I saw that you found the same result. The current header file in the CVS of mSys is already patched. > The note on 'termcap' is correct, but is not the whole story. > Since the replacement 'termcap' is incorrect, either its > generation has to be corrected or its proper source needs to > be found. Then there needs to be a patch that puts the > result in the generated package's space, not in the current > system. The proximate patch for the placement is to > 'configure', but the ultimate patch should be to the > generation file. Since there is a work around, I was going > to wait on it until I'd gotten a whole build done before > going into that. I've still got to understand what exactly that termcap file does. With or without it, everything works fine for me. > > > I'll (or if someone else wants to) put that on the MinGWiki. > > > > Julien > > > > Ps : About the subject "How do I recreate the MSYS > distribution?"; I'm > > also trying to provide a clean and easy way to build what I call a > > "Msys From Scratch" > > > > Please contribute !!! At the current stage, it almost works (some > > headers aren't installed, and thus the new mSys doesn't yet really > > work) http://www.mingw.org/MinGWiki/index.php/mSysFromScratch > > You've set it that up as a 'howto'. There was already a much > smaller 'howto' on part of it. I've been writing a chronicle > and posted a part of it to this list a little while ago. > You're welcome to use the information it contains with a > 'thanks to' note. The HowTo is basically just on the mSys package, not on recreating a whole mSys with tools and co. > > When I looked at what you've written so far, the biggest > problem I have is the reference to GnuW32. Whoever is doing > that is recreating the wheel and only doing a fair job of it. > Their personal taste in build environments gets into their > packages and will make it harder for someone else to use > their basic work. Further, using it will slow down getting > corrections to their proper point of application. > I've tried to locate original distributions where I could. Yeah, I hate that windres stuff too. If I have spare time, I'll try to do a autoconf macro to test for windres and autocreate a rc file for executables under win*. Nevertheless, the flex and bison packages were, at the time, the best ones I had found. I'm not too sure about a compiling a canonical coreutils from mSys though (to be tested in the days to come) > I guess I'm actually trying to go one step further than you are. > When I say 'source' I mean a CVS or other network repository > source, not just a tarball. A tarball will meet many > requirements and will let someone make changes they need, but > the result will be a forked project with the resulting > contribution to the OSS community diluted. But that's > getting pretty deep and I have a personal problem I have to > take care of PDQ. > > Max > I'm also for CVS and not just tarballs, but that means that the mSys module should contain all the cvs of basically everytool that is currently missing (flex, bison, etc...) Earnie, what's your input on that ? J |
From: Max T. W. <max...@ve...> - 2005-05-24 06:06:32
|
Julien Lecomte wrote: > > > -----Original Message----- > > From: > Max T. Woodbury > > Sent: mardi 24 mai 2005 01:17 > > > > The note on 'termcap' is correct, but is not the whole story. > > Since the replacement 'termcap' is incorrect, either its > > generation has to be corrected or its proper source needs to > > be found. Then there needs to be a patch that puts the > > result in the generated package's space, not in the current > > system. The proximate patch for the placement is to > > 'configure', but the ultimate patch should be to the > > generation file. Since there is a work around, I was going > > to wait on it until I'd gotten a whole build done before > > going into that. > > I've still got to understand what exactly that termcap file does. With or > without it, everything works fine for me. It tells the programs that use it how to move the cursor around and what character sequences the keys on the keyboard generate. As usual there are other ways to do the same thing. The chief alternative is the various 'curses' packages. > > When I looked at what you've written so far, the biggest > > problem I have is the reference to GnuW32. Whoever is doing > > that is recreating the wheel and only doing a fair job of it. > > Their personal taste in build environments gets into their > > packages and will make it harder for someone else to use > > their basic work. Further, using it will slow down getting > > corrections to their proper point of application. > > I've tried to locate original distributions where I could. > > Yeah, I hate that windres stuff too. If I have spare time, I'll try to do a > autoconf macro to test for windres and autocreate a rc file for executables > under win*. That's a good piece of it, but he uses non-POSIX path names all over the place, like his reference to 'e:' One of the really nice things about MinGW/MSys is the POSIX path syntax. > Nevertheless, the flex and bison packages were, at the time, the best ones I > had found. I'm not too sure about a compiling a canonical coreutils from > mSys though (to be tested in the days to come) I've decided that 'bison' is too big a mess to deal with at the moment since the 'byacc' distribution from GNU builds 'out of the box' on MINGW32. You might consider using it in place of 'bison'. The canonical 'flex' also builds without trouble. 'coreutils' was one of the things I was going to tackle on the next major pass at this thing. I'll be interested in what you find. > > I guess I'm actually trying to go one step further than you are. > > When I say 'source' I mean a CVS or other network repository > > source, not just a tarball. A tarball will meet many > > requirements and will let someone make changes they need, but > > the result will be a forked project with the resulting > > contribution to the OSS community diluted. But that's > > getting pretty deep and I have a personal problem I have to > > take care of PDQ. > > I'm also for CVS and not just tarballs, but that means that the mSys module > should contain all the cvs of basically everytool that is currently missing > (flex, bison, etc...) > > Earnie, what's your input on that ? I think I saw something from him that he wanted that kind of thing in the msys-DTK, not in 'msys'. This would make special sense if the tools can be built unmodified under either the MSYS or MINGW32 environments. If I understood him correctly, the stuff actually in 'msys' was to be things that everyone would use on a regular basis and your 'average user' is not likely to play with either 'flex' or 'bison'. (On the other hand he is likely to want a 'man' page or two in addition to 'info'.) But I might be stepping on his toes so I'd better shut my mouth... Max |
From: Max T. W. <max...@ve...> - 2005-05-25 18:13:59
|
Progress report -- I've built the following to the point where 'make install' works: autoconf from GNU - not in msys/packages. I had trouble with enough packages and autoconf that I tried reinstalling it. I'll look for differences from the MinGW kit RSN... bash-2.05b 2.04 also built. Both have problems in make-check... byacc from Cygwin - a substitute for 'bison' bzip2 not under autoconf. Copy the tree to be safe. check from Cygwin - it didn't solve the problem I was trying to solve - not recommended. diffutils ... fileutils ... findutils ... flex from GNU, sort of... gawk ... m4 ... rt I think there are problems with the .dll but I am NOT sure rxvt This took some hacking with CPPFLAGS and LDFLAGS. I think I understand what Earnie meant by his comments on W11 now. I may be able to work up a patch or two to make this easier. Strange second version tree that I ignored... Patches? Letting it call itself an 'xterm' causes less trouble when I 'ssh' into other systems... sed ... termcap I've posted a patch and a bug report. At least one of those took hacking that I failed to log. There is trouble with the following -- grep It insists on doing an 'autoconf' and can't find macro _m4_divert_diversion gzip In file included from /usr/include/unistd.h:7, from /xxx/packages/gzip/1.2.4a/gzip.c:76: /usr/include/getopt.h:41: redefinition of `struct option' less in configure -- checking for working terminal libraries... Cannot find terminal libraries - configure failed make _m4_divert_diversion again sh-utils autoconf macros AM_FUNC_ERROR_AT_LINE and AM_FUNC_STRTOD Reinstalling 'autoconf' may have fixed this... tar some kind of automake or autoconf problem... texinfo needs some kind of terminal library... textutils same as sh-utils vim Argh! IIRC it blew but I trashed to logs. me bad! bison It builds but the 'check' target shows serious issues. Since 'byacc' is available, I'm going to wait on this one. I think I'm close to the point where I could write a script to do this. I do need to ream the system out again and redo it because I've kluged too much. I'm close to having this under control but I need to get the last of it working first so the ream-out and restart will have to wait. There are a number of text processing and other tools that would get more of the make targets functional. For example one of the TeX packages, etags, docbook and groff are all called upon. I also saw a calls for 'runtest' without a clue where to get it. (Actually I'll probably be able to dig its origin out of RedHat Linux. I just haven't gotten to it yet.) max |
From: Max T. W. <max...@ve...> - 2005-05-25 21:42:38
|
"Max T. Woodbury" wrote: > There are a number of text processing and other tools that would > get more of the make targets functional. For example one of the > TeX packages, etags, docbook and groff are all called upon. I > also saw a calls for 'runtest' without a clue where to get it. > (Actually I'll probably be able to dig its origin out of RedHat > Linux. I just haven't gotten to it yet.) Not installed on my Linux box. Google shows it as part of DejaGnu. |
From: Michael S. Z. <ms...@mo...> - 2005-05-25 21:57:32
|
On Wed May 25 2005 16:42, Max T. Woodbury wrote: > "Max T. Woodbury" wrote: > > There are a number of text processing and other tools that would > > get more of the make targets functional. For example one of the > > TeX packages, etags, docbook and groff are all called upon. I > > also saw a calls for 'runtest' without a clue where to get it. > > (Actually I'll probably be able to dig its origin out of RedHat > > Linux. I just haven't gotten to it yet.) > > Not installed on my Linux box. Google shows it as part of DejaGnu. > List; Those are all disk space hungry applications. Suggestion: Most applications that can build documentation have configure/make options to control the documentation generation... Perhaps, as an msys modification, default all of that stuff to OFF/NONE. Which brings to mind, most "configure" applications will accept a configure.site file. Look in the cross-builds branch of Bash tree for examples. There is already a win32sig.h in there that might be extended for msys. This could be used to provide a set of msys custom options to all "configure" driven setups. I.E: turn off docs, select byacc, etc. Mike |
From: Michael S. Z. <ms...@mo...> - 2005-05-25 22:52:29
|
On Wed May 25 2005 16:57, Michael S. Zick wrote: > > Look in the cross-builds branch of Bash tree for examples. There is > already a win32sig.h in there that might be extended for msys. > Oops, brain fart; that should be: *.cache files are the examples. Mike |
From: Michael S. Z. <ms...@mo...> - 2005-05-25 23:03:25
|
On Wed May 25 2005 16:42, Max T. Woodbury wrote: > "Max T. Woodbury" wrote: > > There are a number of text processing and other tools that would > > get more of the make targets functional. For example one of the > > TeX packages, etags, docbook and groff are all called upon. I > > also saw a calls for 'runtest' without a clue where to get it. > Probably presumes that you have built and tested gcc . . . Check the dejagnu test package. Best bet is the one distributed on the gcc site/mirrors. Mike |
From: Max T. W. <max...@ve...> - 2005-05-25 22:18:41
|
"Max T. Woodbury" wrote: > > Progress report -- > > ... > > At least one of those took hacking that I failed to log. There is trouble > with the following -- > > ... > vim Argh! IIRC it blew but I trashed to logs. me bad! It does not have autoconf control files, at least at the top level but it does have 'configure'. Like bzip2, you have to build in the source tree. Watching it configure, I noticed that it could not find the termcap library but libtermcap.a is built as part of package/termcap. $ find / -name libtermcap.a only shows the one in the target directory. Strange... that might explain at least one other build problem... |
From: Max T. W. <max...@ve...> - 2005-05-26 03:18:15
|
"Max T. Woodbury" wrote: > ... > > Watching it configure, I noticed that it could not find the termcap library > but libtermcap.a is built as part of package/termcap. > $ find / -name libtermcap.a > only shows the one in the target directory. Strange... that might explain > at least one other build problem... In fact copying libtermcap.a to /lib let both 'less' and 'vim' build and install cleanly. Earnie: Should libtermcap.a be in var/MinGW/lib.dat or var/msys/lib.dat? That leaves: grep gzip make sh-utils tar textutils Several of those are auto<something> problems. I think I'll look at that set of problems next... (That will give me an excuse to go through the book I just bought.) ma...@mt... |
From: Earnie B. <ea...@us...> - 2005-05-26 11:09:37
|
On 3:17:57 am 2005-05-26 "Max T. Woodbury" <max...@ve...> wrote: > > Earnie: > Should libtermcap.a be in var/MinGW/lib.dat or var/msys/lib.dat? > That depends upon which runtime libtermcap.a is dependent on; MSVCRT or MSYS-1.0. 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 Job Listing - http://sf.net/people/viewjob.php?group_id=46778&job_id=22223 |
From: Max T. W. <max...@ve...> - 2005-05-26 11:33:42
|
Earnie Boyd wrote: > > On 3:17:57 am 2005-05-26 "Max T. Woodbury" <max...@ve...> wrote: > > > > > Earnie: > > Should libtermcap.a be in var/MinGW/lib.dat or var/msys/lib.dat? > > > > That depends upon which runtime libtermcap.a is dependent on; MSVCRT or > MSYS-1.0. > > Earnie Since it's a static library I'm not sure. Presumably since it is in the packages tree of the msys module it would depend on MSYS-1.0. There are also two other possibilities if I understand what is going on. I guess I was really asking if it belonged in any of them? I've been up all night trying to get automake and autoconf to do something right with respect to the stuff that wouldn't build. So far I found that the automake tarball is a 'PORT' and it wanted 'wget'. I have just got that installed and am in the process of reimporting automake. However I've done something stupid and need to get some sleep before I try to fix it. It will be well after noon when I get back to it... max |
From: Earnie B. <ea...@us...> - 2005-05-26 16:30:33
|
On 11:33:21 am 2005-05-26 "Max T. Woodbury" <max...@ve...> wrote: > Earnie Boyd wrote: > > > > On 3:17:57 am 2005-05-26 "Max T. Woodbury" <max.teneyck.woodbury@ve > rizon.net> wrote: > > > > > > > > Earnie: > > > Should libtermcap.a be in var/MinGW/lib.dat or > > > var/msys/lib.dat? > > > > That depends upon which runtime libtermcap.a is dependent on; > > MSVCRT or MSYS-1.0. > > > > Earnie > > Since it's a static library I'm not sure. Presumably since it is in > the packages tree of the msys module it would depend on MSYS-1.0. > There are also two other possibilities if I understand what is going > on. I guess I was really asking if it belonged in any of them? > > I've been up all night trying to get automake and autoconf to do > something right with respect to the stuff that wouldn't build. > So far I found that the automake tarball is a 'PORT' and it > wanted 'wget'. I have just got that installed and am in the > process of reimporting automake. However I've done something > stupid and need to get some sleep before I try to fix it. It > will be well after noon when I get back to it... > You shouldn't need autoconf, automake or libtool to ./configure && make. The autotool suite is supposed to provide the user of the application a means to configure the application based on already installed dependencies. Unfortunately, because of the GPL and the GNU Coding Standard, the maintainer modules must be supplied with the source in order to allow modification to that source. In fact the autotool suite exists to satisfy requirements of the GNU Coding Standard. The configure script is the result of the autotool packages and is what the end user is supposed to use. You only need the autotool packages if you change the configuration of the source, e.g. add a source file that needs to be distributed and/or compiled. Simply modifying an existing source file, unless that source file is one of the autotool control files, does not constitute the need for installing the autotools suite. If you change autotool generated files such that the timestamp depedency order is out of sync, then the generated make file will complain. See the cygwin2msys script for a method to touch the generated files to correct the timestamp dependency out of sync problem. Earnie |
From: Max T. W. <max...@ve...> - 2005-06-07 06:13:30
|
Progress report: I'm giving up on 'flex' out of SourceForge for the moment and going back the Cygwin kit. The problem is that the newer versions of 'flex' require a working 'flex' to build. The Cygwin version is ancient 2.5.4a vs 2.5.31 for the latest on SourceForge, but it does NOT require an extant 'flex'. What is a real joker is that the EARLIEST version of 'flex' on SourceForge is 2.5.5b! I'll go with the Cygwin kit for now, but if someone drops me a link to a CVS repository that contains 4a, I'll try it. Otherwise that search goes on the 'maybe later, maybe never' list. With a working 'flex' I've built the descriptors for all the rest of the packages in the MSYS-1.0.11 kit (a.k.a -D '2004-04-30 18:55' from CVS). I've put all of them in the package build list and will turn the machine loose tonight to find where things do not work. I know 'tar' at least will go belly up since I haven't done 'bison' from scratch yet. A note on 'flex' for those who want to duplicate this effort (and I think I've said this before, so please forgive me if I'm repeating myself) -- it has to be built in its own source tree. It looks like it should build in a side directory like most packages, but it blows up if you try it. Current successful build list -- cw-flex msys-bash msys-m4 msys-texinfo msys-base msys-less msys-termcap sf-byacc (That's bash 2.04 fyi.) |
From: Mark J. <mj...@gm...> - 2005-06-07 07:11:33
|
Max T. Woodbury schrieb: >Progress report: > >I'm giving up on 'flex' out of SourceForge for the moment and going back >the Cygwin kit. > That's strange. Building flex worked here. The only things you have to do is: 1. Compile and install a working regex The one from the debian site is quite good and works out of the box. Don't forget to install the latest regex patch. 2. Compile flex export CFLAGS="-D__MINGW32__" export CCFLAGS="-D__MINGW32__" export CPPFLAGS="-D__MINGW32__" export CXXFLAGS="-D__MINGW32__" export CFLAGS="-D__MINGW32__" export LIBS="-lregex" ./configure --prefix=/. --build=i686-pc-mingw32 That's it (IMHO). The main problem with I had with flex was that the regex in msys-1.0.dll is badly broken. Regards, Mark |
From: Earnie B. <ea...@us...> - 2005-06-07 11:08:39
|
On 7:11:31 am 2005-06-07 Mark Junker <mj...@gm...> wrote: > Max T. Woodbury schrieb: > > > Progress report: > > > > I'm giving up on 'flex' out of SourceForge for the moment and going > > back the Cygwin kit. > > > That's strange. Building flex worked here. The only things you have > to do is: > > 1. Compile and install a working regex > > The one from the debian site is quite good and works out of the > box. Don't forget to install the latest regex patch. > > 2. Compile flex > > export CFLAGS="-D__MINGW32__" > export CCFLAGS="-D__MINGW32__" > export CPPFLAGS="-D__MINGW32__" > export CXXFLAGS="-D__MINGW32__" > export CFLAGS="-D__MINGW32__" These should not be needed as __MINGW32__ is defined by the compiler. > export LIBS="-lregex" > ./configure --prefix=/. --build=i686-pc-mingw32 > > > That's it (IMHO). > > The main problem with I had with flex was that the regex in > msys-1.0.dll is badly broken. > Regex in msys-1.0.dll? You shouldn't be using msys-1.0.dll for a native build. What do you mean? 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 Job Listing - http://sf.net/people/viewjob.php?group_id=46778&job_id=22223 |
From: Mark J. <mj...@gm...> - 2005-06-08 01:17:19
|
Earnie Boyd schrieb: >Regex in msys-1.0.dll? You shouldn't be using msys-1.0.dll for a native >build. What do you mean? > > Ahhh ... sorry ... I thought you tried to compile flex as MSYS application (see topic) ... Regards, Mark |
From: Michael S. Z. <ms...@mo...> - 2005-06-08 02:28:23
|
On Tue June 7 2005 20:17, Mark Junker wrote: > Earnie Boyd schrieb: > > >Regex in msys-1.0.dll? You shouldn't be using msys-1.0.dll for a native > >build. What do you mean? > > > > > Ahhh ... sorry ... I thought you tried to compile flex as MSYS > application (see topic) ... > Yup, it does get confusing. The msys environment is a mingw (A.K.A: win-native) thingy. I suppose that applications to run under msys would be target=msys; and would target the msys.dll; but don't quote me on that, I haven't looked and I am tired. The things compiled target=mingw target the MS C Runtime Library. The tool chain also supports x86-64, which would be target=mingw64 which you will not find anywhere yet. That might have to change to target=ia64win and target=amd64win since server-2003 SDK makes that distinction to run on x86, ia64 and amd64. Then there is also a target=mingw32 - which I believe is the windows-95/98/me flavor that targets the win32 sub-system; I could be wrong on this one also. Mike |
From: Earnie B. <ea...@us...> - 2005-06-08 11:15:41
|
On 1:17:07 am 2005-06-08 Mark Junker <mj...@gm...> wrote: > Earnie Boyd schrieb: > > > Regex in msys-1.0.dll? You shouldn't be using msys-1.0.dll for a > > native build. What do you mean? > > > > > Ahhh ... sorry ... I thought you tried to compile flex as MSYS > application (see topic) ... > The example you gave was for building as the __MINGW32__ native version correct? Defining __MINGW32__ for __MSYS__ sounds a bit ominous to me. How about a patch to correct what you say is broken with MSYS? 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 Job Listing - http://sf.net/people/viewjob.php?group_id=46778&job_id=22223 |
From: Mark J. <mj...@gm...> - 2005-06-08 18:55:59
|
Earnie Boyd schrieb: >The example you gave was for building as the __MINGW32__ native version >correct? Defining __MINGW32__ for __MSYS__ sounds a bit ominous to me. > > This isn't needed for flex but for some other projects that use the __MINGW32__ to detect a windows platform. >How about a patch to correct what you say is broken with MSYS? > > Hmm ... too bad but I simply don't have time to do this (yet) because I have to finish another project immediately. However, I noticed two problems (at least with 1.0.10): 1. regex is not fully supported (compared to the regex library from debian ... and required by flex) 2. some regex debug output is shown 3. compiling applications with -lc causes errors about duplicate symbol definitions Regards, Mark |
From: Michael S. Z. <ms...@mo...> - 2005-06-07 07:51:30
|
On Tue June 7 2005 01:12, Max T. Woodbury wrote: > Progress report: > > I'm giving up on 'flex' out of SourceForge for the moment and going back > the Cygwin kit. The problem is that the newer versions of 'flex' require > a working 'flex' to build. The Cygwin version is ancient 2.5.4a vs 2.5.31 > for the latest on SourceForge, but it does NOT require an extant 'flex'. > What is a real joker is that the EARLIEST version of 'flex' on SourceForge > is 2.5.5b! I'll go with the Cygwin kit for now, but if someone drops me > a link to a CVS repository that contains 4a, I'll try it. Otherwise that > search goes on the 'maybe later, maybe never' list. > It moved from "gnu" to "non-gnu" <ftp://ftp.gnu.org/non-gnu/flex/> Mike |
From: Max T. W. <max...@ve...> - 2005-06-08 14:33:42
|
Mark Junker wrote: > > Max T. Woodbury schrieb: > > >Progress report: > > > >I'm giving up on 'flex' out of SourceForge for the moment and going back > >the Cygwin kit. > > > That's strange. Building flex worked here. The only things you have to > do is: > > 1. Compile and install a working regex > > The one from the debian site is quite good and works out of the box. > Don't forget to install the latest regex patch. > > 2. Compile flex > > export CFLAGS="-D__MINGW32__" > export CCFLAGS="-D__MINGW32__" > export CPPFLAGS="-D__MINGW32__" > export CXXFLAGS="-D__MINGW32__" > export CFLAGS="-D__MINGW32__" > export LIBS="-lregex" > ./configure --prefix=/. --build=i686-pc-mingw32 > > That's it (IMHO). > > The main problem with I had with flex was that the regex in msys-1.0.dll > is badly broken. > > Regards, > Mark This is more than a bit strange. I'm still groggy this morning so I could easily be mistaken, but I'm trying to locate active CVS sources for things, not just tarballs. GNU (or non-GNU) has tarballs for 'flex' but no CVS IIRC while there seems to be an active CVS repository for 'flex' on SourceForge. I would really like to try to get a good build from the SourceForge CVS but that archive does not go back to the 'known good' 2.5.4a point. The latest (2.5.31) requires more than a little jiggery-pokery and still can't find all the headers it needs. I got the Cygwin kit (i.e. a tarball) to build under MSYS with only a generic fix to the /share/automake-1.7/config.guess and /share/automake-1.7/config.sub files. (A basic change so that 'automake' and 'autoconf' thinks MSYS is 'posix'y.) Progress Report -- I did a deeper than usual ream-out and freed some extra disk space, did Spyware and Virus scans and defraged the drive. (I found a recent article on all the different scans that 'knowledgeable' people use. I'm missing a couple at the moment...) There's a version of 'df' in the fileutils kit. It compiles and runs but produces wrong numbers for local drives under some circumstances. Network drives seem to be OK. It might be a 2GB (31 bit) limit of some kind... I started a complete rebuild shortly after one -- Started at Wed Jun 8 01:04:01 EDT 2005 Filesystem 1k-blocks Used Available Use% Mounted on c: 2096832 0 2096832 0% /c Starting to install msysDVLPR-1.0.0-alpha-1 for MSys at Wed Jun 8 01:04:05 EDT 2005 Filesystem 1k-blocks Used Available Use% Mounted on c: 2096832 0 2096832 0% /c Finished installing msysDVLPR-1.0.0-alpha-1 at Wed Jun 8 01:05:14 EDT 2005 Filesystem 1k-blocks Used Available Use% Mounted on c: 2096832 0 2096832 0% /c Starting to apply patch termios_h at Wed Jun 8 01:05:18 EDT 2005 ... It just stopped cranking a few minutes ago -- Finished final cleanup at Wed Jun 8 08:46:41 EDT 2005 Finished at Wed Jun 8 08:46:44 EDT 2005 Filesystem 1k-blocks Used Available Use% Mounted on c: 2096832 0 2096832 0% /c and produced cw-flex msys-bzip2 msys-findutils msys-less msys-sh-utils sf-byacc msys-base msys-diffutils msys-gawk msys-m4 msys-termcap msys-bash msys-fileutils msys-grep msys-sed msys-texinfo I need to fix the msys-sh-utils build since it doesn't put '.exe' on anything. I've also got to add a piece that saves the unstripped .exe and then strips them. (Earnie: What parameters did you use for strip? '-S', '-SX' ...) I've done a successful msys-rxvt build by hand so I should be able to get that on the list PDQ. 'gzip' has a problem with 'struct option' (or something like that) being defined in two different headers. 'tar' insists on 'bison', which I should be able to reconstruct since I got both 'byacc' and 'flex' to build. I haven't done anything but note that the /bin directory was empty for 'textutils' and 'vim'. I think I got both of those up with a little fiddling before. Now I just have to get the details 'on paper'. The 'bash' build has not configuration options specified and I suspect that at least some should be. I'll try to find the method where the build options actually used can be extracted from the executable, but if someone can save me that particular search, it might speed things up a bit. Also, the resulting builds contain a number of additional pieces that did NOT get included in any distribution, like the libtermcap.a out of the termcap package and ALL the 'info' and 'man' files. It looks like this phase will end soon. Next will be a 'MinGW' 3.1.0-1 kit reconstruction, then the msys-DTK and msysDVLPR kits and some other odd pieces. That should establish a firm foundation for fixing problems... Max |