libxmlplusplus-general — Open discusions about libXML++

[libxml++] [ libxmlplusplus-Patches-810606 ] Element::add_comment()

[SourceForge.net <no...@so...>]

Patches item #810606, was opened at 2003-09-22 13:44
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312999&aid=810606&group_id=12999

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dan Dennedy (ddennedy)
Assigned to: Nobody/Anonymous (nobody)
Summary: Element::add_comment()

Initial Comment:
Index: libxml++/nodes/element.cc

===================================================================

RCS file:

/cvsroot/libxmlplusplus/libxml++/libxml++/nodes/element.cc,v

retrieving revision 1.13

diff -u -p -r1.13 element.cc

--- libxml++/nodes/element.cc   19 Sep 2003 07:29:59

-0000      1.13

+++ libxml++/nodes/element.cc   22 Sep 2003 13:42:10 -0000

@@ -167,6 +167,16 @@ std::string

Element::get_namespace_uri_f

 }

  

  

+CommentNode* Element::add_comment(const std::string&

content)

+{

+  if(cobj()->type == XML_ELEMENT_NODE)

+  {

+     xmlNode* node =

xmlNewComment((xmlChar*)content.c_str());

+     xmlAddChild(cobj(), node);

+     return static_cast<CommentNode*>(node->_private);

+  }

+  return 0;

+}

  

  

 } //namespace xmlpp

Index: libxml++/nodes/element.h

===================================================================

RCS file:

/cvsroot/libxmlplusplus/libxml++/libxml++/nodes/element.h,v

retrieving revision 1.12

diff -u -p -r1.12 element.h

--- libxml++/nodes/element.h    19 Sep 2003 07:29:59

-0000      1.12

+++ libxml++/nodes/element.h    22 Sep 2003 13:42:10 -0000

@@ -67,6 +67,8 @@ public:

   void set_child_content(const std::string& content);

   bool has_content() const;

  

+  CommentNode* add_comment(const std::string& content);

+

 protected:

   std::string get_namespace_uri_for_prefix(const

std::string& ns_prefix) const;

 };



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312999&aid=810606&group_id=12999

Re: [libxml++] Release soon

[Christophe de V. <cde...@al...>]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,


Le Lundi 22 Septembre 2003 13:00, Ephraim Vider a =E9crit :
> Hi,
>
> not msvc related - but the dom_build example uses Element::add_attribute
> which no longer exists.

=46ixed. Thanks.

>
> otherwise it is fine.
>

Great. I'll do the release this afternoon.

Best Regards,

Christophe
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE/buAhB+sU3TyOQjARAh7RAJ9mw8BMRwJXe+ZoWeWkZ3Lbk+htoACg0wRN
Icl4EEf7HXtMq/o0uaW7wJ4=3D
=3DhczX
=2D----END PGP SIGNATURE-----

Re: [libxml++] Release soon

[Ephraim V. <ef...@ep...>]

Hi,

not msvc related - but the dom_build example uses Element::add_attribute
which no longer exists.

otherwise it is fine.

-eff

----- Original Message ----- 
From: "Christophe de VIENNE" <cde...@al...>
To: <lib...@li...>
Sent: Monday, September 22, 2003 11:27 AM
Subject: Re: [libxml++] Release soon


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

OK, thanks...

Le Lundi 22 Septembre 2003 12:23, Ephraim Vider a écrit :
> Will do later today,
> please hold on till I do
>
> thanks,
> -eff
>
> ----- Original Message -----
> From: "Christophe de VIENNE" <cde...@al...>
> To: <lib...@li...>
> Sent: Monday, September 22, 2003 10:38 AM
> Subject: Re: [libxml++] Release soon
>
>
> Hi,
>
> Could someone using msvc check if current CVS version works well before I
> do the release ?
>
> Thanks in advance,
>
>
> Christophe
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Libxmlplusplus-general mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libxmlplusplus-general
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Libxmlplusplus-general mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libxmlplusplus-general
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE/bsB8B+sU3TyOQjARAkWWAKCPOQLd10xTAlK3HZa8PvM12gVNAQCffxj1
N3AcDM1msIlo9uiCYRwheYQ=
=PESO
-----END PGP SIGNATURE-----



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Libxmlplusplus-general mailing list
Lib...@li...
https://lists.sourceforge.net/lists/listinfo/libxmlplusplus-general

