Updates to the .l/.y files under tools/libxl/ over the last month lead to the unfortunate situation that libxl failed to build on my SLE10 systems. Looking at README at the root of the tree doesn''t reveal anything but the fact that the two utilities are required (i.e. in particular there''s no mini,mum version specified), and the common ground for utility versions so far was what RHEL5 and SLE10 provide. While, with some hassle, I was able to work around that by building newer m4, bison, and flex versions, the situation currently is clearly in need of improvement. Jan
On Mon, 2013-05-13 at 14:44 +0100, Jan Beulich wrote:> Updates to the .l/.y files under tools/libxl/ over the last month lead > to the unfortunate situation that libxl failed to build on my SLE10 > systems. Looking at README at the root of the tree doesn''t reveal > anything but the fact that the two utilities are required (i.e. in > particular there''s no mini,mum version specified), and the common > ground for utility versions so far was what RHEL5 and SLE10 > provide.IIRC we check in the generated files for these tools precisely because one or more of these older distros didn''t have a new enough version of one or the other (flex?). Hopefully Ian J remembers more about what the required feature is. So the intention is that you shouldn''t need to regenerate these files on those systems, but of course if you are patching the .l/.y at RPM build time that isn''t going to work. The logical extension of the above is that your RPM patches should also patch the generated files, presumably with a version built on a newer distro with a newer flex. Not terribly satisfactory for you I think. So in practice these files are most often regenerated on the tool''s maintainers/committers systems, which are typically running Debian Squeeze. I have: $ bison --version bison (GNU Bison) 2.4.1 $ flex --version flex 2.5.35 How does that compare with what you have? With any luck Ian J will remember what the original issue was and we can update the docs and configure to suit... Ian.> > While, with some hassle, I was able to work around that by building > newer m4, bison, and flex versions, the situation currently is clearly > in need of improvement.
Ian Campbell writes ("Re: [Xen-devel] bison/flex version
requirements"):> On Mon, 2013-05-13 at 14:44 +0100, Jan Beulich wrote:
> > Updates to the .l/.y files under tools/libxl/ over the last month lead
> > to the unfortunate situation that libxl failed to build on my SLE10
> > systems. Looking at README at the root of the tree doesn''t
reveal
> > anything but the fact that the two utilities are required (i.e. in
> > particular there''s no mini,mum version specified), and the
common
> > ground for utility versions so far was what RHEL5 and SLE10
> > provide.
>
> IIRC we check in the generated files for these tools precisely because
> one or more of these older distros didn''t have a new enough
version of
> one or the other (flex?). Hopefully Ian J remembers more about what the
> required feature is.
IIRC RHEL5 is too old. It had a totally ancient version of at least
one of flex or bison which couldn''t even produce reentrant
scanners/parsers.
> So the intention is that you shouldn''t need to regenerate these
files on
> those systems, but of course if you are patching the .l/.y at RPM build
> time that isn''t going to work. The logical extension of the above
is
> that your RPM patches should also patch the generated files, presumably
> with a version built on a newer distro with a newer flex. Not terribly
> satisfactory for you I think.
I concur.
But in general you should be able to avoid regenerating these files if
you don''t patch the inputs.
Ian.
Ian Jackson writes ("Re: [Xen-devel] bison/flex version
requirements"):> IIRC RHEL5 is too old. It had a totally ancient version of at least
> one of flex or bison which couldn''t even produce reentrant
> scanners/parsers.
Searching my mail archives turned up this:
http://lists.xen.org/archives/html/xen-devel/2010-07/msg01237.html
In that message I assert that RHEL5 has a version of flex from _1993_.
Ian.
>>> On 13.05.13 at 16:10, Ian Campbell <Ian.Campbell@citrix.com> wrote: > On Mon, 2013-05-13 at 14:44 +0100, Jan Beulich wrote: >> Updates to the .l/.y files under tools/libxl/ over the last month lead >> to the unfortunate situation that libxl failed to build on my SLE10 >> systems. Looking at README at the root of the tree doesn''t reveal >> anything but the fact that the two utilities are required (i.e. in >> particular there''s no mini,mum version specified), and the common >> ground for utility versions so far was what RHEL5 and SLE10 >> provide. > > IIRC we check in the generated files for these tools precisely because > one or more of these older distros didn''t have a new enough version of > one or the other (flex?). Hopefully Ian J remembers more about what the > required feature is. > > So the intention is that you shouldn''t need to regenerate these files on > those systems, but of course if you are patching the .l/.y at RPM build > time that isn''t going to work. The logical extension of the above is > that your RPM patches should also patch the generated files, presumably > with a version built on a newer distro with a newer flex. Not terribly > satisfactory for you I think.Actually there''s no RPM involved here, I''m doing a simple local build. The one aspect that is specific (and likely different from most others) is that when I snapshot the repository, I hard link files that are identical to their counterpart in the most recent earlier snapshot to that counterpart. Hence time stamps then can look to make as if one of the generated files would need updating. But that''s only as background - I ought to be able to build things also when I need to touch one of the source files (however infrequent that may be for me personally).> So in practice these files are most often regenerated on the tool''s > maintainers/committers systems, which are typically running Debian > Squeeze. I have: > $ bison --version > bison (GNU Bison) 2.4.1 > $ flex --version > flex 2.5.35 > > How does that compare with what you have?2.1 and 2.5.31. Jan
On Mon, 2013-05-13 at 15:26 +0100, Ian Jackson wrote:> Ian Campbell writes ("Re: [Xen-devel] bison/flex version requirements"): > > On Mon, 2013-05-13 at 14:44 +0100, Jan Beulich wrote: > > > Updates to the .l/.y files under tools/libxl/ over the last month lead > > > to the unfortunate situation that libxl failed to build on my SLE10 > > > systems. Looking at README at the root of the tree doesn''t reveal > > > anything but the fact that the two utilities are required (i.e. in > > > particular there''s no mini,mum version specified), and the common > > > ground for utility versions so far was what RHEL5 and SLE10 > > > provide. > > > > IIRC we check in the generated files for these tools precisely because > > one or more of these older distros didn''t have a new enough version of > > one or the other (flex?). Hopefully Ian J remembers more about what the > > required feature is. > > IIRC RHEL5 is too old. It had a totally ancient version of at least > one of flex or bison which couldn''t even produce reentrant > scanners/parsers.We know that these are OK as minimums: Squeeze: flex = 2.5.35 ; bison = 2.4.1 The older distros have: RHEL5: flex = 2.5.4a ; bison = 2.3 SLES10: flex = 2.5.3 ; bison = 2.1 Which seems to suggest that our real minimums are something >2.5.4a and>2.3, I suppose it depends on which Jan had trouble with.The origin commit doesn''t tell us much: commit 05b99c93cb61809a369763db29803816df49407d Author: Keir Fraser <keir.fraser@citrix.com> Date: Fri Mar 5 14:35:09 2010 +0000 Commit output from flex for benefit of prehistoric people Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com> Signed-off-by: Keir Fraser <keir.fraser@citrix.com> The archives around the time aren''t telling me much either. Ian.
Jan Beulich writes ("Re: [Xen-devel] bison/flex version
requirements"):>On 13.05.13 at 16:10, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > $ bison --version
> > bison (GNU Bison) 2.4.1
> > $ flex --version
> > flex 2.5.35
> >
> > How does that compare with what you have?
>
> 2.1 and 2.5.31.
Looking at the changelog for flex:
We depend on `yylex_init_extra'' which was introduced in flex 2.5.34
released in December 2007.
2.5.34 also fixes some memory leaks which may be relevant.
Bison version 2.1 is from February 2006.
Having read the changelog I think the latest thing we definitely need
is this:
Finish implementation of per-type %destructor/%printer.
from 2006-09-04, released in version 2.3a, but a user would very
likely want bugfixes (eg memory leak fixes) that are later than that.
Ian.
>>> On 13.05.13 at 16:52, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote: > Jan Beulich writes ("Re: [Xen-devel] bison/flex version requirements"): >>On 13.05.13 at 16:10, Ian Campbell <Ian.Campbell@citrix.com> wrote: >> > $ bison --version >> > bison (GNU Bison) 2.4.1 >> > $ flex --version >> > flex 2.5.35 >> > >> > How does that compare with what you have? >> >> 2.1 and 2.5.31. > > Looking at the changelog for flex: > > We depend on `yylex_init_extra'' which was introduced in flex 2.5.34 > released in December 2007.So minimally the configure script should then actually check for this.> 2.5.34 also fixes some memory leaks which may be relevant. > > Bison version 2.1 is from February 2006. > > Having read the changelog I think the latest thing we definitely need > is this: > Finish implementation of per-type %destructor/%printer. > from 2006-09-04, released in version 2.3a, but a user would very > likely want bugfixes (eg memory leak fixes) that are later than that.And this (at least via a version check). Jan
Jan Beulich writes ("Re: [Xen-devel] bison/flex version
requirements"):> On 13.05.13 at 16:52, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> > We depend on `yylex_init_extra'' which was introduced in flex
2.5.34
> > released in December 2007.
>
> So minimally the configure script should then actually check for this.
It would be OK for it to issue a warning IMO. I don''t think it should
be an error because we do in fact supply pregenerated files for the
uses of prehistoric distros.
Ian.
On Mon, 2013-05-13 at 16:03 +0100, Ian Jackson wrote:> Jan Beulich writes ("Re: [Xen-devel] bison/flex version requirements"): > > On 13.05.13 at 16:52, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote: > > > We depend on `yylex_init_extra'' which was introduced in flex 2.5.34 > > > released in December 2007. > > > > So minimally the configure script should then actually check for this. > > It would be OK for it to issue a warning IMO. I don''t think it should > be an error because we do in fact supply pregenerated files for the > uses of prehistoric distros.It should warn and not set $(FLEX) or $(BISON), since the version on the system is not sufficient it should be treated as not present. Ian.
>>> On 13.05.13 at 17:03, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote: > Jan Beulich writes ("Re: [Xen-devel] bison/flex version requirements"): >> On 13.05.13 at 16:52, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote: >> > We depend on `yylex_init_extra'' which was introduced in flex 2.5.34 >> > released in December 2007. >> >> So minimally the configure script should then actually check for this. > > It would be OK for it to issue a warning IMO. I don''t think it should > be an error because we do in fact supply pregenerated files for the > uses of prehistoric distros.Would such a warning be noticeable in any way? I.e. before running into the subsequent build error? If not, there''s little point in adding one, and then only adding the minimal version to README might be what can usefully be done. Jan
Jan Beulich writes ("Re: [Xen-devel] bison/flex version
requirements"):> On 13.05.13 at 17:03, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> > It would be OK for it to issue a warning IMO. I don''t think
it should
> > be an error because we do in fact supply pregenerated files for the
> > uses of prehistoric distros.
>
> Would such a warning be noticeable in any way? I.e. before running
> into the subsequent build error? If not, there''s little point in
adding
> one, and then only adding the minimal version to README might be
> what can usefully be done.
It could set
FLEX=false your flex is too old
or soemthing.
Ian.