Re: pango-1.8.0 compilation error



On Tue, 2005-01-11 at 21:43 -0500, Chris Mazuc wrote:
> Wed, 22 Dec 2004 19:51:11 -0800
> Glenn Evans wrote:
>  >
>  > When I run make for pango-1.8.0, I get the following errors:
> 
> [ blah blah blah ]
> 
>  > ./.libs/libpangoxft-1.0.so: undefined reference to
>  > `g_type_instance_get_private'
>  > ./.libs/libpangoxft-1.0.so: undefined reference to
>  > `g_type_class_add_private'
>  > ./.libs/libpangoxft-1.0.so: undefined reference to `g_assert_warning'
>  > /home/user1/downloads/pango-1.8.0/pango/.libs/libpango-1.0.so:
>  > undefined reference to `g_unichar_get_mirror_char'
>  > /home/user1/downloads/pango-1.8.0/pango/.libs/libpango-1.0.so:
>  > undefined reference to `g_fopen'
>  > ./.libs/libpangox-1.0.so: undefined reference to
>  > `g_return_if_fail_warning'
>  > collect2: ld returned 1 exit status
>  > make[4]: *** [pango-querymodules] Error 1
> [ blah blah blah ]
>  > I have successfully installed all the other required packages,
>  > including glib-2.6.0 (pkg-config --modversion glib-2.0 returns
>  > "2.6.0"). My current version of pango is 2.4.0. gtk+-2.6.0 will not
>  > install unless pango is 1.7.0 or later.
>  >

Basically, this is a sign of mixed versions of glib-2.6.0 and something
older. You are likely finding the 2.6.0 headers but linking against 
glib-2.2. 

I'd very strongly encourage people when building GTK+ from scratch
to do one of three things:

 A) Use packages built for your distribution. (If you are using older
    versions of Fedora or Red Hat, at least back to Red Hat 9 or
    so, I think rebuilding the FC3 packages of GTK+-2.6 should work.
    That is, rpm --rebuild on the SRPM)

 B) Use a build script, such as jhbuild
    (http://www.jamesh.id.au/software/jhbuild/) or garnome
    (http://cipherfunk.org/garnome/)

 C) Not really recommended, but what I do. Install the new packages
    right over your system install by configuring with

     --prefix=/usr --sysconfdir=/etc

    This typically works well, but when things go wrong, they 
    go *really* wrong.

Manually building GTK+ into a separate prefix when an older version
is present in /usr is difficulty.

And just delete any old versions of GTK+ you have in /usr/local.
Installing into /usr/local is almost certain to cause problems later,
even though it is the default install location 

Regards,
						Owen

Attachment: signature.asc
Description: This is a digitally signed message part



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]