Re: [xslt] linking of libexslt
- From: Daniel Veillard <veillard redhat com>
- To: xslt gnome org
- Subject: Re: [xslt] linking of libexslt
- Date: Thu, 23 Oct 2003 18:52:42 -0400
On Thu, Oct 23, 2003 at 12:45:01PM -0400, Daniel Veillard wrote:
> On Thu, Oct 23, 2003 at 10:54:12AM -0500, Graham Wilson wrote:
> > On Mon, Oct 20, 2003 at 02:43:44AM -0400, Daniel Veillard wrote:
> > > > Also, there is code in libexslt's Makefile.am (although it is commented
> > > > out) which links libexslt against the recently-built libxslt, instead of
> > > > the system libxslt. Why is this commented out? Isn't this the right way
> > > > to do it?
> > >
> > > Because dependancies between "being built" libraries is a problem in
> > > practice. It is very likely that I did so to ensure that the common case
> > > I can test and debug and must have working do indeed work.
> > > I takes patches about configure/Makefile and shared libraries but with
> > > a lot of caution, because usually I get patches which work for the platform
> > > or the use case for which the person was interested in but tend to break
> > > othert setups. It is extremely hard to assess that there is no regression
> > > in configure/Makefile patches.
> >
> > I have applied the attached patch to the Debian libxslt package, and it
> > sucessfully compiles on 11 different (Linux) architectures.
>
> the patch failed with breakpoint/Makefile.am in CVS where
> libxsltbreakpoint_la_LIBADD is defined as empty.
> Now the fact that it builds on a number of arches but on a similar setup
> does not imply that it will build for example within an RPM build root
> where prelinking is activated and where the build root is not the
> install root. I think this is the answer to your initial question
> "Why is this commented out? Isn't this the right way to do it?"
> If you have a build root, the $prefix can be
> /var/tmp/libxslt-1.0.34-root/usr/and the prelinking should still
> be done against /usr/libxml/libxml2...
> I did that patch to cope with this kind of setups I think. I'm afraid
> your patch just removes it but doesn't test that this still works. And if
> the result is that the package don't build out of the box on Red Hat
> buildsystem, well I will have to "fix" it before any release. So I feel
> quite uneasy applying your patch blindly, I will need to check it out
> on various setups first making sure what I tried to handle in the first
> place is not gonna come back after your removed it !
Okay, I managed to get sucessful rpm builds too with that change (minus
the libxsltbreakpoint_la_LIBADD), I still can't remember why I had to go though
the tortuous exercise of the INSTALLED_XSLT_LIB trick. Well it may come and
bite me later but so far the patch looks okay, so applied and commited !
thanks,
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/
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]