[xml] XPath, namespaces and no results. :(
I'm trying to parse specific bits of information from an xml file using the XPath syntax, without much luck. Here is a snippet of my xml file:- ?xml version=1.0 encoding=ISO-8859-1? MELODY xmlns=http://www.foo.com; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://www.foo.com http://www.foo.com/xml_schema/melody.xsd; Version=1 Tempo=132 Resolution=Demisemiquaver Genre=Pop Year=1976 Duet=Yes TRACK Name=Player1 Artist=Bob/TRACK TRACK Name=Player2 Artist=Tom/TRACK /MELODY Here is my code for querying some details of it:- xmlChar player1Path[] = /MELODY/[EMAIL PROTECTED]'Player1']; xmlXPathContextPtr context; xmlXPathObjectPtr result; context = xmlXPathNewContext(doc); int foo = xmlXPathRegisterNs(context, BAD_CAST , BAD_CAST http://www.foo.com;); result = xmlXPathEvalExpression(player1Path, context); if ( !xmlXPathNodeSetIsEmpty(result-nodesetval) ) { xmlNodeSetPtr nodeset = result-nodesetval; if ( nodeset-nodeNr 0 ) { buffer = xmlGetProp(nodeset-nodeTab[0], BAD_CAST Artist); if ( buffer != NULL ) printf(%s\n, (const char*)buffer); xmlFree(buffer); } } xmlXPathFreeObject(result); The code should search for the TRACK element, which has the attribute Name = 'Player1', then query the Artist attribute off that element. i.e. 'Bob'. It fails however, result-nodesetval is empty. The only time I've had it work is if I don't define any namespaces in the xml file and don't register any namespaces on the context. When I look at the context structure in a debugger, the namespaces array element still remains NULL after the xmlXPathRegisterNs function call, although this function does return zero for success. Is this the correct behaviour? Otherwise any other ideas on what I'm doing wrong? Thanks, Arthur. PS I'm using the latest windows build of the libaray: 2.6.17. ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org http://mail.gnome.org/mailman/listinfo/xml
[xml] xml schema validation
We recently upgraded from libxml2 2.6.7 to 2.6.17 and discovered that the following xml, that was marked as valid in 2.6.7 is now marked as invalid: wwwtest isn=103 xmlns=http://library.wur.nl/WebQuery/ns/wwwtest; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://library.wur.nl/WebQuery/ns/wwwtest http://library.wur.nl/WebQuery/ns/wwwtest.xsd; elemtest/elem /wwwtest If we just create a prefix for it, it becomes valid again: x:wwwtest isn=103 xmlns:x=http://library.wur.nl/WebQuery/ns/wwwtest; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://library.wur.nl/WebQuery/ns/wwwtest http://library.wur.nl/WebQuery/ns/wwwtest.xsd; elemtest/elem /x:wwwtest Can anybody tell me why the first form is invalid ? ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org http://mail.gnome.org/mailman/listinfo/xml
Re: [xml] XPath, namespaces and no results. :(
On Tue, Mar 15, 2005 at 11:57:26AM +, Arthur Yarwood wrote: xmlChar player1Path[] = /MELODY/[EMAIL PROTECTED]'Player1']; [...] int foo = xmlXPathRegisterNs(context, BAD_CAST , BAD_CAST [...] Otherwise any other ideas on what I'm doing wrong? Your problem is that you don't understand XPath namespaces ... The FAQ entry http://xmlsoft.org/wiki/index.php?title=Libxslt:FAQ is quite clear in my opinion, and you're not following the suggestions ! xmlChar player1Path[] = /foo:MELODY/foo:[EMAIL PROTECTED]'Player1']; int foo = xmlXPathRegisterNs(context, BAD_CAST foo, BAD_CAST http://www.foo.com;); Daniel -- Daniel Veillard | Red Hat Desktop team http://redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org http://mail.gnome.org/mailman/listinfo/xml
Re: [xml] c14n
The most likely reason for c14n failure in your case is DAV: namespace. Most likely, it failed on xml parsing stage. Aleksey ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org http://mail.gnome.org/mailman/listinfo/xml
Re: [xml] c14n
On Tue, Mar 15, 2005 at 07:26:13AM -0800, Aleksey Sanin wrote: The most likely reason for c14n failure in your case is DAV: namespace. Most likely, it failed on xml parsing stage. hum, no, it's only a warning, garanteed ! Daniel -- Daniel Veillard | Red Hat Desktop team http://redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org http://mail.gnome.org/mailman/listinfo/xml
[xml] xmlParseFile with minimal library
I am trying to build a minimal-sized libxml2 but need to use xmlParseFile. I'm using the following flags to configure, which *almost* works - xmlParseFile is the only link error I've seen so far. Can anyone tell me if there is another flag I need? --minimum --tree --valid --iso8859x The application is going to be embedded, so I'd like to minimize size of libxml while being able to parse validate an xml file into the tree form. Thanks for any help or ideas, Henry Bibb [EMAIL PROTECTED] ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org http://mail.gnome.org/mailman/listinfo/xml
Re: [xml] c14n
Then it fails in relative namespace check inside C14N (see notes in section 2.1 of c14n spec: http://www.w3.org/TR/2001/REC-xml-c14n-20010315) Aleksey Daniel Veillard wrote: On Tue, Mar 15, 2005 at 07:26:13AM -0800, Aleksey Sanin wrote: The most likely reason for c14n failure in your case is DAV: namespace. Most likely, it failed on xml parsing stage. hum, no, it's only a warning, garanteed ! Daniel ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org http://mail.gnome.org/mailman/listinfo/xml
Re: [xml] c14n
On Tue, 2005-03-15 at 07:38 -0800, Aleksey Sanin wrote: Then it fails in relative namespace check inside C14N (see notes in section 2.1 of c14n spec: http://www.w3.org/TR/2001/REC-xml-c14n-20010315) from my reading of http://webdav.org/specs/rfc2518.html#rfc.section.18 DAV: is an absolute URL, not a relative one. Or am I misunderstanding you and/or the note in the c14n spec? either way, it would be nice if the error reported explained the problem a bit better. Martijn ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org http://mail.gnome.org/mailman/listinfo/xml
Re: [xml] c14n
On Tue, Mar 15, 2005 at 05:25:50PM +0100, Martijn van Beers wrote: On Tue, 2005-03-15 at 07:38 -0800, Aleksey Sanin wrote: Then it fails in relative namespace check inside C14N (see notes in section 2.1 of c14n spec: http://www.w3.org/TR/2001/REC-xml-c14n-20010315) from my reading of http://webdav.org/specs/rfc2518.html#rfc.section.18 DAV: is an absolute URL, not a relative one. Or am I misunderstanding According to my reading of RFC2396 it's not ! absoluteURI = scheme : ( hier_part | opaque_part ) hier_part = ( net_path | abs_path ) [ ? query ] net_path = // authority [ abs_path ] abs_path = / path_segments there is no / after the : so it can't be a hier_part opaque_part = uric_no_slash *uric uric_no_slash = unreserved | escaped | ; | ? | : | @ | | = | + | $ | , and absolute URI requires something after the : in that case too. you and/or the note in the c14n spec? either way, it would be nice if the error reported explained the problem a bit better. that I agree with, Daniel -- Daniel Veillard | Red Hat Desktop team http://redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org http://mail.gnome.org/mailman/listinfo/xml
Re: [xml] c14n
either way, it would be nice if the error reported explained the problem a bit better. that I agree with, Currently, all c14n errors are ifdef'd with DEBUG_C14N. Should we just turn them on by default? Aleksey ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org http://mail.gnome.org/mailman/listinfo/xml
Re: [xml] c14n
On Tue, 2005-03-15 at 11:38 -0500, Daniel Veillard wrote: On Tue, Mar 15, 2005 at 05:25:50PM +0100, Martijn van Beers wrote: On Tue, 2005-03-15 at 07:38 -0800, Aleksey Sanin wrote: Then it fails in relative namespace check inside C14N (see notes in section 2.1 of c14n spec: http://www.w3.org/TR/2001/REC-xml-c14n-20010315) from my reading of http://webdav.org/specs/rfc2518.html#rfc.section.18 DAV: is an absolute URL, not a relative one. Or am I misunderstanding According to my reading of RFC2396 it's not ! Indeed. however, I found http://cvs.apache.org/viewcvs.cgi/*checkout*/ietf-uri/rev-2002/issues.html?rev=HEADcontent-type=text/html#014-empty-opaque_part so it will be allowed in the future. Any chance of getting this specific bit in before the new rfc gets published? Martijn ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org http://mail.gnome.org/mailman/listinfo/xml
Re: [xml] xml schema validation
Hi, Kuperus, AgeJan wrote: We recently upgraded from libxml2 2.6.7 to 2.6.17 and discovered that the following xml, that was marked as valid in 2.6.7 is now marked as invalid: wwwtest isn=103 xmlns=http://library.wur.nl/WebQuery/ns/wwwtest; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://library.wur.nl/WebQuery/ns/wwwtest http://library.wur.nl/WebQuery/ns/wwwtest.xsd; elemtest/elem /wwwtest If we just create a prefix for it, it becomes valid again: x:wwwtest isn=103 xmlns:x=http://library.wur.nl/WebQuery/ns/wwwtest; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://library.wur.nl/WebQuery/ns/wwwtest http://library.wur.nl/WebQuery/ns/wwwtest.xsd; elemtest/elem /x:wwwtest Can anybody tell me why the first form is invalid ? Your schema has a elementFormDefault=unqualified attribute, which states that locally declared elements are in no namespace. When you used the default namespace, elem was bound to that namespace as well, which was not correct according to your schema. When you removed the default namespace and prefixed it, and explicitely set x:wwwtest to be in that namespace but not elem. So your latter case is the correct one. Libxml2 2.6.7 has a schema implementation dated of 2004-01-24. This scenario wasn't handled correctly a year ago. Regards, Kasimier ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org http://mail.gnome.org/mailman/listinfo/xml
Re: [xml] c14n
On Tue, Mar 15, 2005 at 09:06:36AM -0800, Aleksey Sanin wrote: either way, it would be nice if the error reported explained the problem a bit better. that I agree with, Currently, all c14n errors are ifdef'd with DEBUG_C14N. Should we just turn them on by default? Depends: 1/ do they use the existing structured error reporting framework ? I think so but double checking quickly would be good 2/ is there any drawback for example speed wise ? 3/ would that be a problem for upper layer like xmldsig ? In general people appreciate receiving error messages when stuff fails. Daniel -- Daniel Veillard | Red Hat Desktop team http://redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org http://mail.gnome.org/mailman/listinfo/xml
Re: [xml] c14n
Indeed. however, I found http://cvs.apache.org/viewcvs.cgi/*checkout*/ietf-uri/rev-2002/issues.html?rev=HEADcontent-type=text/html#014-empty-opaque_part so it will be allowed in the future. Any chance of getting this specific bit in before the new rfc gets published? I don't have any problem with it. Daniel? Aleksey ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org http://mail.gnome.org/mailman/listinfo/xml
Re: [xml] c14n
On Tue, Mar 15, 2005 at 10:13:53AM -0800, Aleksey Sanin wrote: Indeed. however, I found http://cvs.apache.org/viewcvs.cgi/*checkout*/ietf-uri/rev-2002/issues.html?rev=HEADcontent-type=text/html#014-empty-opaque_part so it will be allowed in the future. Any chance of getting this specific bit in before the new rfc gets published? I don't have any problem with it. Daniel? It's a bit more general than just WebDAV, see my other post about 3986, Daniel -- Daniel Veillard | Red Hat Desktop team http://redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org http://mail.gnome.org/mailman/listinfo/xml
Re: [xml] c14n
On Tue, Mar 15, 2005 at 10:13:53AM -0800, Aleksey Sanin wrote: Indeed. however, I found http://cvs.apache.org/viewcvs.cgi/*checkout*/ietf-uri/rev-2002/issues.html?rev=HEADcontent-type=text/html#014-empty-opaque_part so it will be allowed in the future. Any chance of getting this specific bit in before the new rfc gets published? I don't have any problem with it. Daniel? It's a bit more general than just WebDAV, see my other post about 3986, Yes, I've seen it. But I can hard code DAV: exception in c14n for now. It's ugly but I am not sure there is other workaround for Martijn. Aleksey ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org http://mail.gnome.org/mailman/listinfo/xml
Re: [xml] c14n
On Tue, Mar 15, 2005 at 10:13:32AM -0800, Aleksey Sanin wrote: Currently, all c14n errors are ifdef'd with DEBUG_C14N. Should we just turn them on by default? Depends: 1/ do they use the existing structured error reporting framework ? I think so but double checking quickly would be good Yes. Errors are printed out using xmlGenericError(xmlGenericErrorContext, ...) calls. Hum, it's not the structured API. The structured one provides more informations, more generically, see include/libxml/xmlerror.h, there is a XML_FROM_C14N error domain, and an error range for C14N (starting at XML_C14N_CREATE_CTXT 1950 to 2000) for error numbers. Best is to define in c14n.c a couple of intermediate calls which sets the context up and call __xmlRaiseError or __xmlSimpleError, see for example xmlTreeErrMemory() and xmlTreeErr() at the beginning of the tree.c module. Not really fun to do, defining new enums for errors and calling the intermediate functions but it makes a huge difference when the library is embedded in a more complex framework. 2/ is there any drawback for example speed wise ? I don't think so. It is only error case which should not happen during normal run. I'll make sure that only errors will be undefed. The main drawback can be the code size inflation, but using intermediate simpler calls at the beginning of the modules avoid most of the code size increase (don't get me started on ELF symbols lookup at runtime ...) 3/ would that be a problem for upper layer like xmldsig ? Not to xmldsig. It should be no difference for normal run. okay, though the structured error handling might be useful for your users too ;-) In general people appreciate receiving error messages when stuff fails. Yes, I know :) especially if they can automate the processing of said errors :-) Daniel -- Daniel Veillard | Red Hat Desktop team http://redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org http://mail.gnome.org/mailman/listinfo/xml
Re: [xml] c14n
On Tue, Mar 15, 2005 at 10:19:30AM -0800, Aleksey Sanin wrote: On Tue, Mar 15, 2005 at 10:13:53AM -0800, Aleksey Sanin wrote: Indeed. however, I found http://cvs.apache.org/viewcvs.cgi/*checkout*/ietf-uri/rev-2002/issues.html?rev=HEADcontent-type=text/html#014-empty-opaque_part so it will be allowed in the future. Any chance of getting this specific bit in before the new rfc gets published? I don't have any problem with it. Daniel? It's a bit more general than just WebDAV, see my other post about 3986, Yes, I've seen it. But I can hard code DAV: exception in c14n for now. It's ugly but I am not sure there is other workaround for Martijn. it's ugly, but it's your module, so :-) At least keep a note about the future uri.c revision around the hack... Daniel -- Daniel Veillard | Red Hat Desktop team http://redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org http://mail.gnome.org/mailman/listinfo/xml
Re: [xml] c14n
Sounds good. I'll do it this week (I hope). Aleksey Daniel Veillard wrote: On Tue, Mar 15, 2005 at 10:13:32AM -0800, Aleksey Sanin wrote: Currently, all c14n errors are ifdef'd with DEBUG_C14N. Should we just turn them on by default? Depends: 1/ do they use the existing structured error reporting framework ? I think so but double checking quickly would be good Yes. Errors are printed out using xmlGenericError(xmlGenericErrorContext, ...) calls. Hum, it's not the structured API. The structured one provides more informations, more generically, see include/libxml/xmlerror.h, there is a XML_FROM_C14N error domain, and an error range for C14N (starting at XML_C14N_CREATE_CTXT 1950 to 2000) for error numbers. Best is to define in c14n.c a couple of intermediate calls which sets the context up and call __xmlRaiseError or __xmlSimpleError, see for example xmlTreeErrMemory() and xmlTreeErr() at the beginning of the tree.c module. Not really fun to do, defining new enums for errors and calling the intermediate functions but it makes a huge difference when the library is embedded in a more complex framework. 2/ is there any drawback for example speed wise ? I don't think so. It is only error case which should not happen during normal run. I'll make sure that only errors will be undefed. The main drawback can be the code size inflation, but using intermediate simpler calls at the beginning of the modules avoid most of the code size increase (don't get me started on ELF symbols lookup at runtime ...) 3/ would that be a problem for upper layer like xmldsig ? Not to xmldsig. It should be no difference for normal run. okay, though the structured error handling might be useful for your users too ;-) In general people appreciate receiving error messages when stuff fails. Yes, I know :) especially if they can automate the processing of said errors :-) Daniel ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org http://mail.gnome.org/mailman/listinfo/xml
[xml] gethrtime and *Timer
I'm not at all sure that gettimeofday() overhead is an issue for libxml2, but thought I'd point-out (at the risk of bringing-up something already discussed) that a number of platforms seem to have a lighter-weight gethrtime() call that can be used to time things. I suppose that as I get farther along with netperf4 I may see if gettimeofday() overhead is indeed an issue. sincerely, rick jones ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org http://mail.gnome.org/mailman/listinfo/xml
[xml] libxml2-2.6.18 on freebsd
Hi, im trying to install libxml2-2.6.18 from the FreeBSD ports, there is a problem with the compile on the system i am using. I have tried several versions of libxml2 and they all return the same error, which means its probably not an issue involved with libxml, but I cant pin down where the error is coming from, or what is causing the problem to occur. I was hoping someone on this list would be able to point me in the direction of what is causing this. The error is: cc -O -pipe -pedantic -W -Wformat -Wunused -Wimplicit -Wreturn-type -Wswitch -Wcomment -Wtrigraphs -Wformat -Wchar-subscripts -Wuninitialized -Wparentheses -Wshadow -Wpointer-arith -Wcast-align -Wwrite-strings -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Winline -Wredundant-decls -o .libs/xpath1 xpath1.o -L/usr/local/lib ../../.libs/libxml2.so -lz -liconv -lm -Wl,--rpath -Wl,/usr/local/lib ../../.libs/libxml2.so: undefined reference to `__signbit' gmake[3]: *** [xpath1] Error 1 gmake[3]: Leaving directory `/usr/ports/textproc/libxml2/work/libxml2-2.6.18/doc/examples' gmake[2]: *** [all-recursive] Error 1 gmake[2]: Leaving directory `/usr/ports/textproc/libxml2/work/libxml2-2.6.18/doc' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/ports/textproc/libxml2/work/libxml2-2.6.18' gmake: *** [all] Error 2 *** Error code 2 Stop in /usr/ports/textproc/libxml2. Any help here is greatly appreciated Regards Alex -- Alex Shaw ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org http://mail.gnome.org/mailman/listinfo/xml
Re: [xml] gethrtime and *Timer
On Tue, Mar 15, 2005 at 11:58:53AM -0800, Rick Jones wrote: I'm not at all sure that gettimeofday() overhead is an issue for libxml2, but thought I'd point-out (at the risk of bringing-up something already discussed) that a number of platforms seem to have a lighter-weight gethrtime() call that can be used to time things. I suppose that as I get farther along with netperf4 I may see if gettimeofday() overhead is indeed an issue. There is an even simpler way to check: grep gettimeofday *.c - testSAX.c and xmllint.c I really don't think it's a library issue it's only used by CLI tools front end. For performance analysis I usually do top down, i.e. run and then check the majors offenders for said run. Daniel -- Daniel Veillard | Red Hat Desktop team http://redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org http://mail.gnome.org/mailman/listinfo/xml
Re: [xml] libxml2-2.6.18 on freebsd
Thanks for you help with this, is there anyway I could apply an edit to the *.c files to push this through the compiler ?. I have the problem that im about 1 miles away from the server this week, which means I cant do any major work. If I can get this running, I know I can rebuild it properly next week. I have mailed the bsd lists to find out if there is a way to resync the libaries or do anything else os related to bring this back online. I tested gcc as mentioned the hello world app runs and compiles without any errors. Thanks again for you help Alex On Tue, 15 Mar 2005 16:06:51 -0500 Daniel Veillard [EMAIL PROTECTED] wrote: On Tue, Mar 15, 2005 at 03:58:14PM -0500, Liam R. E. Quin wrote: On Tue, 2005-03-15 at 15:49 -0500, Daniel Veillard wrote: On Tue, Mar 15, 2005 at 12:29:42PM +, Alex Shaw wrote: [...] ../../.libs/libxml2.so: undefined reference to `__signbit' paphio:~/XML - grep __signbit *.c paphio:~/XML - grep __signbit *.c include/libxml/*.h paphio:~/XML - Well, you should search for _signbit or signbit, since the compiler may have prepended the _ for a static/private variable. there is two __ and that's usually a convention when remapping a public library (libc in that case) symbol to an internal one or a macro in the system includes. The signbit() call is from trio the compatibility library (apparently the libc is missing some of the advanced function libxml2 needs or well that configure think it is needed). In this case signbit is for floating point portability for XPath. Daniel -- Daniel Veillard | Red Hat Desktop team http://redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org http://mail.gnome.org/mailman/listinfo/xml -- Alex Shaw Technical Manager BulletOnline www.bulletonline.com +44(0)2088343442 +44(0)7790744560 ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org http://mail.gnome.org/mailman/listinfo/xml
Re: [xml] libxml2-2.6.18 on freebsd
Im running 5.3, but one of the last things installed a couple of days ago was compat4x ... could this have had any effect ??, have also mailed the a bsd list to try and get more os specific help. THanks Alex On Tue, 15 Mar 2005 23:09:20 +0100 Aron Stansvik [EMAIL PROTECTED] wrote: On Tue, 15 Mar 2005 12:29:42 +, Alex Shaw [EMAIL PROTECTED] wrote: Hi, im trying to install libxml2-2.6.18 from the FreeBSD ports, there is a problem with the compile on the system i am using. I have tried several versions of libxml2 and they all return the same error, which means its probably not an issue involved with libxml, but I cant pin down where the error is coming from, or what is causing the problem to occur. I was hoping someone on this list would be able to point me in the direction of what is causing this. The error is: cc -O -pipe -pedantic -W -Wformat -Wunused -Wimplicit -Wreturn-type -Wswitch -Wcomment -Wtrigraphs -Wformat -Wchar-subscripts -Wuninitialized -Wparentheses -Wshadow -Wpointer-arith -Wcast-align -Wwrite-strings -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Winline -Wredundant-decls -o .libs/xpath1 xpath1.o -L/usr/local/lib ../../.libs/libxml2.so -lz -liconv -lm -Wl,--rpath -Wl,/usr/local/lib ../../.libs/libxml2.so: undefined reference to `__signbit' gmake[3]: *** [xpath1] Error 1 gmake[3]: Leaving directory `/usr/ports/textproc/libxml2/work/libxml2-2.6.18/doc/examples' gmake[2]: *** [all-recursive] Error 1 gmake[2]: Leaving directory `/usr/ports/textproc/libxml2/work/libxml2-2.6.18/doc' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/ports/textproc/libxml2/work/libxml2-2.6.18' gmake: *** [all] Error 2 *** Error code 2 I don't really know what your problem might be, and I don't have time to investigate, but I just wanted to say that I just installed 2.6.18 from ports on my 5.3 laptop. I see in the manpage for signbit that it's a macro added to the math library starting from version 5.1 of FreeBSD, are you running 4.x? Maybe it's a glitch and you should contact the port maintainer? Anyway, I don't think it's for this list. Best regards, Aron ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org http://mail.gnome.org/mailman/listinfo/xml -- Alex Shaw Technical Manager BulletOnline www.bulletonline.com +44(0)2088343442 +44(0)7790744560 ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org http://mail.gnome.org/mailman/listinfo/xml
Re: [xml] xmlParseFile with minimal library (solved)
-Original Message- From: Daniel Veillard [EMAIL PROTECTED] Subject: Re: [xml] xmlParseFile with minimal library On Tue, Mar 15, 2005 at 10:32:06AM -0500, Henry Bibb wrote: I am trying to build a minimal-sized libxml2 but need to use xmlParseFile. use the new xmlReadFile apis, not the old one xmlParseFile if you want to build with minimum code. xmllint compiles with just --with-minimum you probably don't need anything else for just parsing UTF-8 instances Daniel Thanks, Daniel, that did the trick! Henry Bibb ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org http://mail.gnome.org/mailman/listinfo/xml