Re: Fix linking of libxsltbreakpoint (Re: [xslt] Release of libxslt-1.0.31)

[Daniel Veillard <veillard redhat com>]

On Thu, Jul 10, 2003 at 10:08:48AM +0200, Peter Breitenlohner wrote:
> On Wed, 9 Jul 2003, Daniel Veillard wrote:
> 
> > On Wed, Jul 09, 2003 at 04:29:04PM +0200, Karl Eichwalder wrote:
> > [...]
> > > -libxsltbreakpoint_la_LDFLAGS = -version-info @LIBXSLTBREAK_VERSION_INFO@
> > > +libxsltbreakpoint_la_LDFLAGS = -version-info @LIBXSLTBREAK_VERSION_INFO@ $(top_builddir)/libxslt/libxslt.la
> >
> >   Eh, thanks, but honnestly I don't really see why :-)
> > libxsltbreakpoint is an empty library, its content was completely removed as
> > it was deprecated, I just kept it around to ensure binary compatibility.
> > It just exports the deprecated function entry points, nothing should really
> > link against it, it's an empty nutshell.
> 
> All the above may be true, BUT the shared version libxsltbreakpoint.so
> does contain the deprecated entrypoints that have undefined external to be
> resolved via libxslt->libxml2. Thus, on a (linux-gnu) system with shared libs,
> 	gcc /usr/local/lib/libxsltbreakpoint.so
> fails without Karl Eichwalder's patch but (sort of) succeeds with that patch
> (fails since there is no main program).

  I totally fail to see the point of running such a command.

> Moreover, whoever links against libxsltbreakpoint most probably also needs
> libxslt, so why not code this dependency into the library (resp. the .la file).

  *nothing* should link against libxsltbreakpoint. If they do there is
an error which need to be fixed. That's why I'm raising the red flag
about this.

> Conclusion: I fully support Karl Eichwalder's patch (apart the fact that
> maybe the whole question obsoletes itself together with libxsltbreakpoint).

  I do not understand your reaction. How can you "fully support" this,
do you use that library ? If yes you should not. The only dependancy
to libxslt is about an xsltGenericError message.
Of course I have no technical problem making that change, the problem
is elsewhere, nobody should use that library, except those programs compiled
against a very old release who may still have shared lib references to
the .so and those need to be spotted to be fixed.

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/