Re: [xslt] Relase of xsldbg-0.7.9, : release of xsldbg-0.8.1

[Daniel Veillard <veillard redhat com>]

On Thu, Nov 29, 2001 at 02:57:07PM +1000, Keith Isdale wrote:
> Hi all,
> 
> Kdbg (in xsldbg mode) and  xsldbg-0.8.2  has been released see below.
> 
> Daniel wrote,
>  
> >>  Okay, looks good (libxslt-1.0.8_ki_0.8.1.diff), applied !
> >>However I noticed that xslHandleDebugger() is still called from a few
> >>places while it's now a noop function. Do you plan to turn 
> >> xslHandleDebugger()
> >> back into a useful function or should the calls be removed (we can't
> >> really remove it since it's a public API now ...)
> 
> Please don't remove any calls to xslHandleDebugger() as this is CRITICAL to 
> the debugger working! I've checkout your version 1.0.8 that has 
> xsltHandleDebugger removed the build fails with debugging enabled. Please 
> surround the xslHandelDebugger with a #define it you want. But  I'm sure that 
> as it is there will be problems for  at least win32 platforms.

  Hum, I don't remember removing anything. I applied your last patch that's 
all...

> I've not plan for putting content into this function it is just a hook into 
> my code. The linker does its magic and it just works! This does mean that 
> xsldbg will always need to be dynamically linked. I don't think it is 
> possible to overloaded functions from a static library. ?

  I think this just won't work with most compiler chains. When module A and
module B are in the same library, most linkers resolve statically references
from A to B when generating the library, shared or not. This construct is
doomed to fail on most platform/compiler chains whether the libraries are
shared or not.


> Daniel : The patches you made to include  lib*.la to be added to a new  
> library this are troublesome. Would you add a configure parameter to avoid 
> using them.

It's the wrong approach to the problem. Using the linker to put in place an
overtride mechanism was just plain wrong. I should have been more careful
I really expected the breakpoint code to be the actual implementation not
dummies references to functions possibly implemented by other modules.
Moreover as the Linux platform is moving toward prelinking the current
mechanism will fails.

In a nutshell, the current mechanism is:
  - unportable
  - garanteed to fail on mosty serious toolschains
  - very different from the callback mechanisms specified everywhere
    else in the libxml2/libxslt APIs.

I intend to fix this mess by:
  - providing a callback registration API
  - make the various existing dunny function call the registered APIs
    if they are there.

Daniel

-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard@redhat.com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/