Обсуждение: Libxml2 load error on Windows
Hi,
http://postgresql.1045698.n5.nabble.com/9-2-beta1-libxml2-can-t-be-loaded-on-Windows-td5710672.html
postgres=# SELECT xml '<foo>bar</foo>';
ERROR: could not set up XML error handler
HINT: This probably indicates that the version of libxml2 being used is not compatible with the libxml2 header files that PostgreSQL was built with.
HAVE_XMLSTRUCTUREDERRORCONTEXT should be defined if libxml2 has xmlStructuredErrorContext (introduced after 2.7.3). It is being set for Linux in pg_config.h:
/* Define to 1 if your libxml has xmlStructuredErrorContext. */
#define HAVE_XMLSTRUCTUREDERRORCONTEXT 1
For Windows build, we need to set it in "src/tools/msvc/Solution.pm".
I guess there are two approaches to get the libxml2 version:
1) Parse "LIBXML_INST/include/libxml/xmlversion.h" to get the libxml2 version number, this header file is included in libxml2.
2) We may also get the version by running a command line utility i.e "LIBXML_INST/bin/xmllint --version". The xmllint program parses one or more XML files and it is also included in libxml2.
I believe it is safe to assume that libxml2 include folder would contain xmlversion.h file containing the required version number. It might be a touch slower to parse the file line by line, but similar functionality has been used elsewhere as well. We obviously rely on xml include files (with xml enabled), so there is definitely a tighter dependency on include files than xmllint executable as it is not mandatory for build process.
Therefore, I used first approach to get libxml2 version number and include the "#define HAVE_XMLSTRUCTUREDERRORCONTEXT" in pg_config.h if libxml2 version is greater than 20703 (which effectively is 2.7.3). Please find attached patch "libxml2_win_v1.patch".
Regards,
Talha Bin Rizwan
Вложения
On Mon, Jun 18, 2012 at 5:08 AM, Talha Bin Rizwan <talha.rizwan@gmail.com> wrote: > PostgreSQL 9.2 Windows build is having trouble with the XML support: > http://postgresql.1045698.n5.nabble.com/9-2-beta1-libxml2-can-t-be-loaded-on-Windows-td5710672.html > > postgres=# SELECT xml '<foo>bar</foo>'; > ERROR: could not set up XML error handler > HINT: This probably indicates that the version of libxml2 being used is not > compatible with the libxml2 header files that PostgreSQL was built with. > > HAVE_XMLSTRUCTUREDERRORCONTEXT should be defined if libxml2 > has xmlStructuredErrorContext (introduced after 2.7.3). It is being set for > Linux in pg_config.h: > > /* Define to 1 if your libxml has xmlStructuredErrorContext. */ > #define HAVE_XMLSTRUCTUREDERRORCONTEXT 1 > > For Windows build, we need to set it in "src/tools/msvc/Solution.pm". > > I guess there are two approaches to get the libxml2 version: > > 1) Parse "LIBXML_INST/include/libxml/xmlversion.h" to get the > libxml2 version number, this header file is included in libxml2. > > 2) We may also get the version by running a command line utility > i.e "LIBXML_INST/bin/xmllint --version". The xmllint program parses one > or more XML files and it is also included in libxml2. > > I believe it is safe to assume that libxml2 include folder would contain > xmlversion.h file containing the required version number. It might be a > touch slower to parse the file line by line, but similar functionality has > been used elsewhere as well. We obviously rely on xml include files (with > xml enabled), so there is definitely a tighter dependency on include files > than xmllint executable as it is not mandatory for build process. > > Therefore, I used first approach to get libxml2 version number and include > the "#define HAVE_XMLSTRUCTUREDERRORCONTEXT" in pg_config.h if > libxml2 version is greater than 20703 (which effectively is 2.7.3). Please > find attached patch "libxml2_win_v1.patch". Please add this patch here so that it doesn't get lost in the shuffle: https://commitfest.postgresql.org/action/commitfest_view/open -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Tue, Jun 19, 2012 at 4:43 AM, Robert Haas <robertmhaas@gmail.com> wrote: > > > Please add this patch here so that it doesn't get lost in the shuffle: > > https://commitfest.postgresql.org/action/commitfest_view/open Hmm, that raises an interesting question (though maybe I've just missed this happening in the past). This is a bug fix, that we'll want in the next back branch updates, not just 9.3. Sticking it in the open commit fest means it may well not get looked at for 2-3 months or so. How do we prevent that happening? -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Dave Page <dpage@pgadmin.org> writes: > On Tue, Jun 19, 2012 at 4:43 AM, Robert Haas <robertmhaas@gmail.com> wrote: >> >> >> Please add this patch here so that it doesn't get lost in the shuffle: >> >> https://commitfest.postgresql.org/action/commitfest_view/open > > Hmm, that raises an interesting question (though maybe I've just > missed this happening in the past). This is a bug fix, that we'll want > in the next back branch updates, not just 9.3. Sticking it in the open > commit fest means it may well not get looked at for 2-3 months or so. > How do we prevent that happening? In a real bug-tracking system we would create a new bug/ticket and set it's target version to 'candidate for next minor release' or something like that. This way, if we don't release unless all targeted bugs are resolved, this would be taken care of (hopefully.)
On Tue, Jun 19, 2012 at 11:04 AM, Alex Shulgin <ash@commandprompt.com> wrote: > > Dave Page <dpage@pgadmin.org> writes: > >> On Tue, Jun 19, 2012 at 4:43 AM, Robert Haas <robertmhaas@gmail.com> wrote: >>> >>> >>> Please add this patch here so that it doesn't get lost in the shuffle: >>> >>> https://commitfest.postgresql.org/action/commitfest_view/open >> >> Hmm, that raises an interesting question (though maybe I've just >> missed this happening in the past). This is a bug fix, that we'll want >> in the next back branch updates, not just 9.3. Sticking it in the open >> commit fest means it may well not get looked at for 2-3 months or so. >> How do we prevent that happening? > > In a real bug-tracking system we would create a new bug/ticket and set > it's target version to 'candidate for next minor release' or something > like that. This way, if we don't release unless all targeted bugs are > resolved, this would be taken care of (hopefully.) Well yes, but the point is that that is not how the project works. I'm asking how we do handle this problem at the moment, because I realised I haven't seen this happen in the past (largely because I haven't been paying attention). -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Dave Page <dpage@pgadmin.org> writes: > On Tue, Jun 19, 2012 at 11:04 AM, Alex Shulgin <ash@commandprompt.com> wrote: >> >> In a real bug-tracking system we would create a new bug/ticket and set >> it's target version to 'candidate for next minor release' or something >> like that. This way, if we don't release unless all targeted bugs are >> resolved, this would be taken care of (hopefully.) > > Well yes, but the point is that that is not how the project works. I'm > asking how we do handle this problem at the moment, because I realised > I haven't seen this happen in the past (largely because I haven't been > paying attention). It only works as long as there is some mechanism to ensure that the bugs which were not submitted to commitfest are looked at. If there is no, then it doesn't work actually. So is there a real and reliable mechanism for that? -- Alex
On Tue, Jun 19, 2012 at 6:36 AM, Alex Shulgin <ash@commandprompt.com> wrote: > Dave Page <dpage@pgadmin.org> writes: >> On Tue, Jun 19, 2012 at 11:04 AM, Alex Shulgin <ash@commandprompt.com> wrote: >>> >>> In a real bug-tracking system we would create a new bug/ticket and set >>> it's target version to 'candidate for next minor release' or something >>> like that. This way, if we don't release unless all targeted bugs are >>> resolved, this would be taken care of (hopefully.) >> >> Well yes, but the point is that that is not how the project works. I'm >> asking how we do handle this problem at the moment, because I realised >> I haven't seen this happen in the past (largely because I haven't been >> paying attention). > > It only works as long as there is some mechanism to ensure that the bugs > which were not submitted to commitfest are looked at. If there is no, > then it doesn't work actually. > > So is there a real and reliable mechanism for that? No. There probably should be, but in the meantime adding it to the CommitFest is better than a poke in the eye with a sharp stick. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Mon, Jun 18, 2012 at 02:08:29PM +0500, Talha Bin Rizwan wrote: > PostgreSQL 9.2 Windows build is having trouble with the XML support: > http://postgresql.1045698.n5.nabble.com/9-2-beta1-libxml2-can-t-be-loaded-on-Windows-td5710672.html > Therefore, I used first approach to get libxml2 version number and include > the "#define HAVE_XMLSTRUCTUREDERRORCONTEXT" in pg_config.h if libxml2 version > is greater than 20703 (which effectively is 2.7.3). Please find attached > patch "libxml2_win_v1.patch". Tom fixed this differently; effectively, we now use a check like you describe on all platforms, not just Windows: http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=470d0b9789981bc91a8ef2654911d80ab6a6be57 Since that commit makes your patch obsolete, I'm marking it Rejected. Even so, thank you for calling attention to the problem and submitting this fix. nm