Re: bind_textdomain_codeset error while building gnomevfs



On Wed, 2002-05-22 at 09:22, Robert Staudinger wrote:
> 
> At the moment I'm building 0.10 on my debian potato and it seems like
> the settings in gar.conf.mk don't make a single package build (only
> from those which would otherwise spit an undefined reference to
> bind_textdomain_codeset of course).

I'm having similar (but worse) problems. I'm new to GARNOME as of this
evening, but it looks really good. Sadly it's falling over on my box
when it gets to gnome-vfs.

The output is essentially the same as everybody else has posted:

gcc -g -O2 -o .libs/test-async test-async.o
../libgnomevfs/.libs/libgnomevfs-2.so -L/home/gashton/garnome/lib
/home/gashton/garnome/lib/libbonobo-activation.so
/home/gashton/garnome/lib/libxml2.so -lz
/home/gashton/garnome/lib/libgconf-2.so
/home/gashton/garnome/lib/libORBit-2.so -lm
/home/gashton/garnome/lib/liblinc.so
/home/gashton/garnome/lib/libgmodule-2.0.so -ldl
/home/gashton/garnome/lib/libgobject-2.0.so
/home/gashton/garnome/lib/libgthread-2.0.so -lpthread
/home/gashton/garnome/lib/libglib-2.0.so -lrt -Wl,--rpath
-Wl,/home/gashton/garnome/lib
../libgnomevfs/.libs/libgnomevfs-2.so: undefined reference to
`bind_textdomain_codeset'

I find that setting LDFLAGS, PATH and LD_LIBRARY_PATH and re-running
configure and make manually (as described in one of your earlier posts)
from work/gnome-vfs-1.9.15 has absolutely no effect, however.

I started out with gettext 0.10.35 installed, which doesn't define
bind_textdomain_codset, so I removed it and upgraded to 0.11.2. I then
checked to see if bind_textdomain_codeset was defined anywhere, but it
appears to be in libintl.so, not libgettextlib.so:

% find /usr/local/lib -print | xargs nm --print-file-name 2>/dev/null |
grep bind_textdomain_codeset
/usr/local/lib/libintl.a:intl-compat.o:000000fc T
bind_textdomain_codeset
/usr/local/lib/libintl.a:intl-compat.o:         U
bind_textdomain_codeset__
/usr/local/lib/libintl.a:bindtextdom.o:00000388 T
bind_textdomain_codeset__
/usr/local/lib/libintl.so.2.0.1:00001c24 T bind_textdomain_codeset
/usr/local/lib/libintl.so.2.0.1:00002020 T bind_textdomain_codeset__
/usr/local/lib/libintl.so.2:00001c24 T bind_textdomain_codeset
/usr/local/lib/libintl.so.2:00002020 T bind_textdomain_codeset__
/usr/local/lib/libintl.so:00001c24 T bind_textdomain_codeset
/usr/local/lib/libintl.so:00002020 T bind_textdomain_codeset__

So I modified my LDFLAGS to include both libintl.so and
libgettextlib.so, and tried again. No dice. I've been trying to get out
of this situation for about four hours now, and haven't made any
progress.

It's infuriating -- I really want to have a play with GNOME 2, and I
must have invested over 24 hours of solid time to it in total. :(

Can anybody help me out here? I'm as interested in helping solve the
generic problem (i.e. finding a bug fix, or whatever) as getting GNOME 2
working on my box, but I think I'm starting to get in over my head, so
need guidance.

> --with-gnu-ld doesn't seem to be required (for "problem garballs"?)
> adding -L/opt/gnome2/lib/libgettextlib.so or 
> /opt/gnome2/lib/libgettextlib.so to the LDFLAGS in gar.conf.mk doesn't
> do the job.

I can confirm that it didn't help me either.

> What works for me is the painful way
> when the build stops:
> - open terminal 2
> - make sure $(prefix)/bin is in the PATH, LD_LIBRARY_PATH contains
>   $(prefix)/lib and LDFLAGS=/opt/gnome2/lib/libgettextlib.so is set
> - get ./configure arguments from config.log
> - make clean, reconfigure, make, make install
> - continue make install in terminal 1

I followed that to the letter. No joy.

> Any suggestions how to ease the process are welcome.

Amen to that!

I'm running Trustix 1.5 (based on Red Hat 7.x -- I forget what x is),
though most stuff has been compiled from source (recently), including
GNOME 1.4.

P.S. What is a garball, exactly? Is it one of the directories that
contains a package?

-- 
Graham Ashton



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