From Dominik at pich.info Sat Oct 16 12:52:03 2004 From: Dominik at pich.info (Dominik Pich) Date: Sat Oct 16 18:24:18 2004 Subject: [Expat-discuss] expat framework for MacOS X Message-ID: <69D01BB1-1F61-11D9-A6B6-000A95B19DF0@pich.info> Could the makefile be modified to contain a section named 'install-framework'? I don't want to only copy the libraries but also setup an exspat framework for use with Xcode, kinda like allegro does it... May you always find water and shade. - Wheel Of Time Dominik From sb at dod.no Sat Oct 16 23:10:06 2004 From: sb at dod.no (Steinar Bang) Date: Sat Oct 16 23:10:15 2004 Subject: [Expat-discuss] Re: Conflict with two expat shared libraries References: <871xhpajm5.fsf@dod.no> <002101c48e3d$3bc7b6f0$0300a8c0@karlglen188> <87brgnykyx.fsf@dod.no> <000f01c491c8$dba0c610$9e539696@citkwaclaww2k> Message-ID: <871xfyl68h.fsf@dod.no> >>>>> "Karl Waclawek" : > From: "Steinar Bang" >> 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. FWIW, the MSVC linker has such an option. It's called /DELAYLOAD, and what it does, is to create a small stub function with the appropriate name, that contains a function pointer, and calls to LoadLibrary() et. al, to explicitly load a DLL, and bind to a function residing in this DLL. >> So I'm still pondering the approach to take. > Please let us know what you come up with. Your problem is likely not > unique. I've added a Feature Request, that aims to avoid this problem in the future: http://sourceforge.net/tracker/index.php?func=detail&aid=1048448&group_id=10127&atid=110127 I managed to get my application working properly again, by using your explicit load approach. Some details: - I created static functions with the same signature as the expat API functions I was using, and then used these functions in my own code, instead of using the "XML_" functions directly. Each of these static functions had a static function pointer variable. If null, this pointer is resolved against the library named "myapptp_expat". After resolving the function is called via the function pointer. The functions are included below - I had to make sure that my own expath shared library was linked with the -Bsymbolic flag. If it wasn't, the functions I were linking explicitly were using functions in the other expat shared library (the functions with the "Xml" prefix, like eg. XmlGetUtf16InternalEncoding() ). Since my build system uses gcc to create the shared lib, I sent the options "-Xlinker -Bsymbolic" when linking the shared lib It's worth noting that this approach is very similar to the result of using the /DELAYLOAD linker flag on Win32, and that it was simplified by me accessing the expat "XML_" API functions from within a single file of my application. - Steinar Here is the wrapper code, that may be of interest to others: #ifdef EXPAT_DYNAMIC_LOAD #include static QString expatLib = "myapptp_expat"; #endif /* EXPAT_DYNAMIC_LOAD */ extern "C" { #include #ifdef EXPAT_DYNAMIC_LOAD typedef int (*XML_GetCurrentLineNumberP)(XML_Parser parser); typedef int (*XML_GetCurrentColumnNumberP)(XML_Parser parser); typedef XML_Parser (*XML_ParserCreateP)(const XML_Char *encoding); typedef void (*XML_SetUserDataP)(XML_Parser parser, void *userData); typedef void (*XML_SetElementHandlerP)(XML_Parser, XML_StartElementHandler, XML_EndElementHandler); typedef void (*XML_SetCharacterDataHandlerP)(XML_Parser , XML_CharacterDataHandler); typedef void (*XML_SetProcessingInstructionHandlerP)(XML_Parser, XML_ProcessingInstructionHandler); typedef void (*XML_ParserFreeP)(XML_Parser parser); typedef int (*XML_ParseP)(XML_Parser , const char*, int, int); typedef enum XML_Error (*XML_GetErrorCodeP)(XML_Parser parser); #endif /* EXPAT_DYNAMIC_LOAD */ static int expat_GetCurrentLineNumber(XML_Parser expat) { #ifdef EXPAT_DYNAMIC_LOAD static XML_GetCurrentLineNumberP getCurrentLineNumber = 0; if (getCurrentLineNumber == 0) { getCurrentLineNumber = (XML_GetCurrentLineNumberP)QLibrary::resolve(expatLib, "XML_GetCurrentLineNumber"); } return getCurrentLineNumber(expat); #else return XML_GetCurrentLineNumber(expat); #endif } static int expat_GetCurrentColumnNumber(XML_Parser expat) { #ifdef EXPAT_DYNAMIC_LOAD static XML_GetCurrentColumnNumberP getCurrentColumnNumber = 0; if (getCurrentColumnNumber == 0) { getCurrentColumnNumber = (XML_GetCurrentColumnNumberP)QLibrary::resolve(expatLib, "XML_GetCurrentColumnNumber"); } return getCurrentColumnNumber(expat); #else return XML_GetCurrentColumnNumber(expat); #endif } static XML_Parser expat_ParserCreate(const XML_Char* encoding) { #ifdef EXPAT_DYNAMIC_LOAD static XML_ParserCreateP parserCreate = 0; if (parserCreate == 0) { parserCreate = (XML_ParserCreateP)QLibrary::resolve(expatLib, "XML_ParserCreate"); } return parserCreate(encoding); #else return XML_ParserCreate(encoding); #endif } static void expat_SetUserData(XML_Parser parser, void* userData) { #ifdef EXPAT_DYNAMIC_LOAD static XML_SetUserDataP setUserData = 0; if (setUserData == 0) { setUserData = (XML_SetUserDataP)QLibrary::resolve(expatLib, "XML_SetUserData"); } setUserData(parser, userData); #else XML_SetUserData(parser, userData); #endif } static void expat_SetElementHandler(XML_Parser parser, XML_StartElementHandler start, XML_EndElementHandler end) { #ifdef EXPAT_DYNAMIC_LOAD static XML_SetElementHandlerP setElementHandler = 0; if (setElementHandler == 0) { setElementHandler = (XML_SetElementHandlerP)QLibrary::resolve(expatLib, "XML_SetElementHandler"); } setElementHandler(parser, start, end); #else XML_SetElementHandler(parser, start, end); #endif } static void expat_SetCharacterDataHandler(XML_Parser parser, XML_CharacterDataHandler handler) { #ifdef EXPAT_DYNAMIC_LOAD static XML_SetCharacterDataHandlerP setCharacterDataHandler = 0; if (setCharacterDataHandler == 0) { setCharacterDataHandler = (XML_SetCharacterDataHandlerP)QLibrary::resolve(expatLib, "XML_SetCharacterDataHandler"); } setCharacterDataHandler(parser, handler); #else XML_SetCharacterDataHandler(parser, handler); #endif } static void expat_SetProcessingInstructionHandler(XML_Parser parser, XML_ProcessingInstructionHandler handler) { #ifdef EXPAT_DYNAMIC_LOAD static XML_SetProcessingInstructionHandlerP setProcessingInstructionHandler = 0; if (setProcessingInstructionHandler == 0) { setProcessingInstructionHandler = (XML_SetProcessingInstructionHandlerP)QLibrary::resolve(expatLib, "XML_SetProcessingInstructionHandler"); } setProcessingInstructionHandler(parser, handler); #else XML_SetProcessingInstructionHandler(parser, handler); #endif } static void expat_ParserFree(XML_Parser parser) { #ifdef EXPAT_DYNAMIC_LOAD static XML_ParserFreeP parserFree = 0; if (parserFree == 0) { parserFree = (XML_ParserFreeP)QLibrary::resolve(expatLib, "XML_ParserFree"); } parserFree(parser); #else XML_ParserFree(parser); #endif } From karl at waclawek.net Sat Oct 16 23:35:11 2004 From: karl at waclawek.net (Karl Waclawek) Date: Sat Oct 16 23:36:31 2004 Subject: [Expat-discuss] Re: Conflict with two expat shared libraries References: <871xhpajm5.fsf@dod.no><002101c48e3d$3bc7b6f0$0300a8c0@karlglen188> <87brgnykyx.fsf@dod.no><000f01c491c8$dba0c610$9e539696@citkwaclaww2k> <871xfyl68h.fsf@dod.no> Message-ID: <036901c4b3c8$32875ea0$0300a8c0@karlglen188> ----- Original Message ----- From: "Steinar Bang" Sent: Saturday, October 16, 2004 5:10 PM > > I've added a Feature Request, that aims to avoid this problem in the > future: > http://sourceforge.net/tracker/index.php?func=detail&aid=1048448&group_id=10127&atid=110127 > > I managed to get my application working properly again, by using your > explicit load approach. > > Some details: > > - I created static functions with the same signature as the expat API > functions I was using, and then used these functions in my own > code, instead of using the "XML_" functions directly. > Each of these static functions had a static function pointer > variable. If null, this pointer is resolved against the library > named "myapptp_expat". After resolving the function is called via > the function pointer. The functions are included below > > - I had to make sure that my own expath shared library was linked > with the -Bsymbolic flag. If it wasn't, the functions I were > linking explicitly were using functions in the other expat shared > library (the functions with the "Xml" prefix, like > eg. XmlGetUtf16InternalEncoding() ). > Since my build system uses gcc to create the shared lib, I sent the > options "-Xlinker -Bsymbolic" when linking the shared lib Yes, that looks like what I would have done. Could you not have avoided the special -Bsymbolic flag by naming your function pointers differently than their Expat names? Karl From sb at dod.no Sun Oct 17 10:13:11 2004 From: sb at dod.no (Steinar Bang) Date: Sun Oct 17 10:13:16 2004 Subject: [Expat-discuss] Re: Conflict with two expat shared libraries References: <871xhpajm5.fsf@dod.no> <002101c48e3d$3bc7b6f0$0300a8c0@karlglen188> <87brgnykyx.fsf@dod.no> <000f01c491c8$dba0c610$9e539696@citkwaclaww2k> <871xfyl68h.fsf@dod.no> <036901c4b3c8$32875ea0$0300a8c0@karlglen188> Message-ID: <87oej1kbjc.fsf@dod.no> >>>>> "Karl Waclawek" : > Could you not have avoided the special -Bsymbolic flag by naming > your function pointers differently than their Expat names? Note the sample code. The function pointers are different from their expat names. And the answer is no. The -Bsymbolic flag was to make the expat functions themselves, call functions in the shared lib they were a part of, instead of functions with the same name in the other shared lib. I was on the verge of giving up, when I eventually googled my way to the -Bsymbolic flag...;-) From karl at waclawek.net Sun Oct 17 15:58:36 2004 From: karl at waclawek.net (Karl Waclawek) Date: Sun Oct 17 15:58:37 2004 Subject: [Expat-discuss] Re: Conflict with two expat shared libraries References: <871xhpajm5.fsf@dod.no><002101c48e3d$3bc7b6f0$0300a8c0@karlglen188> <87brgnykyx.fsf@dod.no><000f01c491c8$dba0c610$9e539696@citkwaclaww2k> <871xfyl68h.fsf@dod.no><036901c4b3c8$32875ea0$0300a8c0@karlglen188> <87oej1kbjc.fsf@dod.no> Message-ID: <001301c4b451$665825a0$0200a8c0@karlglen188> >>>>>> "Karl Waclawek" : > >> Could you not have avoided the special -Bsymbolic flag by naming >> your function pointers differently than their Expat names? > > Note the sample code. The function pointers are different from their > expat names. > > And the answer is no. The -Bsymbolic flag was to make the expat > functions themselves, call functions in the shared lib they were a > part of, instead of functions with the same name in the other shared > lib. > > I was on the verge of giving up, when I eventually googled my way to > the -Bsymbolic flag...;-) After re-reading it I am not sure I understand what you did. Does QLibrary::resolve() use dlopen() and dlsym()? Karl From sb at dod.no Sun Oct 17 21:02:05 2004 From: sb at dod.no (Steinar Bang) Date: Sun Oct 17 21:02:10 2004 Subject: [Expat-discuss] Re: Conflict with two expat shared libraries References: <871xhpajm5.fsf@dod.no> <002101c48e3d$3bc7b6f0$0300a8c0@karlglen188> <87brgnykyx.fsf@dod.no> <000f01c491c8$dba0c610$9e539696@citkwaclaww2k> <871xfyl68h.fsf@dod.no> <036901c4b3c8$32875ea0$0300a8c0@karlglen188> <87oej1kbjc.fsf@dod.no> <001301c4b451$665825a0$0200a8c0@karlglen188> Message-ID: <87k6tpjhhu.fsf@dod.no> >>>>> "Karl Waclawek" : > After re-reading it I am not sure I understand what you did. OK. I'll try phrasing it differently. > Does QLibrary::resolve() use dlopen() and dlsym()? Without looking at the code: yes, I think so. And the functions I bound to a function pointer using QLibrary::resolve(), like eg. XML_Parse(), are bound to the implementation in the correct library. For the example below I'll name the system installed expat shared lib that fontconfig is using expatA, and my own expat shared lib (with an XML_Char of short int size) expatB What happened was: - The application was linked with expatA, because fontconfig was using it - When I linked with expatB, fontconfig started using the API in expatB, and got the error message I described - When I removed the linkage to expatB, fontconfig started working again, but my own application no longer could parse XML files - When I used QLibrary::resolve() to bind a function pointer to eg. XML_Parse() in expatB, fontconfig worked, but my own application still couldn't parse files - When I followed XML_Parse() of expatB, in the debugger, I saw that it got to a place where it called the function XmlGetUtf16InternalEncoding(). And the version of the function that was called, was the version in expatA, and not the version in expatB The -Bsymbolic flag used when linking expatB will make the XML_Parse() function in expatB, always call the XmlGetUtf16InternalEncoding() function residing together with it in expatB, no matter what other symbols is available through linkage with other shared libraries. Did I succeed in making it clearer, or more confused...? :-) From karl at waclawek.net Sun Oct 17 22:45:33 2004 From: karl at waclawek.net (Karl Waclawek) Date: Sun Oct 17 22:45:33 2004 Subject: [Expat-discuss] Re: Conflict with two expat shared libraries References: <871xhpajm5.fsf@dod.no><002101c48e3d$3bc7b6f0$0300a8c0@karlglen188> <87brgnykyx.fsf@dod.no><000f01c491c8$dba0c610$9e539696@citkwaclaww2k> <871xfyl68h.fsf@dod.no><036901c4b3c8$32875ea0$0300a8c0@karlglen188> <87oej1kbjc.fsf@dod.no><001301c4b451$665825a0$0200a8c0@karlglen188> <87k6tpjhhu.fsf@dod.no> Message-ID: <001801c4b48a$3fbffdd0$097ca8c0@karlglen188> >>>>>> "Karl Waclawek" : > >> After re-reading it I am not sure I understand what you did. > > OK. I'll try phrasing it differently. > >> Does QLibrary::resolve() use dlopen() and dlsym()? > > Without looking at the code: yes, I think so. And the functions I > bound to a function pointer using QLibrary::resolve(), like > eg. XML_Parse(), are bound to the implementation in the correct > library. > > For the example below I'll name the system installed expat shared lib > that fontconfig is using expatA, and my own expat shared lib (with > an XML_Char of short int size) expatB > > What happened was: > > - The application was linked with expatA, because fontconfig was > using it > - When I linked with expatB, fontconfig started using the API in > expatB, and got the error message I described > - When I removed the linkage to expatB, fontconfig started working > again, but my own application no longer could parse XML files > - When I used QLibrary::resolve() to bind a function pointer to > eg. XML_Parse() in expatB, fontconfig worked, but my own > application still couldn't parse files > - When I followed XML_Parse() of expatB, in the debugger, I saw > that it got to a place where it called the function > XmlGetUtf16InternalEncoding(). And the version of the function > that was called, was the version in expatA, and not the version in > expatB > > The -Bsymbolic flag used when linking expatB will make the XML_Parse() > function in expatB, always call the XmlGetUtf16InternalEncoding() > function residing together with it in expatB, no matter what other > symbols is available through linkage with other shared libraries. > > Did I succeed in making it clearer, or more confused...? :-) I think what confused me is that with true dynamic linking the linker is not involved at all. Obviously, what you are doing is still static linking, and that is why you had to go to great lengths to disambiguate the linked symbols. What I had in mind is to define your own header file (not use expat.h at all). Declare function pointers and types at the size you need, and define a LoadExpat and UnloadExpat function which you can use to set and clear the function pointers at application startup and termination. dlopen() loads the shared library (libexpatw.so), and dlsym() retrieves the function pointer for each Expat API member. In Windows these functions would be called LoadLibrary() and GetProcAddress(). It might be a good idea to create such header files as part of the Expat distribution. They could be called expatdyn.h and expatdynw.h for 8 bit and 16 bit characters. Karl From sb at dod.no Sun Oct 17 23:57:22 2004 From: sb at dod.no (Steinar Bang) Date: Sun Oct 17 23:57:27 2004 Subject: [Expat-discuss] Re: Conflict with two expat shared libraries References: <871xhpajm5.fsf@dod.no> <002101c48e3d$3bc7b6f0$0300a8c0@karlglen188> <87brgnykyx.fsf@dod.no> <000f01c491c8$dba0c610$9e539696@citkwaclaww2k> <871xfyl68h.fsf@dod.no> <036901c4b3c8$32875ea0$0300a8c0@karlglen188> <87oej1kbjc.fsf@dod.no> <001301c4b451$665825a0$0200a8c0@karlglen188> <87k6tpjhhu.fsf@dod.no> <001801c4b48a$3fbffdd0$097ca8c0@karlglen188> Message-ID: <87brf1j9dp.fsf@dod.no> >>>>> "Karl Waclawek" : > I think what confused me is that with true dynamic linking the > linker is not involved at all. Obviously, what you are doing is > still static linking, and that is why you had to go to great lengths > to disambiguate the linked symbols. Actually, using -Bsymbolic to create expatB was the simple approach. Dynamically linking, and binding _all_ exported symbols would have been a lot more work. And the problem symbols, such as e.g. XmlGetUtf16InternalEncoding(), I couldn't have done anything about, without rewriting my version of expat to use function pointers, and dynamic binding. > What I had in mind is to define your own header file (not use > expat.h at all). Declare function pointers and types at the size > you need, and define a LoadExpat and UnloadExpat function which you > can use to set and clear the function pointers at application > startup and termination. dlopen() loads the shared library > (libexpatw.so), and dlsym() retrieves the function pointer for each > Expat API member. In Windows these functions would be called > LoadLibrary() and GetProcAddress(). > It might be a good idea to create such header files as part of the > Expat distribution. They could be called expatdyn.h and expatdynw.h > for 8 bit and 16 bit characters. It won't work on ELF-architectures, without rewriting the expat internals to use function pointers, with explicit binding to the library they will be a part of. Use the name of the shared library they'll end up in, as a string constant, or something. If your background is Win32, note that a big difference between DLLs and ELF shared libraries, is that on ELF all global references are is exported. That is, all global references except static functions, and variables, which aren't exported outside of the compilation unit (if we're talking C and C++). Ie. it's like if you have __declspec(dllexport) on all functions. From karl at waclawek.net Mon Oct 18 01:00:25 2004 From: karl at waclawek.net (Karl Waclawek) Date: Mon Oct 18 01:00:32 2004 Subject: [Expat-discuss] Re: Conflict with two expat shared libraries References: <871xhpajm5.fsf@dod.no><002101c48e3d$3bc7b6f0$0300a8c0@karlglen188> <87brgnykyx.fsf@dod.no><000f01c491c8$dba0c610$9e539696@citkwaclaww2k> <871xfyl68h.fsf@dod.no><036901c4b3c8$32875ea0$0300a8c0@karlglen188> <87oej1kbjc.fsf@dod.no><001301c4b451$665825a0$0200a8c0@karlglen188> <87k6tpjhhu.fsf@dod.no><001801c4b48a$3fbffdd0$097ca8c0@karlglen188> <87brf1j9dp.fsf@dod.no> Message-ID: <002701c4b49d$1a5b6940$097ca8c0@karlglen188> ----- Original Message ----- From: "Steinar Bang" Sent: Sunday, October 17, 2004 5:57 PM >>>>>> "Karl Waclawek" : > >> I think what confused me is that with true dynamic linking the >> linker is not involved at all. Obviously, what you are doing is >> still static linking, and that is why you had to go to great lengths >> to disambiguate the linked symbols. > > Actually, using -Bsymbolic to create expatB was the simple approach. > Dynamically linking, and binding _all_ exported symbols would have > been a lot more work. And the problem symbols, such as > e.g. XmlGetUtf16InternalEncoding(), I couldn't have done anything > about, without rewriting my version of expat to use function pointers, > and dynamic binding. > >> What I had in mind is to define your own header file (not use >> expat.h at all). Declare function pointers and types at the size >> you need, and define a LoadExpat and UnloadExpat function which you >> can use to set and clear the function pointers at application >> startup and termination. dlopen() loads the shared library >> (libexpatw.so), and dlsym() retrieves the function pointer for each >> Expat API member. In Windows these functions would be called >> LoadLibrary() and GetProcAddress(). > >> It might be a good idea to create such header files as part of the >> Expat distribution. They could be called expatdyn.h and expatdynw.h >> for 8 bit and 16 bit characters. > > It won't work on ELF-architectures, without rewriting the expat > internals to use function pointers, with explicit binding to the > library they will be a part of. Use the name of the shared library > they'll end up in, as a string constant, or something. > > If your background is Win32, note that a big difference between DLLs > and ELF shared libraries, is that on ELF all global references are is > exported. That is, all global references except static functions, and > variables, which aren't exported outside of the compilation unit (if > we're talking C and C++). > > Ie. it's like if you have __declspec(dllexport) on all functions. You guessed right, my background is Win32, and I didn't know that in ELF libraries all global references are exported. However, should it not work anyway? When the ELF library is loaded, aren't the links to these functiones like XmlGetUtf16InternalEncoding resolved already (at compile time), at least for those calls that are internal to the library? Or are they still left open for late binding? Would that late binding then happen when dlopen() is called, or even later, when dlsym() is called? I admit, I don't understand much about how linking works on Linux, and not that much about it in general. Karl From sb at dod.no Tue Oct 19 19:54:03 2004 From: sb at dod.no (Steinar Bang) Date: Tue Oct 19 19:54:10 2004 Subject: [Expat-discuss] Re: Conflict with two expat shared libraries References: <871xhpajm5.fsf@dod.no> <002101c48e3d$3bc7b6f0$0300a8c0@karlglen188> <87brgnykyx.fsf@dod.no> <000f01c491c8$dba0c610$9e539696@citkwaclaww2k> <871xfyl68h.fsf@dod.no> <036901c4b3c8$32875ea0$0300a8c0@karlglen188> <87oej1kbjc.fsf@dod.no> <001301c4b451$665825a0$0200a8c0@karlglen188> <87k6tpjhhu.fsf@dod.no> <001801c4b48a$3fbffdd0$097ca8c0@karlglen188> <87brf1j9dp.fsf@dod.no> <002701c4b49d$1a5b6940$097ca8c0@karlglen188> Message-ID: <874qkqbnlw.fsf@dod.no> >>>>> "Karl Waclawek" : > However, should it not work anyway? > When the ELF library is loaded, aren't the links to these functiones > like XmlGetUtf16InternalEncoding resolved already (at compile time), > at least for those calls that are internal to the library? Nope. But the -Bsymbolic flag effectively achives this effect (though in a different manner, see below). > Or are they still left open for late binding? Yes. > Would that late binding then happen when dlopen() is called, or even > later, when dlsym() is called? That's what I experienced. However, using the -Bsymbolic flag when creating the shared library solved my problem. What it does (for listing googleable terms), is to is set the DT_SYMBOLIC dynamic entry. This is interpreted to search the module itself, and its immediate dependencies, instead of doing a global search. Hm... it's possible that if the fontconfig shared library had been created with the -Bsymbolic flag, it would have used the system's expat shared library ("expatA" in my description earlier), and not be overriden by mine (But that's out of my control. I could file a bug, but since I don't know whether using -Bsymbolic would actually work, I'm not sure what to say in the bug report). From karl at waclawek.net Tue Oct 19 20:02:34 2004 From: karl at waclawek.net (Karl Waclawek) Date: Tue Oct 19 20:02:37 2004 Subject: [Expat-discuss] Re: Conflict with two expat shared libraries References: <871xhpajm5.fsf@dod.no><002101c48e3d$3bc7b6f0$0300a8c0@karlglen188> <87brgnykyx.fsf@dod.no><000f01c491c8$dba0c610$9e539696@citkwaclaww2k> <871xfyl68h.fsf@dod.no><036901c4b3c8$32875ea0$0300a8c0@karlglen188> <87oej1kbjc.fsf@dod.no><001301c4b451$665825a0$0200a8c0@karlglen188> <87k6tpjhhu.fsf@dod.no><001801c4b48a$3fbffdd0$097ca8c0@karlglen188> <87brf1j9dp.fsf@dod.no><002701c4b49d$1a5b6940$097ca8c0@karlglen188> <874qkqbnlw.fsf@dod.no> Message-ID: <001b01c4b605$cff09a00$057ca8c0@karlglen188> ----- Original Message ----- From: "Steinar Bang" Sent: Tuesday, October 19, 2004 1:54 PM >>>>>> "Karl Waclawek" : > >> However, should it not work anyway? >> When the ELF library is loaded, aren't the links to these functiones >> like XmlGetUtf16InternalEncoding resolved already (at compile time), >> at least for those calls that are internal to the library? > > Nope. But the -Bsymbolic flag effectively achives this effect (though > in a different manner, see below). > >> Or are they still left open for late binding? > > Yes. > >> Would that late binding then happen when dlopen() is called, or even >> later, when dlsym() is called? > > That's what I experienced. I did a quick readup, and I found that contray to Windows Dlls ELF libraries share a global namespace for all their symbols. This together with late binding for internal links obviosuly explains it. > However, using the -Bsymbolic flag when creating the shared library > solved my problem. What it does (for listing googleable terms), is to > is set the DT_SYMBOLIC dynamic entry. This is interpreted to search > the module itself, and its immediate dependencies, instead of doing a > global search. I saw that flag mentioned as well. Supposedly it is not well supported. Hhmm, would it not be better then to find a way to control which symbols are exported from within Expat? In other words, isn't there a design issue with Expat? Karl From sb at dod.no Tue Oct 19 22:23:14 2004 From: sb at dod.no (Steinar Bang) Date: Tue Oct 19 22:23:32 2004 Subject: [Expat-discuss] Re: Conflict with two expat shared libraries References: <871xhpajm5.fsf@dod.no> <002101c48e3d$3bc7b6f0$0300a8c0@karlglen188> <87brgnykyx.fsf@dod.no> <000f01c491c8$dba0c610$9e539696@citkwaclaww2k> <871xfyl68h.fsf@dod.no> <036901c4b3c8$32875ea0$0300a8c0@karlglen188> <87oej1kbjc.fsf@dod.no> <001301c4b451$665825a0$0200a8c0@karlglen188> <87k6tpjhhu.fsf@dod.no> <001801c4b48a$3fbffdd0$097ca8c0@karlglen188> <87brf1j9dp.fsf@dod.no> <002701c4b49d$1a5b6940$097ca8c0@karlglen188> <874qkqbnlw.fsf@dod.no> <001b01c4b605$cff09a00$057ca8c0@karlglen188> Message-ID: <87zn2ia24t.fsf@dod.no> >>>>> "Karl Waclawek" : > I saw that flag mentioned as well. Supposedly it is not well > supported. Hhmm, would it not be better then to find a way to > control which symbols are exported from within Expat? In other > words, isn't there a design issue with Expat? I think the enhancement request below would fix at least this particular problem: http://sourceforge.net/tracker/index.php?func=detail&aid=1048448&group_id=10127&atid=110127 This would be similar to the "A" and "W" suffixes used on different versions of the Win32 API calls. From fdrake at acm.org Tue Oct 19 22:37:20 2004 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Tue Oct 19 22:37:30 2004 Subject: [Expat-discuss] Re: Conflict with two expat shared libraries In-Reply-To: <001b01c4b605$cff09a00$057ca8c0@karlglen188> References: <871xhpajm5.fsf@dod.no> <874qkqbnlw.fsf@dod.no> <001b01c4b605$cff09a00$057ca8c0@karlglen188> Message-ID: <200410191637.20789.fdrake@acm.org> On Tuesday 19 October 2004 02:02 pm, Karl Waclawek wrote: > I saw that flag mentioned as well. Supposedly it is not well supported. > Hhmm, would it not be better then to find a way to control > which symbols are exported from within Expat? In other words, > isn't there a design issue with Expat? I vaguely recall James Clark mentioning that he expected some people to use the really-really-really-low-level calls directly, especially if they didn't need to do much with the XML data. It's not at all clear to be that anyone uses these APIs, so it may be that doing something with the library would be best. It would be interesting to know if anyone is using the low-level calls. It would be quite disturbing if they are. ;-) They certainly aren't documented, and I dread the thought that they need to be supported. -Fred -- Fred L. Drake, Jr. From karl at waclawek.net Tue Oct 19 23:03:07 2004 From: karl at waclawek.net (Karl Waclawek) Date: Tue Oct 19 23:03:06 2004 Subject: [Expat-discuss] Re: Conflict with two expat shared libraries References: <871xhpajm5.fsf@dod.no> <874qkqbnlw.fsf@dod.no> <001b01c4b605$cff09a00$057ca8c0@karlglen188> <200410191637.20789.fdrake@acm.org> Message-ID: <001801c4b61f$0930c8d0$047ca8c0@karlglen188> ----- Original Message ----- From: "Fred L. Drake, Jr." Sent: Tuesday, October 19, 2004 4:37 PM > On Tuesday 19 October 2004 02:02 pm, Karl Waclawek wrote: > > I saw that flag mentioned as well. Supposedly it is not well supported. > > Hhmm, would it not be better then to find a way to control > > which symbols are exported from within Expat? In other words, > > isn't there a design issue with Expat? > > I vaguely recall James Clark mentioning that he expected some people to use > the really-really-really-low-level calls directly, especially if they didn't > need to do much with the XML data. I think you are right. I believe it was the API exposed by xmltok.h. > It's not at all clear to be that anyone uses these APIs, so it may be that > doing something with the library would be best. Do you know how to? I recall that the Mozilla developers have the same problem of using both 8bit and 16bit versions of Expat in the same app. > It would be interesting to know if anyone is using the low-level calls. It > would be quite disturbing if they are. ;-) They certainly aren't > documented, and I dread the thought that they need to be supported. Maybe Steinar could help? ;-) Karl From karl at waclawek.net Tue Oct 19 23:07:27 2004 From: karl at waclawek.net (Karl Waclawek) Date: Tue Oct 19 23:07:25 2004 Subject: [Expat-discuss] Re: Conflict with two expat shared libraries References: <871xhpajm5.fsf@dod.no><002101c48e3d$3bc7b6f0$0300a8c0@karlglen188> <87brgnykyx.fsf@dod.no><000f01c491c8$dba0c610$9e539696@citkwaclaww2k> <871xfyl68h.fsf@dod.no><036901c4b3c8$32875ea0$0300a8c0@karlglen188> <87oej1kbjc.fsf@dod.no><001301c4b451$665825a0$0200a8c0@karlglen188> <87k6tpjhhu.fsf@dod.no><001801c4b48a$3fbffdd0$097ca8c0@karlglen188> <87brf1j9dp.fsf@dod.no><002701c4b49d$1a5b6940$097ca8c0@karlglen188> <874qkqbnlw.fsf@dod.no><001b01c4b605$cff09a00$057ca8c0@karlglen188> <87zn2ia24t.fsf@dod.no> Message-ID: <001d01c4b61f$a39aa940$047ca8c0@karlglen188> ----- Original Message ----- From: "Steinar Bang" Sent: Tuesday, October 19, 2004 4:23 PM >>>>>> "Karl Waclawek" : > >> I saw that flag mentioned as well. Supposedly it is not well >> supported. Hhmm, would it not be better then to find a way to >> control which symbols are exported from within Expat? In other >> words, isn't there a design issue with Expat? > > I think the enhancement request below would fix at least this > particular problem: > http://sourceforge.net/tracker/index.php?func=detail&aid=1048448&group_id=10127&atid=110127 > > This would be similar to the "A" and "W" suffixes used on different > versions of the Win32 API calls. I guess it would break existing code, but it is in principle a reasonable approach. The other one would be, of course, to control what is exported, to avoid the need for the -Bsymbolic flag. Karl From sb at dod.no Wed Oct 20 08:43:30 2004 From: sb at dod.no (Steinar Bang) Date: Wed Oct 20 08:43:38 2004 Subject: [Expat-discuss] Re: Conflict with two expat shared libraries References: <871xhpajm5.fsf@dod.no> <874qkqbnlw.fsf@dod.no> <001b01c4b605$cff09a00$057ca8c0@karlglen188> <200410191637.20789.fdrake@acm.org> <001801c4b61f$0930c8d0$047ca8c0@karlglen188> Message-ID: <87is95anzh.fsf@dod.no> >>>>> "Karl Waclawek" : > From: "Fred L. Drake, Jr." >> It would be interesting to know if anyone is using the low-level >> calls. It would be quite disturbing if they are. ;-) They >> certainly aren't documented, and I dread the thought that they need >> to be supported. > Maybe Steinar could help? ;-) Sorry, no. The only thing I know about them, is that I ran into them, when I tried to link the published API functions explicitly with QLibrary. From SpamTrap at gmx.de Fri Oct 22 11:52:38 2004 From: SpamTrap at gmx.de (Hendrik Schober) Date: Fri Oct 22 12:10:13 2004 Subject: [Expat-discuss] DoS exploit? Message-ID: Hi, I have heard about a bug in expat that would allow DoS attacks. I have searched through the bug mailing list, this list, the bug list at sourceforge, and used google. However, besides some seemingly false alarm in 2002, I only found some evidence that there really might have been such a bug in some version of expat (start looking for this at http://mail.jabber.org/pipermail/jabberd/2004-September/002005.html). I haven't had any luck finding whether this is true, let alone which version of expat were vulnerable. Is there anybody out there who can shed some light onto this? I have been asked by a customer to comment on the issue. TIA, Schobi -- SpamTrap@gmx.de is never read I'm Schobi at suespammers dot org "The presence of those seeking the truth is infinitely to be prefered to those thinking they've found it." Terry Pratchett From karl at waclawek.net Fri Oct 22 14:32:18 2004 From: karl at waclawek.net (Karl Waclawek) Date: Fri Oct 22 14:32:19 2004 Subject: [Expat-discuss] DoS exploit? References: Message-ID: <001301c4b833$2babf8b0$0200a8c0@karlglen188> ----- Original Message ----- From: "Hendrik Schober" To: Sent: Friday, October 22, 2004 5:52 AM Subject: [Expat-discuss] DoS exploit? > Hi, > > I have heard about a bug in expat that would allow DoS > attacks. > I have searched through the bug mailing list, this list, > the bug list at sourceforge, and used google. However, > besides some seemingly false alarm in 2002, I only found > some evidence that there really might have been such a > bug in some version of expat (start looking for this at > http://mail.jabber.org/pipermail/jabberd/2004-September/002005.html). > I haven't had any luck finding whether this is true, let > alone which version of expat were vulnerable. > > Is there anybody out there who can shed some light onto > this? I have been asked by a customer to comment on the > issue. Search google for the "million laughs xml" attack. This is a DoS attack that every conforming XML parser is susceptible too. Its based on how entities declared in a DTD are expanded. There is no known bug in Expat related to DoS attacks. Karl From mickymenezes at greymatterindia.com Wed Oct 27 07:28:44 2004 From: mickymenezes at greymatterindia.com (Micky MeNeZeS) Date: Wed Oct 27 07:25:21 2004 Subject: [Expat-discuss] creating xml Message-ID: <002101c4bbe5$d3e7b860$4900a8c0@gmitech> Is it possible to create XML using expat. Regards, Micky From mickymenezes at greymatterindia.com Wed Oct 27 07:33:40 2004 From: mickymenezes at greymatterindia.com (Micky MeNeZeS) Date: Wed Oct 27 07:30:24 2004 Subject: [Expat-discuss] Create XML file Message-ID: <002c01c4bbe6$844bd150$4900a8c0@gmitech> Hi all, Is it possible to create XML using expat ? I mean can we write into xml file which is blank or already having some structured data. Thanks and Regards, Micky From mbenyounes at tycoint.com Thu Oct 28 00:34:02 2004 From: mbenyounes at tycoint.com (mbenyounes@tycoint.com) Date: Thu Oct 28 01:05:36 2004 Subject: [Expat-discuss] Compiling the library for arm target Message-ID: Hi to whomever can help, I'm trying to build the expat library to target the arm-linux-gcc, I also added -mbig-endian flag to build the big endian format. I am, however getting an error when Lib/xmlparse.lo: could not read symbols: file in wrong format Collect2: ld returned 1 exit status Thank you for any suggestions. Mohamed Benyounes From lee at puddledock.net Thu Oct 28 02:58:14 2004 From: lee at puddledock.net (Lee Brown) Date: Thu Oct 28 02:58:07 2004 Subject: [Expat-discuss] entities in parameters Message-ID: <000c01c4bc89$3428b140$0200a8c0@GLOUCESTER> I see a different behavior after upgrading from expat 1.95.2 to 1.95.8 and using the library with Sablotron's sabcmd XSL translator. A picture is clearer.... XSL: LINE: XML: line one line two line three With the 1.95.2 library I get line-breaks between each line in the XSL translation output, but with the 1.95.8 library there are no line-breaks. The AA parameter does get expanded, so I'm certain this has to do with entities. If I replace the "$LF" in the xsl:value-of element with "' '" then I do get a line-break. The behavior is the same if I use xsl:variable instead of xsl:param. I've also tried the example with saxon instead of sabcmd (saxon does not use the expat library) and I do get line-breaks. Can anyone shed any light on this? P.S. I'm running on UnixWare 2.1.3. I built from source, no modifications necessary. Thanks, Lee From nickmacd at gmail.com Thu Oct 28 04:26:31 2004 From: nickmacd at gmail.com (Nick MacDonald) Date: Thu Oct 28 04:26:37 2004 Subject: [Expat-discuss] Handling text that occurs in multiple places inside of start and end tags Message-ID: I am creating my own expat wrapper that will work somewhat like SAX (I probably should have used someone elses, but I didn't know where to look when I started this project, and now I 95% done and determined to finish my own.) I am getting the start/text/end call backs in the order you would expect, and I am happy with the results. I was considering implementing an "all tag data at once" capability, but I can't think of any really good way to handle the case where you have text for one tag intermixed with other tags. I am working with the following XML file: Some data for TestTag1 Some more data for TestTag1 Still more data for TestTag1 What I would like to see happen: callback4TestTag1(2, paramNames, paramValues, text) callback4TestTag2() callback4TestTag3() callback4TestTag4() and the value for "text" in the first call back would be: "Some data for TestTag1 Some more data for TestTag1 Still more data for TestTag1" Short of implementing a full DOM, can anyone suggest a good memory efficient way to deal with this case. So far, my only hope, short of putting it all on a huge stack and or using DOM is to read the same file multiple times, and that just isn't a pretty thought. Is there some trick I could use in expat to achieve this? From mbenyounes at tycoint.com Thu Oct 28 19:43:48 2004 From: mbenyounes at tycoint.com (mbenyounes@tycoint.com) Date: Thu Oct 28 19:43:28 2004 Subject: [Expat-discuss] Expat for arm-linux-gcc Message-ID: Hi to whomever can help, I'm trying to build the expat library to target the arm-linux-gcc using -mbig-endian flag to build the big endian format. I am, however getting an error when Lib/xmlparse.lo: could not read symbols: file in wrong format Collect2: ld returned 1 exit status Thank you for any suggestions. Mohamed Benyounes From magi at funambol.com Thu Oct 28 20:31:27 2004 From: magi at funambol.com (Marco Magistrali) Date: Thu Oct 28 20:32:50 2004 Subject: [Expat-discuss] Expat for arm-linux-gcc References: Message-ID: <00ac01c4bd1c$5791bf80$0400a8c0@Delicious> Hi, I apologize but I don't know how answer to your question.. :( I'm a newbe... I have a similar problem but on windows platform. I would like to build expat for arm ppc 2003 using the MS eVC++ 4.0. My build finishes successfully but my program can't link with the .lib just generated. So I think there are some macro to define to build but I don't guess what they are. Any hints? Thanks so much Marco ----- Original Message ----- From: To: Sent: Thursday, October 28, 2004 7:43 PM Subject: [Expat-discuss] Expat for arm-linux-gcc > Hi to whomever can help, > > > > I'm trying to build the expat library to target the arm-linux-gcc using > -mbig-endian flag to build the big endian format. I am, however getting an > error when > > > > Lib/xmlparse.lo: could not read symbols: file in wrong format > > Collect2: ld returned 1 exit status > > > > Thank you for any suggestions. > > > > Mohamed Benyounes > > > > > > _______________________________________________ > Expat-discuss mailing list > Expat-discuss@libexpat.org > http://mail.libexpat.org/mailman/listinfo/expat-discuss > From mbenyounes at tycoint.com Fri Oct 29 18:28:12 2004 From: mbenyounes at tycoint.com (mbenyounes@tycoint.com) Date: Fri Oct 29 18:28:11 2004 Subject: [Expat-discuss] Expat-1.95.8 Build for arm-linux Message-ID: While building Expat-1.95.8 for arm-linux, I encountered the following erros: checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking for gcc... arm-linux-gcc checking for C compiler default output... configure: error: C compiler cannot create executables configure options I used are: ./configure CC=arm-linux-gcc --with-arm-linux-ld --without-pic