Re: [libxml++] Release soon

[Christophe de V. <cde...@al...>]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

OK, thanks...

Le Lundi 22 Septembre 2003 12:23, Ephraim Vider a =E9crit :
> Will do later today,
> please hold on till I do
>
> thanks,
> -eff
>
> ----- Original Message -----
> From: "Christophe de VIENNE" <cde...@al...>
> To: <lib...@li...>
> Sent: Monday, September 22, 2003 10:38 AM
> Subject: Re: [libxml++] Release soon
>
>
> Hi,
>
> Could someone using msvc check if current CVS version works well before I
> do the release ?
>
> Thanks in advance,
>
>
> Christophe
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Libxmlplusplus-general mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libxmlplusplus-general
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Libxmlplusplus-general mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libxmlplusplus-general
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE/bsB8B+sU3TyOQjARAkWWAKCPOQLd10xTAlK3HZa8PvM12gVNAQCffxj1
N3AcDM1msIlo9uiCYRwheYQ=3D
=3DPESO
=2D----END PGP SIGNATURE-----

Re: [libxml++] Release soon

[Ephraim V. <ef...@ep...>]

Will do later today,
please hold on till I do

thanks,
-eff

----- Original Message ----- 
From: "Christophe de VIENNE" <cde...@al...>
To: <lib...@li...>
Sent: Monday, September 22, 2003 10:38 AM
Subject: Re: [libxml++] Release soon


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Could someone using msvc check if current CVS version works well before I do
the release ?

Thanks in advance,


Christophe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE/brUTB+sU3TyOQjARApkeAJ9C7Hzhel5HOQLBJNPPG+VnVr47mACeILSw
uDShHqQcWQZK4SGq3rUgcfQ=
=rLgM
-----END PGP SIGNATURE-----



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Libxmlplusplus-general mailing list
Lib...@li...
https://lists.sourceforge.net/lists/listinfo/libxmlplusplus-general

Re: [libxml++] Release soon

[Christophe de V. <cde...@al...>]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Could someone using msvc check if current CVS version works well before I d=
o=20
the release ?

Thanks in advance,


Christophe
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE/brUTB+sU3TyOQjARApkeAJ9C7Hzhel5HOQLBJNPPG+VnVr47mACeILSw
uDShHqQcWQZK4SGq3rUgcfQ=3D
=3DrLgM
=2D----END PGP SIGNATURE-----

[libxml++] Release soon

[Christophe de V. <cde...@al...>]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

