Libxml2 load error on Windows
Hi,
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".
Regards,
Talha Bin Rizwan
Attachments:
libxml2_win_v1.patchapplication/octet-stream; name=libxml2_win_v1.patchDownload
diff --git a/src/tools/msvc/Solution.pm b/src/tools/msvc/Solution.pm
index 0c50c05..65719b1 100644
--- a/src/tools/msvc/Solution.pm
+++ b/src/tools/msvc/Solution.pm
@@ -204,6 +204,20 @@ s{PG_VERSION_STR "[^"]+"}{__STRINGIFY(x) #x\n#define __STRINGIFY2(z) __STRINGIFY
{
print O "#define HAVE_LIBXML2\n";
print O "#define USE_LIBXML\n";
+
+ # Parse xmlversion.h to get version number
+ open(X,"$self->{options}->{xml}/include/libxml/xmlversion.h")
+ || confess("Could not open xmlversion.h for reading\n");
+ while (<X>)
+ {
+ if (/^#define LIBXML_VERSION (.*)/)
+ {
+ print O "#define HAVE_XMLSTRUCTUREDERRORCONTEXT\n"
+ if ($1 > 20703);
+ last;
+ }
+ }
+ close(X);
}
if ($self->{options}->{xslt})
{
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.htmlpostgres=# 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 1For 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:
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