Re: pango makefile fix breaks gtk build
- From: Carol Spears <carol gimp org>
- To: Tim Janik <timj imendio com>
- Cc: gtk-devel <gtk-devel-list gnome org>
- Subject: Re: pango makefile fix breaks gtk build
- Date: Fri, 2 Dec 2005 08:54:45 -0800
On Fri, Dec 02, 2005 at 09:58:31AM +0100, Tim Janik wrote:
> On Thu, 1 Dec 2005, Carol Spears wrote:
> >
> >i have been for years struggling with pango. it refused to build from
> >cvs into /usr/local/lib (the default) while my distribution had a version
> >in /usr/lib
> >
> >i changed a few things in the pango makefiles. the patch can be
> >reviewed here:
> >http://bugzilla.gnome.org/attachment.cgi?id=55457&action=view i did not
> >add the patch until pango was able to build without fail. it seems that
> >this has broken the build of gtk+ from cvs head today.
>
> your patch simply adds a glib library dependency in one place and is just
> chaging whitespaces in the others.
>
mclasen mentioned this whitespace online as well, if it is a problem
with the patch that i attached to that bug report, then it must also be
a problem in the other patch that is there?
i thought that making the files easier to read was good. i am seeing
that this is perhaps not the case, but fixing me with this will not fix
the problem. i have only made one patch for files like this so far.
pango is not dependent on glib?
i thought that what i did was add the glib environment variable to the
build. without that, the build finds glib in other places.
> >
> >it is not supposed to be like this. can someone fill in the details
> >about how that fix to pango breaks gtk+? it should have helped it.
>
> could you please:
> a) build the glib/cairo/pango/gtk toolchain without any patches to figure
> whether you still have any problems doing that
i did this for years already. it seems that there is one build tool
that refuses to play well with the other build tools as far as
distributions vs. homemade software goes. better for me to talk to them
again than to go through that again.
> b) outline the actually build error you're running into (in this case copy
> the relevant build log excerpt from gtk) if you run into problems
it is too simple to need pasted errors. i want to have software
installed from my distribution and i also want to build my own using
"fresher" or even cvs builds in /usr/local/. the build archetecture to
do this is so close to being there to allow this, except for one of the
build tools.
i had a lesson in how to set the rpath when running software that uses
things like pango and gtk+ yesterday. i understand that the complexity
helps people who are using, maintaining and fixing several versions. it
is so well designed though, that it can almost (almost) work for the
more simple case that i am trying to make it work.
> c) if we still can't get things fixed, try building the toolchain with
> jhbuild, we can give hand holding on how to do that on #gtk+
>
i don't know jhbuild. with all due respect, it is too easy to type
./autogen --help or ./configure --help myself than to learn yet one more
software whose task would be to type this for me. ;)
>
> >
i am sorry that i posted the email here about this. it is not a problem
with gtk+ as i thought. in my defense, i was feeling really good about
fixing the problems with pango.
i am going to approach the people with the problem build tool -- it is
so close to running very very simply or as complex as you might need it.
however, there has been such a stink about the way i cleaned up the
patch before submitting it -- i might have uncovered a need to fix yosh
and this should be approached with the same level of "concern" i guess
to make me think that it is really as unacceptable as it seems.
thanks for answering,
carol
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]