Re: libtool ignorant of lack of headers in /usr

[Carol Spears]

On Mon, Oct 17, 2005 at 06:30:45PM +0200, Ralf Wildenhues wrote:
> Hi Carol,
> 
> * Carol Spears wrote on Mon, Oct 17, 2005 at 05:46:48PM CEST:
> > 
> > i am using (GNU libtool) 1.5.20 Debian 1.5.20-2 (1.1220.2.287 2005/08/31
> > 18:54:15) to build glib, pango and gtk+ from cvs.
> 
> OK.  Which architecture are you on?
> 
address@hidden:~$ uname -a
Linux treva 2.6.9 #1 Sun Feb 13 11:44:32 PST 2005 i686 GNU/Linux

whatelse would you like to know?

> > all of the other tools respect that i have allowed the distribution to
> > install this software in /usr and my build system uses the stuff i
> > installed in /usr/local to build with.  i am having a difficult time
> > finding the words to express this problem.  let me paste the compiler
> > spew:
> > 
> > first:
> > if gcc -DHAVE_CONFIG_H -I. -I. -I.. -DG_DISABLE_DEPRECATED
> > -DPANGO_DISABLE_DEPRE
> > CATED -DG_DISABLE_CAST_CHECKS -I.. -I/usr/include/cairo   -pthread
> > -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include
> > -I/usr/include/freetype2  
> >   -g -O2 -Wall -MT argcontext.o -MD -MP -MF ".deps/argcontext.Tpo" \
> >   -c -o argcontext.o `test -f 'argcontext.c' || echo'./'`argcontext.c; \
> > then mv -f ".deps/argcontext.Tpo" ".deps/argcontext.Po"; \
> > else rm -f ".deps/argcontext.Tpo"; exit 1; \
> > fi
> >     
> > this portion is clearly working correctly.  i am using freetype from the
> > distribution (there has not been many changes for a very very long
> > while) and the same with cairo.  i have built my own glib in /usr/local
> > and the tools find this and use it appropriately until libtool takes
> > over:
> > 
> > /bin/sh ../libtool --mode=link gcc  -g -O2 -Wall   -o pangoft2topgm
> > pangoft2top
> > gm.o renderdemo.o argcontext.o ../pango/libpango-1.0.la
> > ../pango/libpangoft2-1.0
> > .la -lfontconfig   -lfreetype -lz 
> > gcc -g -O2 -Wall -o .libs/pangoft2topgm pangoft2topgm.o renderdemo.o
> > argcontext.o  ../pango/.libs/libpango-1.0.so 
> > ../pango/.libs/libpangoft2-1.0.so -lfontconfig /usr/lib/libfreetype.so -lz
> > ../pango/.libs/libpango-1.0.so: undefined reference to 
> > `g_intern_static_string'
> > collect2: ld returned 1 exit status
> > make[2]: *** [pangoft2topgm] Error 1
> > 
> > the way i understand it, libtool is finding .la files that were
> > installed by debian.  this breaks an otherwise sane build system.  this
> > negates anything that ldconfig does. 
> 
> I don't understand you at all.  Might be a language barrier, or
> something else.
> 
yes.  i am a user.  i went from playing star trek and adventure on a
teletype machine in 1982 to more than a decade of nothing computer at
all and then a big jump into gnu stuff  in 1998.  i know a lot and know
nothing at the same time.  language will be a problem.

> What do you expect to happen?
i expect that when the compiler linker knows to use the files from
/usr/local that libtool will also.

> Which package is this that you are building (sorry if the question seems
> dense to you)?
not at all.  my goal is to build my desktop (xfce), my graphics app
(gimp) and my media player (whatever i can get to build by then) from
whatever version control sources i can.  they all use the same widget
set -- gtk+.  gtk stands for gimp tool kit.  gimp stands for GNU Image
Manipulation Program.  gtk+ has some dependencies.  cairo, keith
packards new project which to me looks like an attempt to free the free
world from xfree86 and also give postscript abilities that were lacking
in X.  i let debian install X from X.org and cairo.  i am pretty good at
building things, but not that good.  i requested cairo-dev from them,
for instance.

i started with glib.  glib is a gnu wrapper around libc.  right now, on
my computer i have a functional glib installed in /usr/lib and a fully
enabled newer glib installed in /usr/local/lib.  every single tool in
the build system understands this with the exception of libtool.

the broken build is pango, the font renderer.  it seems to break during
testing which means (i think) that the build is complete.  this does
nothing to help with my aggravation level.

> Could you paste the .la files referenced in above link line?
> 
i would like libtool to see this file:
address@hidden:~$ ls -l /usr/local/lib/libglib-2.0.la
-rwxr-xr-x  1 root root 829 2005-10-16 22:54
/usr/local/lib/libglib-2.0.la

instead libtool sees this file:
address@hidden:~$ ls -l /usr/lib/libglib.la
-rw-r--r--  1 root root 714 2005-05-04 03:13 /usr/lib/libglib.la

> > can this be fixed?  in my world, the gnu tools used to provide sanity.
> 
> No need to get rude.   I could guess that you are seeing an effect of
> the `link_all_deplibs=no' patch which is part of Debian's libtool but
> not of GNU libtool.  If this were true, I guess that libpango (or one of
> its deplibs) was/were missing a `-L/path/to -lglib' in their link line.
> Mere speculation though, because of reasons given above.
> 
i am sorry, i did not want to appear rude, i wanted to appear as an old
and semi-seasoned fan of gnu build tools who is confused and
disheartened because it doesn't work any longer.  i love the gnu build
tools.  no matter how my current frustration appears here, please
understand this underlying love.

> (another reason may be that whoever provided your CPPFLAGS with the
> -I/usr/local/include entry should've also provided LDFLAGS with
> -L/usr/local/lib or similar; but then again, `-lglib' does not even show
> up in the line beginning with `/bin/sh ../libtool --mode=link', so that
> seems rather unlikely)
> 
i am using a shell script to make my build go easier.  i actually had to
heavily edit this document:
http://www.gimp.org/source/howtos/stable-cvs-build.html and my shell
script is this with some personal cvs stuff edited in:
http://www.gimp.org/source/howtos/gimpenv

maybe i am just in need of a way to tell libtool to look only in
/usr/local

the one thing i understand is that i do not understand the reasons my
build system was successful for so long.  it is causing me problems
understanding the reason it is suddenly broken as well.

humbly,
carol