From sb at dod.no Fri Sep 3 07:34:14 2004 From: sb at dod.no (Steinar Bang) Date: Fri Sep 3 07:34:19 2004 Subject: [Expat-discuss] Re: Conflict with two expat shared libraries References: <871xhpajm5.fsf@dod.no> <002101c48e3d$3bc7b6f0$0300a8c0@karlglen188> Message-ID: <87brgnykyx.fsf@dod.no> >>>>> "Karl Waclawek" : > You can also load the UTF-16 version of Expat dynamically using > dlopen() and dlsym(). Thanx for the pointer! For me, since I'm using Qt, it would be even simpler to use the QLibrary class: http://doc.trolltech.com/3.3/qlibrary.html But either way, I would have to make changes to the code itself, and if I don't decide to go this way on Win32 as well (where it isn't neccessary), I'll get a lot of #ifdefs in the code. I was sort of hoping there was a way to achive the effect of dlsym() in static linking, through flags given to the linker. I've been reading the ld() man page some, but I haven't seen anything I understand, that points to this. So I'm still pondering the approach to take. Thanx! - Steinar From karl at waclawek.net Fri Sep 3 17:15:33 2004 From: karl at waclawek.net (Karl Waclawek) Date: Fri Sep 3 17:15:41 2004 Subject: [Expat-discuss] Re: Conflict with two expat shared libraries References: <871xhpajm5.fsf@dod.no><002101c48e3d$3bc7b6f0$0300a8c0@karlglen188> <87brgnykyx.fsf@dod.no> Message-ID: <000f01c491c8$dba0c610$9e539696@citkwaclaww2k> ----- Original Message ----- From: "Steinar Bang" To: Sent: Friday, September 03, 2004 1:34 AM Subject: [Expat-discuss] Re: Conflict with two expat shared libraries > >>>>> "Karl Waclawek" : > > > You can also load the UTF-16 version of Expat dynamically using > > dlopen() and dlsym(). > > Thanx for the pointer! For me, since I'm using Qt, it would be even > simpler to use the QLibrary class: > http://doc.trolltech.com/3.3/qlibrary.html That looks cool! > But either way, I would have to make changes to the code itself, and > if I don't decide to go this way on Win32 as well (where it isn't > neccessary), I'll get a lot of #ifdefs in the code. > > I was sort of hoping there was a way to achive the effect of dlsym() > in static linking, through flags given to the linker. I've been > reading the ld() man page some, but I haven't seen anything I > understand, that points to this. > > So I'm still pondering the approach to take. Please let us know what you come up with. Your problem is likely not unique. Regards, Karl From abra9823 at mail.usyd.edu.au Sat Sep 4 14:53:18 2004 From: abra9823 at mail.usyd.edu.au (Ajay) Date: Sat Sep 4 14:53:23 2004 Subject: [Expat-discuss] compiling for winCE Message-ID: <1094302398.4139babe1d382@www-mail.usyd.edu.au> hi! has anyone done this? i am trying to compile using embedded visual c++. the build process works fine with visual c++ 6 but with evc i get the error C:\hons\pocketpc\expat\xmltok\xmltok_ns.c(1) : error C2143: syntax error : missing '{' before '*' C:\hons\pocketpc\expat\xmltok\xmltok_ns.c(1) : error C2091: function returns function C:\hons\pocketpc\expat\xmltok\xmltok_ns.c(3) : warning C4013: 'ns' undefined; assuming extern returning int .... the errors start at - const ENCODING *NS(XmlGetUtf8InternalEncoding)(void) { return &ns(internal_utf8_encoding).enc; } what i have done is, similar to vc++ 6, created a new project in evc and have added the same .c files and .h fies to source files and header files respectively. what am i doing wrong/ thanks cheers ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From coreybrenner at yahoo.com Sun Sep 5 21:36:25 2004 From: coreybrenner at yahoo.com (Corey Brenner) Date: Mon Sep 6 00:28:42 2004 Subject: [Expat-discuss] User memory pool management -- patch and description. Message-ID: <20040905193625.81147.qmail@web13125.mail.yahoo.com> Hi, In the course of writing some software for myself, I have stumbled on the need to have expat allocate and use memory from a specified pool, using specialized routines of my own device. I could have used the XML_Memory_Handling_Suite setup as is, but for the fact that, on different occasions, the pools (and, indeed, the allocators) could be different, and I wanted them to be able to be swapped out at runtime. For instance, I have a couple of heap managers: typedef int (*memf) (int, void*, size_t, void*); int mem1 (int, void*, size_t, void* pool); int mem2 (int, void*, size_t, void* pool); and a couple of different pools: void* pool1; void* pool2; I have a wrapper API atop expat which takes the heap manager function and a pool pointer to perform its magic: int xml_explode (memf, void* pool, doc*, char*, int); If I set up a structure, then, which contains all the relevant information within this wrapper, I can use the function and pool I pass: struct poolwrap { memf func; void* pool; int err; }; Additionally, I write a few simple wrappers which dispatch calls through to the heap managers given: void* my_malloc (size_t size, void* pd) { struct poolwrap* w = (struct poolwrap*) pd; void* p = NULL; w->err = w->func(BUFFER, size, &p, w->pool); return p; } void* my_realloc (void* p, size_t size, void* pd) { struct poolwrap* w = (struct poolwrap*) pd; w->err = w->func(RESIZE, size, &p, w->pool); return p; } void my_free (void* p, void* pd) { struct poolwrap* w = (struct poolwrap*) pd; w->err = w->func(RETURN, 0, &p, w->pool); } Now, though, I need support in expat for using these functions and pools: int xml_explode (memf f, void* p, ...) { struct poolwrap w; /* expanded expat memsuite structure */ XML_Memory_Handling_Suite ms = { /* malloc_fcn */ NULL, /* realloc_fcn */ NULL, /* free_fcn */ NULL, /* pool_malloc_fcn */ my_malloc, /* pool_realloc_fcn */ my_realloc, /* pool_free_fcn */ my_free, /* pool */ &w }; XML_Parser p; /* set up allocators at runtime */ w.func = f; w.pool = p; w.err = 0; /* go! */ p = XML_ParserCreate_MM(NULL, &ms, NULL); if (!p) { die(); } ... } The attached patch (against current CVS) implements the expanded XML_Memory_Handling_Suite structure, and its use in lib/xmlparse.c. Additionally, doc/reference.html is updated to show the addition and describe its use. The expanded structure, due to the way expat's data structures are laid out, should not affect older programs as they link against the new library. This /should/ be a drop-in replacement not even requiring a re-link for programs which don't use this function- ality. Please direct comments to my email address. Thanks! --Corey __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail -------------- next part -------------- Index: doc/reference.html =================================================================== RCS file: /cvsroot/expat/expat/doc/reference.html,v retrieving revision 1.61 diff -r1.61 reference.html 923a924,927 > void *(XMLCALL *pool_malloc_fcn)(size_t size, void *pool); > void *(XMLCALL *pool_realloc_fcn)(void *ptr, size_t size, void *pool); > void (XMLCALL *pool_free_fcn)(void *ptr, void *pool); > void *pool; 932a937,943 >

Note that the pool allocation routines will not be called if the > non-pool routines are provided. In order to use the pool management > routines, set the first three fields to NULL. Use one set of routines, > or the other, but not both. Do not mix them, either, or bad tidings > will likely befall you. The pool routines accept the user pool pointer > set into the structure as their last argument, so user pool management > may be performed on a per-parser basis.

Index: lib/expat.h =================================================================== RCS file: /cvsroot/expat/expat/lib/expat.h,v retrieving revision 1.71 diff -r1.71 expat.h 195a196,199 > void *(*pool_malloc_fcn)(size_t size, void *pool); > void *(*pool_realloc_fcn)(void *ptr, size_t size, void *pool); > void (*pool_free_fcn)(void *ptr, void *pool); > void *pool; Index: lib/xmlparse.c =================================================================== RCS file: /cvsroot/expat/expat/lib/xmlparse.c,v retrieving revision 1.137 diff -r1.137 xmlparse.c 545,547c545,556 < #define MALLOC(s) (parser->m_mem.malloc_fcn((s))) < #define REALLOC(p,s) (parser->m_mem.realloc_fcn((p),(s))) < #define FREE(p) (parser->m_mem.free_fcn((p))) --- > #define MALLOC(s) \ > ((parser->m_mem.malloc_fcn) \ > ? parser->m_mem.malloc_fcn((s)) \ > : parser->m_mem.pool_malloc_fcn((s), parser->m_mem.pool)) > #define REALLOC(p,s) \ > ((parser->m_mem.realloc_fcn) \ > ? parser->m_mem.realloc_fcn((p),(s)) \ > : parser->m_mem.pool_realloc_fcn((p),(s),parser->m_mem.pool)) > #define FREE(p) \ > ((parser->m_mem.free_fcn) \ > ? parser->m_mem.free_fcn((p)) \ > : parser->m_mem.pool_free_fcn((p), parser->m_mem.pool)) 701c710,713 < memsuite->malloc_fcn(sizeof(struct XML_ParserStruct)); --- > ((memsuite->malloc_fcn) > ? memsuite->malloc_fcn(sizeof(struct XML_ParserStruct)) > : memsuite->pool_malloc_fcn(sizeof(struct XML_ParserStruct), > memsuite->pool)); 706a719,722 > mtemp->pool_malloc_fcn = memsuite->pool_malloc_fcn; > mtemp->pool_realloc_fcn = memsuite->pool_realloc_fcn; > mtemp->pool_free_fcn = memsuite->pool_free_fcn; > mtemp->pool = memsuite->pool; 716a733,736 > mtemp->pool_malloc_fcn = NULL; > mtemp->pool_realloc_fcn = NULL; > mtemp->pool_free_fcn = NULL; > mtemp->pool = NULL; 5431c5451,5453 < DTD *p = (DTD *)ms->malloc_fcn(sizeof(DTD)); --- > DTD *p = (DTD *) ((ms->malloc_fcn) > ? ms->malloc_fcn(sizeof(DTD)) > : ms->pool_malloc_fcn(sizeof(DTD), ms->pool)); 5470,5471c5492,5498 < if (e->allocDefaultAtts != 0) < ms->free_fcn(e->defaultAtts); --- > > if (e->allocDefaultAtts != 0) { > if (ms->free_fcn) > ms->free_fcn(e->defaultAtts); > else > ms->pool_free_fcn(e->defaultAtts, ms->pool); > } 5488c5515,5522 < ms->free_fcn(p->scaffIndex); --- > if (ms->free_fcn) { > ms->free_fcn(p->scaffIndex); > ms->free_fcn(p->scaffold); > } > else { > ms->pool_free_fcn(p->scaffIndex, ms->pool); > ms->pool_free_fcn(p->scaffold, ms->pool); > } 5490d5523 < ms->free_fcn(p->scaffold); 5512,5513c5545,5550 < if (e->allocDefaultAtts != 0) < ms->free_fcn(e->defaultAtts); --- > if (e->allocDefaultAtts != 0) { > if (ms->free_fcn) > ms->free_fcn(e->defaultAtts); > else > ms->pool_free_fcn(e->defaultAtts, ms->pool); > } 5525,5526c5562,5569 < ms->free_fcn(p->scaffIndex); < ms->free_fcn(p->scaffold); --- > if (ms->free_fcn) { > ms->free_fcn(p->scaffIndex); > ms->free_fcn(p->scaffold); > } > else { > ms->pool_free_fcn(p->scaffIndex, ms->pool); > ms->pool_free_fcn(p->scaffold, ms->pool); > } 5528c5571,5574 < ms->free_fcn(p); --- > if (ms->free_fcn) > ms->free_fcn(p); > else > ms->pool_free_fcn(p, ms->pool); 5607c5653,5656 < ms->malloc_fcn(oldE->nDefaultAtts * sizeof(DEFAULT_ATTRIBUTE)); --- > ((ms->malloc_fcn) > ? ms->malloc_fcn(oldE->nDefaultAtts * sizeof(DEFAULT_ATTRIBUTE)) > : ms->pool_malloc_fcn(oldE->nDefaultAtts * sizeof(DEFAULT_ATTRIBUTE), > ms->pool)); 5609c5658,5661 < ms->free_fcn(newE); --- > if (ms->free_fcn) > ms->free_fcn(newE); > else > ms->pool_free_fcn(newE, ms->pool); 5762c5814,5817 < table->v = (NAMED **)table->mem->malloc_fcn(tsize); --- > table->v = (NAMED **) > ((table->mem->malloc_fcn) > ? table->mem->malloc_fcn(tsize) > : table->mem->pool_malloc_fcn(tsize, table->mem->pool)); 5791c5846,5849 < NAMED **newV = (NAMED **)table->mem->malloc_fcn(tsize); --- > NAMED **newV = (NAMED **) > ((table->mem->malloc_fcn) > ? table->mem->malloc_fcn(tsize) > : table->mem->pool_malloc_fcn(tsize, table->mem->pool)); 5807c5865,5868 < table->mem->free_fcn(table->v); --- > if (table->mem->free_fcn) > table->mem->free_fcn(table->v); > else > table->mem->pool_free_fcn(table->v, table->mem->pool); 5820c5881,5884 < table->v[i] = (NAMED *)table->mem->malloc_fcn(createSize); --- > table->v[i] = (NAMED *) > ((table->mem->malloc_fcn) > ? table->mem->malloc_fcn(createSize) > : table->mem->pool_malloc_fcn(createSize, table->mem->pool)); 5834c5898,5901 < table->mem->free_fcn(table->v[i]); --- > if (table->mem->free_fcn) > table->mem->free_fcn(table->v[i]); > else > table->mem->pool_free_fcn(table->v[i], table->mem->pool); 5845,5846c5912,5920 < table->mem->free_fcn(table->v[i]); < table->mem->free_fcn(table->v); --- > if (table->mem->free_fcn) > table->mem->free_fcn(table->v[i]); > else > table->mem->pool_free_fcn(table->v[i], table->mem->pool); > > if (table->mem->free_fcn) > table->mem->free_fcn(table->v); > else > table->mem->pool_free_fcn(table->v, table->mem->pool); 5914c5988,5991 < pool->mem->free_fcn(p); --- > if (pool->mem->free_fcn) > pool->mem->free_fcn(p); > else > pool->mem->pool_free_fcn(p, pool->mem->pool); 5920c5997,6000 < pool->mem->free_fcn(p); --- > if (pool->mem->free_fcn) > pool->mem->free_fcn(p); > else > pool->mem->pool_free_fcn(p, pool->mem->pool); 6019,6021c6099,6106 < pool->mem->realloc_fcn(pool->blocks, < (offsetof(BLOCK, s) < + blockSize * sizeof(XML_Char))); --- > ((pool->mem->realloc_fcn) > ? pool->mem->realloc_fcn(pool->blocks, > (offsetof(BLOCK, s) > + blockSize * sizeof(XML_Char))) > : pool->mem->pool_realloc_fcn(pool->blocks, > (offsetof(BLOCK, s) > + blockSize * sizeof(XML_Char)), > pool->mem->pool)); 6036,6037c6121,6127 < tem = (BLOCK *)pool->mem->malloc_fcn(offsetof(BLOCK, s) < + blockSize * sizeof(XML_Char)); --- > tem = (BLOCK *) > ((pool->mem->malloc_fcn) > ? pool->mem->malloc_fcn(offsetof(BLOCK, s) > + blockSize * sizeof(XML_Char)) > : pool->mem->pool_malloc_fcn(offsetof(BLOCK, s) > + blockSize + sizeof(XML_Char), > pool->mem->pool)); From armin.bauer at desscon.com Tue Sep 7 15:16:57 2004 From: armin.bauer at desscon.com (Armin Bauer) Date: Tue Sep 7 15:17:01 2004 Subject: [Expat-discuss] CRLF conversion question Message-ID: <1094563017.18161.4.camel@azrael> Hi, i dont know if this is the right list to ask or if expat is responsible for this bug. Sorry if its the wrong list. Im working on multisync, which uses syncml. i have to send VCARD data over syncml. A vcard looks like this: BEGIN:VCARD\r\n... It is stored in a cdata object and is then converted to wbxml. Somewhere along the conversion, the vcard gets crippled to BEGIN:VCARD\n... and im suspecting either expat or the wbxml library responsible for this :) Is this a known bug and is there anything i can do about this? Armin From fdrake at acm.org Tue Sep 7 15:44:32 2004 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Tue Sep 7 15:44:40 2004 Subject: [Expat-discuss] CRLF conversion question In-Reply-To: <1094563017.18161.4.camel@azrael> References: <1094563017.18161.4.camel@azrael> Message-ID: <200409070944.33021.fdrake@acm.org> On Tuesday 07 September 2004 09:16 am, Armin Bauer wrote: > Im working on multisync, which uses syncml. i have to send VCARD data > over syncml. A vcard looks like this: > > BEGIN:VCARD\r\n... ... > Is this a known bug and is there anything i can do about this? I would strongly suspect that this is related to Expat myself. Here's why. XML requires normalization of line-ened sequences to \n. There are ways to encode \r\n so that you get it back; the easiest is: BEGIN:VCARD \n I don't know anything about syncml, but if there's some way to encode binary data, that may be an option as well. -Fred -- Fred L. Drake, Jr. From armin.bauer at desscon.com Tue Sep 7 16:09:18 2004 From: armin.bauer at desscon.com (Armin Bauer) Date: Tue Sep 7 16:09:33 2004 Subject: [Expat-discuss] CRLF conversion question In-Reply-To: <200409070944.33021.fdrake@acm.org> References: <1094563017.18161.4.camel@azrael> <200409070944.33021.fdrake@acm.org> Message-ID: <1094566158.18333.26.camel@azrael> On Tue, 2004-09-07 at 15:44, Fred L. Drake, Jr. wrote: > On Tuesday 07 September 2004 09:16 am, Armin Bauer wrote: > > Im working on multisync, which uses syncml. i have to send VCARD data > > over syncml. A vcard looks like this: > > > > BEGIN:VCARD\r\n... > ... > > Is this a known bug and is there anything i can do about this? > > I would strongly suspect that this is related to Expat myself. Here's why. > > XML requires normalization of line-ened sequences to \n. There are ways to > encode \r\n so that you get it back; the easiest is: > > BEGIN:VCARD \n > > I don't know anything about syncml, but if there's some way to encode binary > data, that may be an option as well. > > > -Fred I suspect that this is a bug in the parser which manufactures the xml tree. the wbxml lib goes through the cdata which consist of a lot of nodes like this: WBXML Encoder> CDATA Begin WBXML Encoder> Text: WBXML Encoder> Text: < > WBXML Encoder> Text: WBXML Encoder> Text: < > But it should be only one node which holds all the cdata. By the way: the < > node holds a 0x0a. So i guess the parser just creates a node for every 0x0d it encounters even it is in the cdata. That doesnt sound right to me. The correct fix to this (if my assumptions are correct) would be to not parse the cdata into nodes but to leave it as is. BTW: the fix did not work. It was left as is. Armin From fdrake at acm.org Tue Sep 7 16:55:42 2004 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Tue Sep 7 16:55:52 2004 Subject: [Expat-discuss] CRLF conversion question In-Reply-To: <1094566158.18333.26.camel@azrael> References: <1094563017.18161.4.camel@azrael> <200409070944.33021.fdrake@acm.org> <1094566158.18333.26.camel@azrael> Message-ID: <200409071055.42294.fdrake@acm.org> On Tuesday 07 September 2004 10:09 am, Armin Bauer wrote: > I suspect that this is a bug in the parser which manufactures the xml > tree. I'm not convinced. > the wbxml lib goes through the cdata which consist of a lot of nodes > like this: > > WBXML Encoder> CDATA Begin > WBXML Encoder> Text: > WBXML Encoder> Text: < > > WBXML Encoder> Text: > WBXML Encoder> Text: < That seems like how Expat reports it. Most tree-builders normalize on input, though, so you would get just one text node. There may be a knob to twist; that depends on your tree-builder. If you're getting a DOM, you should be able to call .normalize() on the document to take care of this issue. > But it should be only one node which holds all the cdata. By the way: > the < > > > node holds a 0x0a. > > So i guess the parser just creates a node for every 0x0d it encounters > even it is in the cdata. That doesnt sound right to me. > > The correct fix to this (if my assumptions are correct) would be to not > parse the cdata into nodes but to leave it as is. It's not clear to me what this means. If CDATA marked sections are represented, it'll contain zero or more text nodes; this is expected of the DOM. I don't know what API your using, though (wbxml doesn't tell me anything, unfortunately), but the nodes look like what I'd expect as output events from Expat. Especially the normalized newlines coming through as a separate bit. > BTW: the fix did not work. It was left as is. Inside of CDATA marked sections, yes. -Fred -- Fred L. Drake, Jr. From armin.bauer at desscon.com Wed Sep 8 00:18:39 2004 From: armin.bauer at desscon.com (Armin Bauer) Date: Wed Sep 8 00:18:48 2004 Subject: [Expat-discuss] CRLF conversion question In-Reply-To: <200409071055.42294.fdrake@acm.org> References: <1094563017.18161.4.camel@azrael> <200409070944.33021.fdrake@acm.org> <1094566158.18333.26.camel@azrael> <200409071055.42294.fdrake@acm.org> Message-ID: <1094595519.24218.6.camel@azrael> On Tue, 2004-09-07 at 16:55, Fred L. Drake, Jr. wrote: > On Tuesday 07 September 2004 10:09 am, Armin Bauer wrote: > > I suspect that this is a bug in the parser which manufactures the xml > > tree. > > I'm not convinced. > > > the wbxml lib goes through the cdata which consist of a lot of nodes > > like this: > > > > WBXML Encoder> CDATA Begin > > WBXML Encoder> Text: > > WBXML Encoder> Text: < > > > > WBXML Encoder> Text: > > WBXML Encoder> Text: < > > That seems like how Expat reports it. Most tree-builders normalize on input, > though, so you would get just one text node. There may be a knob to twist; > that depends on your tree-builder. If you're getting a DOM, you should be > able to call .normalize() on the document to take care of this issue. > > > But it should be only one node which holds all the cdata. By the way: > > the < > > > > > node holds a 0x0a. > > > > So i guess the parser just creates a node for every 0x0d it encounters > > even it is in the cdata. That doesnt sound right to me. > > > > The correct fix to this (if my assumptions are correct) would be to not > > parse the cdata into nodes but to leave it as is. > > It's not clear to me what this means. If CDATA marked sections are > represented, it'll contain zero or more text nodes; this is expected of the > DOM. I don't know what API your using, though (wbxml doesn't tell me > anything, unfortunately), but the nodes look like what I'd expect as output > events from Expat. Especially the normalized newlines coming through as a > separate bit. > Sorry if its me being stupid but why do CDATA sections contain nodes at all? As far as my understanding goes the parser has not to touch the cdata section at all. So if the parser encounters something like this: wouldnt it be correct if it created exactly one text node containing all the text as is? At the moment it creates a lot of nodes for every line etc. wbxml is the library that converts syncml request to wap binary xml ( a form of conversion before it is send over gprs) :) > > BTW: the fix did not work. It was left as is. > > Inside of CDATA marked sections, yes. > > > -Fred From fdrake at acm.org Wed Sep 8 00:35:27 2004 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Wed Sep 8 00:35:38 2004 Subject: [Expat-discuss] CRLF conversion question In-Reply-To: <1094595519.24218.6.camel@azrael> References: <1094563017.18161.4.camel@azrael> <200409071055.42294.fdrake@acm.org> <1094595519.24218.6.camel@azrael> Message-ID: <200409071835.27377.fdrake@acm.org> On Tuesday 07 September 2004 06:18 pm, Armin Bauer wrote: > Sorry if its me being stupid but why do CDATA sections contain nodes at > all? As far as my understanding goes the parser has not to touch the > cdata section at all. The node structure is defined by whatever API is providing you with nodes (Expat isn't). If you're using a DOM with wbxml (or if wbxml is using a DOM internally), that's why nodes are used. Line-end normalization is required at all times, even inside CDATA marked sections. CDATA marked sections are not intended as an escape hatch for binary data. > wouldnt it be correct if it created exactly one text node containing all > the text as is? At the moment it creates a lot of nodes for every line > etc. What's correct depends on the API. If these are DOM nodes, then yes, that would be correct, but not required for correctness. The series of nodes would also be correct. That's a separate issue from line-end normalization. > wbxml is the library that converts syncml request to wap binary xml ( a > form of conversion before it is send over gprs) :) Cool, I guess. Is it this one? http://libwbxml.aymerick.com/ The tree described in the documentation looks *very* DOMish to me, though perhaps a little lighter than a full W3C DOM (hard to be heavier!). -Fred -- Fred L. Drake, Jr. From armin.bauer at desscon.com Thu Sep 9 14:31:54 2004 From: armin.bauer at desscon.com (Armin Bauer) Date: Thu Sep 9 14:32:04 2004 Subject: [Expat-discuss] CRLF conversion question In-Reply-To: <200409071835.27377.fdrake@acm.org> References: <1094563017.18161.4.camel@azrael> <200409071055.42294.fdrake@acm.org> <1094595519.24218.6.camel@azrael> <200409071835.27377.fdrake@acm.org> Message-ID: <1094733114.21807.15.camel@azrael> So what fix do you think would be best? I have a cdata section like this the lines are seperated by 0x0d 0x0a The tree builder make two text nodes out of every line: the first one hold the text of the line like: "VERSION:2.1" the second one holds a 0x0a the 0x0d is lost the tree is built by XML_Parse. The parser was created by XML_ParserCreate(NULL) the wbxml library later just concatenates these text nodes in the assumptions that they were not altered (Which is wrong since the 0x0d is lost) so could you give me an hint how to fix this? Armin On Wed, 2004-09-08 at 00:35, Fred L. Drake, Jr. wrote: > On Tuesday 07 September 2004 06:18 pm, Armin Bauer wrote: > > Sorry if its me being stupid but why do CDATA sections contain nodes at > > all? As far as my understanding goes the parser has not to touch the > > cdata section at all. > > The node structure is defined by whatever API is providing you with nodes > (Expat isn't). If you're using a DOM with wbxml (or if wbxml is using a DOM > internally), that's why nodes are used. > > Line-end normalization is required at all times, even inside CDATA marked > sections. CDATA marked sections are not intended as an escape hatch for > binary data. > > > wouldnt it be correct if it created exactly one text node containing all > > the text as is? At the moment it creates a lot of nodes for every line > > etc. > > What's correct depends on the API. If these are DOM nodes, then yes, that > would be correct, but not required for correctness. The series of nodes > would also be correct. That's a separate issue from line-end normalization. > > > wbxml is the library that converts syncml request to wap binary xml ( a > > form of conversion before it is send over gprs) :) > > Cool, I guess. Is it this one? > > http://libwbxml.aymerick.com/ > > The tree described in the documentation looks *very* DOMish to me, though > perhaps a little lighter than a full W3C DOM (hard to be heavier!). > > > -Fred From armin.bauer at desscon.com Thu Sep 9 14:55:17 2004 From: armin.bauer at desscon.com (Armin Bauer) Date: Thu Sep 9 14:55:35 2004 Subject: [Expat-discuss] CRLF conversion question In-Reply-To: <200409071835.27377.fdrake@acm.org> References: <1094563017.18161.4.camel@azrael> <200409071055.42294.fdrake@acm.org> <1094595519.24218.6.camel@azrael> <200409071835.27377.fdrake@acm.org> Message-ID: <1094734517.21807.20.camel@azrael> On Wed, 2004-09-08 at 00:35, Fred L. Drake, Jr. wrote: > On Tuesday 07 September 2004 06:18 pm, Armin Bauer wrote: > > Sorry if its me being stupid but why do CDATA sections contain nodes at > > all? As far as my understanding goes the parser has not to touch the > > cdata section at all. > > The node structure is defined by whatever API is providing you with nodes > (Expat isn't). If you're using a DOM with wbxml (or if wbxml is using a DOM > internally), that's why nodes are used. > > Line-end normalization is required at all times, even inside CDATA marked > sections. CDATA marked sections are not intended as an escape hatch for > binary data. > Thats true. But is not xml compliant to do line-end normalization in cdata sections. Definition of a cdata section: [18] CDSect ::= CDStart CData CDEnd[19] CDStart ::= '' Char*)) [21] CDEnd ::= ']]>' as taken from http://www.w3.org/TR/REC-xml/#sec-cdata-sect Notice the Char*. Char is defined as: Char ::= #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF] /* any Unicode character, excluding the surrogate blocks, FFFE, and FFFF. */ as taken from http://www.w3.org/TR/REC-xml/#NT-Char. And this clearly include 0x0a and 0x0d. So expat should never touch these characters. > > wouldnt it be correct if it created exactly one text node containing all > > the text as is? At the moment it creates a lot of nodes for every line > > etc. > > What's correct depends on the API. If these are DOM nodes, then yes, that > would be correct, but not required for correctness. The series of nodes > would also be correct. That's a separate issue from line-end normalization. > > > wbxml is the library that converts syncml request to wap binary xml ( a > > form of conversion before it is send over gprs) :) > > Cool, I guess. Is it this one? > > http://libwbxml.aymerick.com/ > > The tree described in the documentation looks *very* DOMish to me, though > perhaps a little lighter than a full W3C DOM (hard to be heavier!). > > > -Fred From karl at waclawek.net Thu Sep 9 15:10:00 2004 From: karl at waclawek.net (Karl Waclawek) Date: Thu Sep 9 15:10:07 2004 Subject: [Expat-discuss] CRLF conversion question References: <1094563017.18161.4.camel@azrael><200409071055.42294.fdrake@acm.org> <1094595519.24218.6.camel@azrael><200409071835.27377.fdrake@acm.org> <1094734517.21807.20.camel@azrael> Message-ID: <002201c4966e$5033fd90$9e539696@citkwaclaww2k> ----- Original Message ----- From: "Armin Bauer" Sent: Thursday, September 09, 2004 8:55 AM > On Wed, 2004-09-08 at 00:35, Fred L. Drake, Jr. wrote: > > On Tuesday 07 September 2004 06:18 pm, Armin Bauer wrote: > > > Sorry if its me being stupid but why do CDATA sections contain nodes at > > > all? As far as my understanding goes the parser has not to touch the > > > cdata section at all. > > > > The node structure is defined by whatever API is providing you with nodes > > (Expat isn't). If you're using a DOM with wbxml (or if wbxml is using a DOM > > internally), that's why nodes are used. > > > > Line-end normalization is required at all times, even inside CDATA marked > > sections. CDATA marked sections are not intended as an escape hatch for > > binary data. > > > > Thats true. But is not xml compliant to do line-end normalization in > cdata sections. > > Definition of a cdata section: > > [18] CDSect ::= CDStart CData > CDEnd[19] CDStart ::= ' [20] CData ::= (Char* - (Char* ']]>' Char*)) > [21] CDEnd ::= ']]>' > > as taken from http://www.w3.org/TR/REC-xml/#sec-cdata-sect > Notice the Char*. > > Char is defined as: > > Char ::= #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | > [#x10000-#x10FFFF] > /* any Unicode character, excluding the surrogate blocks, FFFE, and > FFFF. */ > > as taken from http://www.w3.org/TR/REC-xml/#NT-Char. And this clearly > include 0x0a and 0x0d. So expat should never touch these characters. But if you read this section, it becomes clear that it has to touch them (the important words are in upper case): 2.11 End-of-Line Handling XML parsed entities are often stored in computer files which, for editing convenience, are organized into lines. These lines are typically separated by some combination of the characters CARRIAGE RETURN (#xD) and LINE FEED (#xA). To simplify the tasks of applications, the XML processor MUST behave as if it normalized all line breaks in external parsed entities (including the document entity) ON INPUT, BEFORE PARSING, by translating both the two-character sequence #xD #xA and any #xD that is not followed by #xA to a single #xA character. Karl From karl at waclawek.net Thu Sep 9 15:18:27 2004 From: karl at waclawek.net (Karl Waclawek) Date: Thu Sep 9 15:18:36 2004 Subject: [Expat-discuss] CRLF conversion question References: <1094563017.18161.4.camel@azrael><200409071055.42294.fdrake@acm.org> <1094595519.24218.6.camel@azrael><200409071835.27377.fdrake@acm.org> <1094733114.21807.15.camel@azrael> Message-ID: <003601c4966f$7e6f0dc0$9e539696@citkwaclaww2k> ----- Original Message ----- From: "Armin Bauer" To: "Fred L. Drake, Jr." Cc: Sent: Thursday, September 09, 2004 8:31 AM Subject: Re: [Expat-discuss] CRLF conversion question > So what fix do you think would be best? > > I have a cdata section like this > > VERSION:2.1 > X-EVOLUTION-FILE-AS:Mike, Smith > FN:Smith Mike > N:Mike;Smith > TEL;PREF;WORK:+1 469 43220403 > EMAIL;INTERNET:mike.smith@yahoo.com > TITLE:Business Developer > UID:pas-id-413DC011000000B2 > END:VCARD]]> > > the lines are seperated by 0x0d 0x0a > The tree builder make two text nodes out of every line: > the first one hold the text of the line like: "VERSION:2.1" > the second one holds a 0x0a > the 0x0d is lost > > the tree is built by XML_Parse. The parser was created by > XML_ParserCreate(NULL) To be precise XML_Parse does not build a tree, this would rather be the function of the call-backs. > the wbxml library later just concatenates these text nodes in the > assumptions that they were not altered (Which is wrong since the 0x0d is > lost) > > so could you give me an hint how to fix this? Line breaks are reported by Expat as 0x0A, no matter what the input. So, depending on your platform, convert them back to the appropriate line break characters. Another option would be to Base64 encode your CDATA section. You may not even need a CDATA section then, and everything is preserved as if it were binary. Karl From armin.bauer at desscon.com Thu Sep 9 15:57:12 2004 From: armin.bauer at desscon.com (Armin Bauer) Date: Thu Sep 9 15:57:26 2004 Subject: [Expat-discuss] CRLF conversion question In-Reply-To: <003601c4966f$7e6f0dc0$9e539696@citkwaclaww2k> References: <1094563017.18161.4.camel@azrael> <200409071055.42294.fdrake@acm.org> <1094595519.24218.6.camel@azrael> <200409071835.27377.fdrake@acm.org> <1094733114.21807.15.camel@azrael> <003601c4966f$7e6f0dc0$9e539696@citkwaclaww2k> Message-ID: <1094738232.22259.19.camel@azrael> On Thu, 2004-09-09 at 15:18, Karl Waclawek wrote: > ----- Original Message ----- > From: "Armin Bauer" > To: "Fred L. Drake, Jr." > Cc: > Sent: Thursday, September 09, 2004 8:31 AM > Subject: Re: [Expat-discuss] CRLF conversion question > > > > So what fix do you think would be best? > > > > I have a cdata section like this > > > > > VERSION:2.1 > > X-EVOLUTION-FILE-AS:Mike, Smith > > FN:Smith Mike > > N:Mike;Smith > > TEL;PREF;WORK:+1 469 43220403 > > EMAIL;INTERNET:mike.smith@yahoo.com > > TITLE:Business Developer > > UID:pas-id-413DC011000000B2 > > END:VCARD]]> > > > > the lines are seperated by 0x0d 0x0a > > The tree builder make two text nodes out of every line: > > the first one hold the text of the line like: "VERSION:2.1" > > the second one holds a 0x0a > > the 0x0d is lost > > > > the tree is built by XML_Parse. The parser was created by > > XML_ParserCreate(NULL) > > To be precise XML_Parse does not build a tree, this > would rather be the function of the call-backs. > > > the wbxml library later just concatenates these text nodes in the > > assumptions that they were not altered (Which is wrong since the 0x0d is > > lost) > > > > so could you give me an hint how to fix this? > > Line breaks are reported by Expat as 0x0A, no matter what > the input. So, depending on your platform, convert them back > to the appropriate line break characters. Yes. That would be one option. The only problem is how the xml document is parsed. The vcard in the cdata section above is parsed into nodes like this: BEGIN:VCARD 0x0a VERSION:2.1 0x0a ... So... what would be the correct approach? Test if the text node == 0x0a and replace it with 0x0d 0x0a then? > > Another option would be to Base64 encode your CDATA section. > You may not even need a CDATA section then, and everything > is preserved as if it were binary. This wont work unfortunatly, since the wbxml library receives a syncml request (which is an xml document with a vcard in a cdata section). So to be able to convert the vcard to base64 the library would have to detect the CDATA section first... > > Karl > _______________________________________________ > Expat-discuss mailing list > Expat-discuss@libexpat.org > http://mail.libexpat.org/mailman/listinfo/expat-discuss From karl at waclawek.net Thu Sep 9 16:05:48 2004 From: karl at waclawek.net (Karl Waclawek) Date: Thu Sep 9 16:05:58 2004 Subject: [Expat-discuss] CRLF conversion question References: <1094563017.18161.4.camel@azrael> <200409071055.42294.fdrake@acm.org> <1094595519.24218.6.camel@azrael> <200409071835.27377.fdrake@acm.org> <1094733114.21807.15.camel@azrael> <003601c4966f$7e6f0dc0$9e539696@citkwaclaww2k> <1094738232.22259.19.camel@azrael> Message-ID: <007401c49676$1ba34a10$9e539696@citkwaclaww2k> ----- Original Message ----- From: "Armin Bauer" Sent: Thursday, September 09, 2004 9:57 AM > > Line breaks are reported by Expat as 0x0A, no matter what > > the input. So, depending on your platform, convert them back > > to the appropriate line break characters. > > Yes. That would be one option. The only problem is how the xml document > is parsed. The vcard in the cdata section above is parsed into nodes > like this: > > > BEGIN:VCARD > 0x0a > VERSION:2.1 > 0x0a > ... > > > So... what would be the correct approach? Test if the text node == 0x0a > and replace it with 0x0d 0x0a then? Yes, that looks good to me. Now, if you ever wanted to port your app to Linux, you should make the conversion platform dependent. > > Another option would be to Base64 encode your CDATA section. > > You may not even need a CDATA section then, and everything > > is preserved as if it were binary. > > This wont work unfortunatly, since the wbxml library receives a syncml > request (which is an xml document with a vcard in a cdata section). So > to be able to convert the vcard to base64 the library would have to > detect the CDATA section first... OK, I thought you had control over the encoding of the vcard. Karl From fdrake at acm.org Thu Sep 9 16:15:16 2004 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Thu Sep 9 16:15:28 2004 Subject: [Expat-discuss] CRLF conversion question In-Reply-To: <007401c49676$1ba34a10$9e539696@citkwaclaww2k> References: <1094563017.18161.4.camel@azrael> <1094738232.22259.19.camel@azrael> <007401c49676$1ba34a10$9e539696@citkwaclaww2k> Message-ID: <200409091015.16834.fdrake@acm.org> On Thursday 09 September 2004 10:05 am, Karl Waclawek wrote: > Now, if you ever wanted to port your app to Linux, you should > make the conversion platform dependent. That depends on the vCard specification. If it really says CRLF, that's what it should be. -Fred -- Fred L. Drake, Jr. From armin.bauer at desscon.com Thu Sep 9 16:18:12 2004 From: armin.bauer at desscon.com (Armin Bauer) Date: Thu Sep 9 16:18:26 2004 Subject: [Expat-discuss] CRLF conversion question In-Reply-To: <007401c49676$1ba34a10$9e539696@citkwaclaww2k> References: <1094563017.18161.4.camel@azrael> <200409071055.42294.fdrake@acm.org> <1094595519.24218.6.camel@azrael> <200409071835.27377.fdrake@acm.org> <1094733114.21807.15.camel@azrael> <003601c4966f$7e6f0dc0$9e539696@citkwaclaww2k> <1094738232.22259.19.camel@azrael> <007401c49676$1ba34a10$9e539696@citkwaclaww2k> Message-ID: <1094739492.26047.3.camel@azrael> On Thu, 2004-09-09 at 16:05, Karl Waclawek wrote: > ----- Original Message ----- > From: "Armin Bauer" > Sent: Thursday, September 09, 2004 9:57 AM > > > > > Line breaks are reported by Expat as 0x0A, no matter what > > > the input. So, depending on your platform, convert them back > > > to the appropriate line break characters. > > > > Yes. That would be one option. The only problem is how the xml document > > is parsed. The vcard in the cdata section above is parsed into nodes > > like this: > > > > > > BEGIN:VCARD > > 0x0a > > VERSION:2.1 > > 0x0a > > ... > > > > > > So... what would be the correct approach? Test if the text node == 0x0a > > and replace it with 0x0d 0x0a then? > > Yes, that looks good to me. > Now, if you ever wanted to port your app to Linux, you should > make the conversion platform dependent. actually... it runs just on linux. The problem is that the nokia phones im trying to sync need the vcards to have 0x0d 0x0a (this is how vcards are specified btw). That really makes me wonder if im the first person using libwbxml for syncml... > > > > Another option would be to Base64 encode your CDATA section. > > > You may not even need a CDATA section then, and everything > > > is preserved as if it were binary. > > > > This wont work unfortunatly, since the wbxml library receives a syncml > > request (which is an xml document with a vcard in a cdata section). So > > to be able to convert the vcard to base64 the library would have to > > detect the CDATA section first... > > OK, I thought you had control over the encoding of the vcard. > > Karl > _______________________________________________ > Expat-discuss mailing list > Expat-discuss@libexpat.org > http://mail.libexpat.org/mailman/listinfo/expat-discuss From karl at waclawek.net Thu Sep 9 16:27:14 2004 From: karl at waclawek.net (Karl Waclawek) Date: Thu Sep 9 16:27:19 2004 Subject: [Expat-discuss] CRLF conversion question References: <1094563017.18161.4.camel@azrael> <1094738232.22259.19.camel@azrael> <007401c49676$1ba34a10$9e539696@citkwaclaww2k> <200409091015.16834.fdrake@acm.org> Message-ID: <009401c49679$1a28b0a0$9e539696@citkwaclaww2k> ----- Original Message ----- From: "Fred L. Drake, Jr." Sent: Thursday, September 09, 2004 10:15 AM > On Thursday 09 September 2004 10:05 am, Karl Waclawek wrote: > > Now, if you ever wanted to port your app to Linux, you should > > make the conversion platform dependent. > > That depends on the vCard specification. If it really says CRLF, that's what > it should be. You are right. Karl From karl at waclawek.net Thu Sep 9 16:27:29 2004 From: karl at waclawek.net (Karl Waclawek) Date: Thu Sep 9 16:27:39 2004 Subject: [Expat-discuss] CRLF conversion question References: <1094563017.18161.4.camel@azrael> <200409071055.42294.fdrake@acm.org> <1094595519.24218.6.camel@azrael> <200409071835.27377.fdrake@acm.org> <1094733114.21807.15.camel@azrael> <003601c4966f$7e6f0dc0$9e539696@citkwaclaww2k> <1094738232.22259.19.camel@azrael> <007401c49676$1ba34a10$9e539696@citkwaclaww2k> <1094739492.26047.3.camel@azrael> Message-ID: <009501c49679$23430320$9e539696@citkwaclaww2k> ----- Original Message ----- From: "Armin Bauer" Sent: Thursday, September 09, 2004 10:18 AM > > > So... what would be the correct approach? Test if the text node == 0x0a > > > and replace it with 0x0d 0x0a then? > > > > Yes, that looks good to me. > > Now, if you ever wanted to port your app to Linux, you should > > make the conversion platform dependent. > > actually... it runs just on linux. The problem is that the nokia phones > im trying to sync need the vcards to have 0x0d 0x0a (this is how vcards > are specified btw). That really makes me wonder if im the first person > using libwbxml for syncml... Fred also pointed this out - it depends on the vcard specs. It seems that given this fact - that CRLF is part of the specs - the original encoding is somewhat deficient, or at least it should have some documentation with it alerting one to the necessity of converting the line breaks back. Karl From ds_sunitha at rediffmail.com Sun Sep 19 09:35:37 2004 From: ds_sunitha at rediffmail.com (Sunitha DS) Date: Sun Sep 19 10:02:21 2004 Subject: [Expat-discuss] Linker error in Embedded VC++ Message-ID: <20040919073537.2942.qmail@webmail27.rediffmail.com> Hello Please help me in resolving the following error. I am trying to compile and build the Code on Embedded VC++ environment. I am getting the linker error 2001, 2019 etc, with _iob. Please kindly suggest me how to resolve these erros. I am able to compile the "*.c" and "*.h" files, but i am getting the above said linker errors. regards Sunitha From ceo at absoft-net.com Sun Sep 19 10:28:14 2004 From: ceo at absoft-net.com (Golibasku) Date: Sun Sep 19 10:28:17 2004 Subject: [Expat-discuss] Linker error in Embedded VC++ References: <20040919073537.2942.qmail@webmail27.rediffmail.com> Message-ID: <002e01c49e22$9c325f00$0100a8c0@alexcd9t4f0rbw> i can successful build the library. But don't have your error. Are you building static library or DLL. Have you use any preprocessing directive ? ----- Original Message ----- From: "Sunitha DS" To: Sent: Sunday, September 19, 2004 3:35 PM Subject: [Expat-discuss] Linker error in Embedded VC++ Hello Please help me in resolving the following error. I am trying to compile and build the Code on Embedded VC++ environment. I am getting the linker error 2001, 2019 etc, with _iob. Please kindly suggest me how to resolve these erros. I am able to compile the "*.c" and "*.h" files, but i am getting the above said linker errors. regards Sunitha _______________________________________________ Expat-discuss mailing list Expat-discuss@libexpat.org http://mail.libexpat.org/mailman/listinfo/expat-discuss From abra9823 at mail.usyd.edu.au Sun Sep 19 12:31:07 2004 From: abra9823 at mail.usyd.edu.au (Ajay) Date: Sun Sep 19 12:31:13 2004 Subject: [Expat-discuss] Linker error in Embedded VC++ Message-ID: <1095589867.414d5febc2429@www-mail.usyd.edu.au> hi! i tried sometime ago to build expat for a pocket pc to use with my python application. i didn't get very far and had linker errors, i think i posted these on the messageboard. would you mind posting the .dll or project/workspace file once you have it working. I would really appreciate that, i am using a Python only parser on my pocket pc application and needless to say, it is very slow. This is not for any commercial purpose at all. Its merely for my research project. thanks regards ajay -- Ajay Brar Smart Internet Technology Research Group School of Information Technologies University of Sydney ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From x at x-formation.com Fri Sep 24 11:48:19 2004 From: x at x-formation.com (x@x-formation.com) Date: Fri Sep 24 11:48:21 2004 Subject: [Expat-discuss] Compiling staticly under linux? Message-ID: <1096019299.4153ed6329943@webmail.x-formation.com> Hello, I compiled expat and linked it to my program. After running ldd utility it seems it's based on a expat ".so" file. Since I need to ship my program to other users I would prefer to link staticly. Can this be done? Additionally I'd like to remove the "-g" flag if possible. How can I do this so I don't need to patch my release of expat every time I download a new update. Thanks in advance. -- John From karthikvasudeva at yahoo.com Sun Sep 26 19:26:50 2004 From: karthikvasudeva at yahoo.com (karthik vasudeva) Date: Sun Sep 26 19:26:52 2004 Subject: [Expat-discuss] Question on DOMC Message-ID: <20040926172650.78758.qmail@web50903.mail.yahoo.com> Hey, I got a refernce to DOMC while browsing through EXPAT mailing lists. I have been using Expat but now i need a DOM. I know that DOMC uses expat for parsing. So its ideal one for me. For some reason i could not get to build the DOMC dll on my Windows XP machine. I have VC++ 6.0 installed. First of all, along with the source for DOMC, i also downloaded expat,libmba and encdec and built these DLLs. I also changed the Makefile.msvc file for domc accordingly. I have the following linker error while building the domc dll: nodelist.obj : error LNK2001: unresolved external symbol ___builtin_codes expatls.obj : error LNK2001: unresolved external symbol ___builtin_codes events.obj : error LNK2001: unresolved external symbol ___builtin_codes dom.obj : error LNK2001: unresolved external symbol ___builtin_codes node.obj : error LNK2001: unresolved external symbol ___builtin_codes domc.dll : fatal error LNK1120: 1 unresolved externals NMAKE : fatal error U1077: 'link' : return code '0x460' I could figure that the variable '_builtin_codes' has been defined inside the libmba\src\mba\msgno.h ! I am new to the Windows world, but i think the linker doesnt seem to know where this file is. I also tried adding libmba.dll to C:\WINDOWS\SYSTEM32 folder. Just wanted to know if anyone has tried building the DOMC on Windows, or if someone has a copy of the domc DLL that i could use. Thanks, Karthik __________________________________ Do you Yahoo!? Y! Messenger - Communicate in real time. Download now. http://messenger.yahoo.com From skidmore at worldvenue.org Thu Sep 30 03:28:55 2004 From: skidmore at worldvenue.org (Barry Skidmore) Date: Thu Sep 30 03:28:58 2004 Subject: [Expat-discuss] xpat problem: Can not Install XML::Parser Message-ID: <1096507735.672.2.camel@worldvenue.org> Solaris 9 - SPARCstation 20 perl, v5.6.1 built for sun4-solaris-64int I am unable to install XML::Parser. The build fails after not being able to locate xpat. This does exist, and I have followed the instructions on setting EXPATLIBPATH, EXPATINCPATH, and LD_LIBRARY_PATH. Below is a transcript of what I have done, but there is obviously something else necessary. Thanks, Barry ----- cpan> install XML::Parser . . Running install for module XML::Parser Running make for M/MS/MSERGEANT/XML-Parser-2.34.tar.gz Note (probably harmless): No library found for -lexpat Expat must be installed prior to building XML::Parser and I can't find it in the standard library directories. You can download expat from: http://sourceforge.net/projects/expat/ If expat is installed, but in a non-standard directory, then use the following options to Makefile.PL: EXPATLIBPATH=... To set the directory in which to find libexpat EXPATINCPATH=... To set the directory in which to find expat.h For example: perl Makefile.PL EXPATLIBPATH=/home/me/lib EXPATINCPATH=/home/me/include Note that if you build against a shareable library in a non-standard location you may (on some platforms) also have to set your LD_LIBRARY_PATH environment variable at run time for perl to find the library. Running make test Make had some problems, maybe interrupted? Won't test Running make install Make had some problems, maybe interrupted? Won't install cpan> exit No history written (no histfile specified). Lockfile removed. # locate expat /usr/local/include/expat.h /usr/local/lib/libexpat.a /usr/local/lib/libexpat.la /usr/local/lib/libexpat.so /usr/local/lib/libexpat.so.0 /usr/local/lib/libexpat.so.0.4.0 # cd /home/skidmore/.cpan/build/XML-Parser-2.34 # perl Makefile.PL EXPATLIBPATH=/usr/local/lib EXPATINCPATH=/usr/local/include Checking if your kit is complete... Looks good Writing Makefile for XML::Parser::Expat Writing Makefile for XML::Parser # export LD_LIBRARY_PATH=/usr/lib:/usr/sfw:/usr/local/lib # echo $LD_LIBRARY_PATH /usr/lib:/usr/sfw:/usr/local/lib # perl -MCPAN -e 'shell' cpan> install XML::Parser Running install for module XML::Parser Running make for M/MS/MSERGEANT/XML-Parser-2.34.tar.gz CPAN.pm: Going to build M/MS/MSERGEANT/XML-Parser-2.34.tar.gz Note (probably harmless): No library found for -lexpat Expat must be installed prior to building XML::Parser and I can't find it in the standard library directories. You can download expat from: http://sourceforge.net/projects/expat/ If expat is installed, but in a non-standard directory, then use the following options to Makefile.PL: EXPATLIBPATH=... To set the directory in which to find libexpat EXPATINCPATH=... To set the directory in which to find expat.h For example: perl Makefile.PL EXPATLIBPATH=/home/me/lib EXPATINCPATH=/home/me/include Note that if you build against a shareable library in a non-standard location you may (on some platforms) also have to set your LD_LIBRARY_PATH environment variable at run time for perl to find the library. Running make test Make had some problems, maybe interrupted? Won't test Running make install Make had some problems, maybe interrupted? Won't install cpan>