I'd like to make a release very soon. The question is do we include or not =
the=20
namespace support ?
I think we should better leave it for the next one since it's not yet=20
finished.
Murray, would you mind reverting the patch so I can do the release (I can d=
o=20
it for you if you don't have time/possibility to do it).

Best regards,

Christophe
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/aLsXB+sU3TyOQjARAggXAKCSJuDGYh1U3xvRFqHGs1TkxL3vhQCg6W4D
9tuATAo/RxyOthk0sqXgOtA=3D
=3DlPgF
=2D----END PGP SIGNATURE-----

Re: [libxml++] [ libxmlplusplus-Patches-806083 ] call xmlInitParser() to avoid threading problems

[Christophe de V. <cde...@al...>]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Commited.

Thanks !

Christophe


Le Dimanche 14 Septembre 2003 19:22, SourceForge.net a =E9crit :
> Patches item #806083, was opened at 2003-09-14 19:22
> Message generated for change (Tracker Item Submitted) made by Item
> Submitter You can respond by visiting:
> https://sourceforge.net/tracker/?func=3Ddetail&atid=3D312999&aid=3D806083=
&group_i
>d=3D12999
>
> Category: None
> Group: None
> Status: Open
> Resolution: None
> Priority: 5
> Submitted By: Fredrik Arnerup (farnerup)
> Assigned to: Nobody/Anonymous (nobody)
> Summary: call xmlInitParser() to avoid threading problems
>
> Initial Comment:
> This is a patch for the problem described in bug 801604
>
> (segfault when running saxparser in separate thread).
>
> A call to xmlInitParser is made in Document::Init().
>
> This will make sure global data is initialized before
>
> starting any threads.
>
> ----------------------------------------------------------------------
>
> You can respond by visiting:
> https://sourceforge.net/tracker/?func=3Ddetail&atid=3D312999&aid=3D806083=
&group_i
>d=3D12999
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Libxmlplusplus-general mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libxmlplusplus-general
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE/ZWfYB+sU3TyOQjARAnAxAJ9Lj8VUHCgm4H0dU5c4WoWHwumMcwCdFdXm
ZlUWt30K1ICF4corlqdTBD4=3D
=3D5BZJ
=2D----END PGP SIGNATURE-----

[libxml++] [ libxmlplusplus-Patches-806083 ] call xmlInitParser() to avoid threading problems

[SourceForge.net <no...@so...>]

Patches item #806083, was opened at 2003-09-14 19:22
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312999&aid=806083&group_id=12999

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Fredrik Arnerup (farnerup)
Assigned to: Nobody/Anonymous (nobody)
Summary: call xmlInitParser() to avoid threading problems

Initial Comment:
This is a patch for the problem described in bug 801604

(segfault when running saxparser in separate thread).

A call to xmlInitParser is made in Document::Init().

This will make sure global data is initialized before

starting any threads.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312999&aid=806083&group_id=12999

Re: [[libxml++] [PATCH] clear_internal_subset()]

[Thomas J. <tho...@in...>]

> > I wanted to replace a dtd reference in a parsed document with a new one.
>
> Just
>
> > calling set_internal_subset doesn't work, libxml checks if we already
> > have
>
> at
>
> > dtd and breaks.
> >
> > So I wrote the clear_internal_subset function.
>
> Shouldn't set_internal_subset() do this automatically, without us adding a
> method? It sounds like a and_make_it_work() method - something that belongs
> in implementation instead of API.

This is what Daniel Veillard wrote to me on the libxml mailinglist:
(about freeing the DTD, but I guess the same is true if you try 
to change the DTD)

> All the refernces to the items defined in the DTD like entities
> will become dandling pointers to freed areas. Might work for a
> given application, but a very bad interface to expose in a library API.
> Changing the strings in the DTD sounds safer, but probably don't
> match what you expect. I would only allow this transformation as part
> of a saving mechanism to avoid the broken references problem

I'm still thinking about the best solution right now, creating an empty 
document and use importNode() is only the last option.

As I just want to validate against a given DTD, perhaps I could
implement a validateAgainstExternalDTD() function in libxml++.

Thomas

Re: [[libxml++] Thread safety?]

[Christophe de V. <cde...@al...>]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Le Dimanche 14 Septembre 2003 14:18, Fredrik Arnerup a =E9crit :
>
> xmlInitParser() should be called only once, and only by the main thread
> before any other libxml calls. The purpose is to initialize global data,
> which normally get initialized automatically when needed, but in a thread=
ed
> program, that might not be reliable, so you should call xmlInitParser()
> explicitly. It should therefore be safe to call it for any program.
>
> The problem is that libxml++ does not have a global init step (am I right=
?)
> and calling xmlInitParser() from each parser constructor is not the corre=
ct
> thing to do.

In fact there is a global init step that set up the callbacks for Node=20
instanciation. You'll find in document.cc.

>
> I see three options:
>
>   * Call xmlInitParser() from the constructor of some global static objec=
t.

I think it's the right solution, since this global static object already=20
exists (it's Document::Init).


Cheers,

Christophe
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/ZF47B+sU3TyOQjARAmReAKCOjuthTjyjqlpn1pKOBYm7TETm4wCeKXVz
pQ0xvWjR6uX0ZgfQVD986Gs=3D
=3D1UFp
=2D----END PGP SIGNATURE-----

Re: [Re: [libxml++] namespace support]

[Murray C. <mu...@us...>]

Dan Dennedy <da...@de...> wrote:
> Please review my third patch submitted to the tracker. If your review i=
s
> positive, let me know if you'd rather get a patch against cvs head to
> simplify the merge.

Thanks. I have done that now (I am back from holiday). It looks like we'l=
l get
a nice clear API eventually that even I can understand. I think it might =
need
a little more revision though, and that's good. Thanks again.


Murray Cumming
mu...@us...
www.murrayc.com

[libxml++] Thread safety?

[Fredrik A. <e9...@el...>]

Hello,

I posted a bug report (is anyone using the bug tracker?) about threading
problems:
http://sourceforge.net/tracker/index.php?func=detail&aid=801604&group_id=12999&atid=112999

I managed to resolve the problem by adding a call to xmlInitParser() in the
main() of my program as described here: http://xmlsoft.org/threads.html
It doesn't say if there is a reason not to call it in every program.

I couldn't find a call to that particular function anywhere in the libxml++
source. Is thread safety covered in some way I haven't noticed?

/Fredrik Arnerup

Re: [libxml++] [PATCH] clear_internal_subset()

[Christophe de V. <cde...@al...>]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Le Mardi 9 Septembre 2003 16:10, Thomas Jarosch a =E9crit :
> One other thing: Is there an easy way to get rid of the error output
> to stderr if a parser error occures (f.e. when I use binary garbage as
> input)?

I guess you're speaking about the output of libxml2 itself since as far as =
I=20
know there shouldn't be direct output done by libxml++. Well, this has to b=
e=20
investigated. I think this has been discussed on the libxml mailing-list=20
already. A search on xmlsolft site should give some hint.=20
If the solution is elegant (I mean is not a dirty hack), we could think abo=
ut=20
a wrapper in libxml++.

Cheers,

Christophe
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE/XfLrB+sU3TyOQjARApEGAJ48kO3gAnMfQMYOi7Tu45FRMzC/QACbBqKB
4sxVtfAUF4lAudZydortxns=3D
=3DEMeJ
=2D----END PGP SIGNATURE-----

Re: [libxml++] [PATCH] clear_internal_subset()

[Thomas J. <tho...@in...>]

>  - Why returning a bool ? I think only the post-condition of the function
> is important, which is always the same : no subset in the current document.
> If one needs to know if a subset was present before, then he should check
> it before. Otherwise if the absence of an internal subset is considered as
> an error, then it should throw an exception (I don't think so).

Ok, it can be removed.

>  - I don't know if the implementation is correct (I seems to me that yes
> but still). If nobody gives you a clear answer on this list, I'd suggest
> you to ask on the libxml list.

Hmm, looks like I have to try my luck there.

>  - I'd prefer you to use the patch manager next time. Thanks !

Ok, sorry, next time.

One other thing: Is there an easy way to get rid of the error output
to stderr if a parser error occures (f.e. when I use binary garbage as input)?

Cheers,
Thomas

Re: [libxml++] [PATCH] clear_internal_subset()

[Christophe de V. <cde...@al...>]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Thanks for the patch.

A few little comments :
 - Why returning a bool ? I think only the post-condition of the function i=
s=20
important, which is always the same : no subset in the current document. If=
=20
one needs to know if a subset was present before, then he should check it=20
before. Otherwise if the absence of an internal subset is considered as an=
=20
error, then it should throw an exception (I don't think so).
 - I don't know if the implementation is correct (I seems to me that yes bu=
t=20
still). If nobody gives you a clear answer on this list, I'd suggest you to=
=20
ask on the libxml list.
 - I'd prefer you to use the patch manager next time. Thanks !


Regards,

Christophe

Le Mardi 9 Septembre 2003 10:13, Thomas Jarosch a =E9crit :
> Hi,
>
> I wanted to replace a dtd reference in a parsed document with a new one.
> Just calling set_internal_subset doesn't work, libxml checks if we already
> have at dtd and breaks.
>
> So I wrote the clear_internal_subset function.
>
> But since I haven't done much libxml hacking yet, I'm not sure if I got a=
ll
> the node linking, referencing and memory allocating right. I would highly
> appreciate it if a libxml guru could take a look at it.
> Feel free to include this patch to libxml++.
>
> Kind regards,
> Thomas
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE/XZUxB+sU3TyOQjARAkypAKCJaVeKKv0tVRmRrwdYRhdtgIrWzACgrJvc
iFZIUDo7zL1/1W4QGHeCq34=3D
=3DJveW
=2D----END PGP SIGNATURE-----

[libxml++] [PATCH] clear_internal_subset()

[Thomas J. <tho...@in...>]

Hi,

I wanted to replace a dtd reference in a parsed document with a new one. Just 
calling set_internal_subset doesn't work, libxml checks if we already have at 
dtd and breaks.

So I wrote the clear_internal_subset function.

But since I haven't done much libxml hacking yet, I'm not sure if I got all 
the node linking, referencing and memory allocating right. I would highly 
appreciate it if a libxml guru could take a look at it.
Feel free to include this patch to libxml++.

Kind regards,
Thomas

Re: [libxml++] libxml++ problem

[tim <ti...@st...>]

On Wed, 3 Sep 2003 10:13, you wrote:
> Hi Guys
>
> I am writting a c++ app and need xml support so i thought i would give
> libxml++ a try. Anyways i can not get anything to compile, i am using
> Debian 3.0r1 I am using kdevelop 2.1. I tried a few of the examples tha=
t
> comes with libxml++ but none of them compile for eg (import node exampl=
e)
>
snip

ooops sorry guys that last error message was the wrong one :-(
here is the correct one: the last one was with "cerr << "Caught exception=
 "=20
<< e.what() << endl;" commented out.

*************************************************************************=
********

make  all-recursive
make[1]: Entering directory `/root/test'
Making all in test
make[2]: Entering directory `/root/test/test'
c++ -DHAVE_CONFIG_H -I. -I. -I..     -O2 -O0 -g3 -Wall -fno-exceptions=20
-fno-check-new  -c main.cpp
main.cpp: In function `int main(int, char **)':
main.cpp:32: exception handling disabled, use -fexceptions to enable
main.cpp:47: no matching function for call to `xmlpp::Element::import_nod=
e=20
(xmlpp::Node *&)'
main.cpp:50: no matching function for call to=20
`xmlpp::Document::write_to_string_formatted ()'
main.cpp:55: `e' undeclared (first use this function)
main.cpp:55: (Each undeclared identifier is reported only once
main.cpp:55: for each function it appears in.)
make[2]: *** [main.o] Error 1
make[2]: Leaving directory `/root/test/test'
make[1]: Leaving directory `/root/test'
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive-am] Error 2
*** failed ***
*************************************************************************=
******************

Tim

[libxml++] libxml++ problem

[tim <ti...@st...>]

Hi Guys

I am writting a c++ app and need xml support so i thought i would give=20
libxml++ a try. Anyways i can not get anything to compile, i am using Deb=
ian=20
3.0r1 I am using kdevelop 2.1. I tried a few of the examples that comes w=
ith=20
libxml++ but none of them compile for eg (import node example)

#include <iostream>
#include <stdexcept>
#include <string>
#include <cstdlib>
#include <libxml++/libxml++.h>

using namespace xmlpp;
using namespace std;

int main (int argc, char *argv[]){
  try {
    DomParser example1("example1.xml");
    DomParser example2("example2.xml");

    Document *doc1 =3D example1.get_document();
    Document *doc2 =3D example2.get_document();

    Element *root1 =3D doc1->get_root_node();
    Element *root2 =3D doc2->get_root_node();

    // find the first "child" element in example2
    Node::NodeList child_list =3D root2->get_children("child");
    Node *node_to_add =3D child_list.front();

    // import the node under the root element (recursive is default)
    root1->import_node(node_to_add);

    // print out the new doc1
    string doc1_string =3D doc1->write_to_string_formatted();
    cout << doc1_string;
    return EXIT_SUCCESS;
  }
  catch (std::exception &e){
    cerr << "Caught exception " << e.what() << endl;
    return EXIT_FAILURE;
  }
}

i get the following errors:
make  all-recursive
make[1]: Entering directory `/root/test'
Making all in test
make[2]: Entering directory `/root/test/test'
c++ -DHAVE_CONFIG_H -I. -I. -I..     -O2 -O0 -g3 -Wall -fno-exceptions=20
-fno-check-new  -c main.cpp
main.cpp: In function `int main(int, char **)':
main.cpp:32: exception handling disabled, use -fexceptions to enable
main.cpp:47: no matching function for call to `xmlpp::Element::import_nod=
e=20
(xmlpp::Node *&)'
main.cpp:50: no matching function for call to=20
`xmlpp::Document::write_to_string_formatted ()'
make[2]: *** [main.o] Error 1
make[2]: Leaving directory `/root/test/test'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/root/test'
make: *** [all-recursive-am] Error 2
*** failed ***

i am pretty sure it's all installed properly because if i try and compile=
=20
with just #include <libxml++/libxml++.h> and nothing in the int main() it=
=20
doesn't complain that it can't find libxml++.h. I have also tried the=20
examples on Mandrake 9.1 and get i get the same errors. I have tried the=20
other examples and they all fail too. What on earth am i doing wrong??

Tim

P.S
Let me know if i haven't given enough information or didn't explain mysel=
f to=20
well ;-)

[libxml++] [ libxmlplusplus-Patches-797605 ] support for namespaces

[SourceForge.net <no...@so...>]

Patches item #797605, was opened at 2003-08-29 23:44
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312999&aid=797605&group_id=12999

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dan Dennedy (ddennedy)
Assigned to: Nobody/Anonymous (nobody)
Summary: support for namespaces

Initial Comment:
This tarball includes a patch to add support for XML

Namespaces.

The dom_build example is modified to show usage of some

of the new Namespace features.



The patch also adds the ability to add comment nodes to

an element.



Finally, the tarball includes the files for a new

example that shows how to build a custom dom by

inheriting libxml++ and using the SAX parser.



+-DRD-+



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312999&aid=797605&group_id=12999

Re: [libxml++] [patch] Namespace class and custom_dom example

[Christophe de V. <cde...@al...>]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Le Vendredi 29 Ao=FBt 2003 22:13, Dan Dennedy a =E9crit :
> Sorry for the delay, my working copy is ready;

great !

> I just haven't had time
> to generate a clean patch. Do you know a simple way to get a cvs diff
> that contains a new directory with files? If you don't know immediately,
> would you mind my including the new example and the cvs patch in a
> tarball?
>

no


Cheers,

Christophe
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/T7dzB+sU3TyOQjARAsoGAJ0fwSwotR0s0QTXhmXGWCxuN6vmDwCfTs/M
C/QIBpODjzxTtNQsORVdF2A=3D
=3DnNgO
=2D----END PGP SIGNATURE-----

RE: [libxml++] [patch] Namespace class and custom_dom example

[Dan D. <da...@de...>]

Sorry for the delay, my working copy is ready; I just haven't had time
to generate a clean patch. Do you know a simple way to get a cvs diff
that contains a new directory with files? If you don't know immediately,
would you mind my including the new example and the cvs patch in a
tarball?

Re: [libxml++] Re: different behavior on solaris/x86 and linux/x86 of Document::create_root_node?

[Stefan S. <se...@sy...>]

Christophe de VIENNE wrote:

>>>The fact that this mechanism is so fragil and not very portable
>>>(or so it seems) made me change the approach on my own libxml2
>>>wrapper...
>>
>>_If_ this is the problem, and there is no simple solution, then maybe we
>>need an xmlpp::initialize() function instead.
> 
> 
> This suggest that with the same compiler a static instance of a class is 
> instanciated or not depending on the platform : quite odd.
> I would be very surprised if it is the case.

It's not just the compiler, as there is a complex interaction between
compiler, linker, and loader. There is quite a bit of things that can go
wrong. In particular with dynamically loadable objects.

Regards,
		Stefan

[libxml++] different behavior on solaris/x86 and linux/x86 of Document::create_root_node?

[Tim F. <ti...@tr...>]

i wrote a short program:
#include <iostream>

#include <libxml++/libxml++.h>

using namespace std;
using namespace xmlpp;

main()
{
try {
     xmlpp::Document document;
     xmlpp::Node* nodeRoot = document.create_root_node("exampleroot");
     cout << nodeRoot << endl;
} catch(const std::exception& ex) {
   cout << "Exception \"" << ex.what() << "\"" << endl;
}


which on my solaris x86 box cout's 0, and on linux cout's a valid 
address.  both platforms are using gcc-3.2.3.  has anyone else run into 
this?

here is the solaris/x86 ldd:
	libxml++-0.1.so.10 =>	 /opt/Gcc3/gnome/2.2/lib/libxml++-0.1.so.10
	libxml2.so.2 =>	 /opt/Gcc3/lib/libxml2.so.2
	libz.so =>	 /opt/Gcc3/lib/libz.so
	libpthread.so.1 =>	 /usr/lib/libpthread.so.1
	libiconv.so.2 =>	 /opt/Gcc3/lib/libiconv.so.2
	libsocket.so.1 =>	 /usr/lib/libsocket.so.1
	libnsl.so.1 =>	 /usr/lib/libnsl.so.1
	libstdc++.so.5 =>	 /opt/Gcc3/lib/libstdc++.so.5
	libm.so.1 =>	 /usr/lib/libm.so.1
	libgcc_s.so.1 =>	 /opt/Gcc3/lib/libgcc_s.so.1
	libc.so.1 =>	 /usr/lib/libc.so.1
	libintl.so.2 =>	 /opt/Gcc3/lib/libintl.so.2
	libdl.so.1 =>	 /usr/lib/libdl.so.1
	libmp.so.2 =>	 /usr/lib/libmp.so.2
	libthread.so.1 =>	 /usr/lib/libthread.so.1

and the linux/x86 ldd:
	libxml++-0.1.so.10 => /usr/lib/libxml++-0.1.so.10 (0x40025000)
	libxml2.so.2 => /usr/lib/libxml2.so.2 (0x4003a000)
	libz.so.1 => /usr/lib/libz.so.1 (0x40132000)
	libpthread.so.0 => /lib/libpthread.so.0 (0x40143000)
	libstdc++.so.5 => 
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/libstdc++.so.5 (0x40193000)
	libm.so.6 => /lib/libm.so.6 (0x40246000)
	libgcc_s.so.1 => /usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/libgcc_s.so.1 
(0x40268000)
	libc.so.6 => /lib/libc.so.6 (0x40271000)
	/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

thanks!
-tim

[libxml++] Re: different behavior on solaris/x86 and linux/x86 of Document::create_root_node?

[Tim F. <ti...@tr...>]

sorry, i forgot to mention, libxml++-0.24, libxml2-2.5.8.

-tim

Tim Flechtner wrote:
> i wrote a short program:
> #include <iostream>
> 
> #include <libxml++/libxml++.h>
> 
> using namespace std;
> using namespace xmlpp;
> 
> main()
> {
> try {
>     xmlpp::Document document;
>     xmlpp::Node* nodeRoot = document.create_root_node("exampleroot");
>     cout << nodeRoot << endl;
> } catch(const std::exception& ex) {
>   cout << "Exception \"" << ex.what() << "\"" << endl;
> }
> 
> 
> which on my solaris x86 box cout's 0, and on linux cout's a valid 
> address.  both platforms are using gcc-3.2.3.  has anyone else run into 
> this?
> 
> here is the solaris/x86 ldd:
>     libxml++-0.1.so.10 =>     /opt/Gcc3/gnome/2.2/lib/libxml++-0.1.so.10
>     libxml2.so.2 =>     /opt/Gcc3/lib/libxml2.so.2
>     libz.so =>     /opt/Gcc3/lib/libz.so
>     libpthread.so.1 =>     /usr/lib/libpthread.so.1
>     libiconv.so.2 =>     /opt/Gcc3/lib/libiconv.so.2
>     libsocket.so.1 =>     /usr/lib/libsocket.so.1
>     libnsl.so.1 =>     /usr/lib/libnsl.so.1
>     libstdc++.so.5 =>     /opt/Gcc3/lib/libstdc++.so.5
>     libm.so.1 =>     /usr/lib/libm.so.1
>     libgcc_s.so.1 =>     /opt/Gcc3/lib/libgcc_s.so.1
>     libc.so.1 =>     /usr/lib/libc.so.1
>     libintl.so.2 =>     /opt/Gcc3/lib/libintl.so.2
>     libdl.so.1 =>     /usr/lib/libdl.so.1
>     libmp.so.2 =>     /usr/lib/libmp.so.2
>     libthread.so.1 =>     /usr/lib/libthread.so.1
> 
> and the linux/x86 ldd:
>     libxml++-0.1.so.10 => /usr/lib/libxml++-0.1.so.10 (0x40025000)
>     libxml2.so.2 => /usr/lib/libxml2.so.2 (0x4003a000)
>     libz.so.1 => /usr/lib/libz.so.1 (0x40132000)
>     libpthread.so.0 => /lib/libpthread.so.0 (0x40143000)
>     libstdc++.so.5 => 
> /usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/libstdc++.so.5 (0x40193000)
>     libm.so.6 => /lib/libm.so.6 (0x40246000)
>     libgcc_s.so.1 => 
> /usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/libgcc_s.so.1 (0x40268000)
>     libc.so.6 => /lib/libc.so.6 (0x40271000)
>     /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
> 
> thanks!
> -tim
>