Re: problems building gtkhtml-3.8.2

roN wrote:

I started with gtk 2.6.4 annd glib 2.8.4 that's what Suse provides with
suse 9.3.

and with the "devel"'s of them both?

I now installed glib2 2.6.3 and gtk2 2.6.4 both, to avoid compiling
problems, as rpm from rpmseek.com.

Ed says a lot, but... you are mixing differnt versions of a lib on your
system "to avoid compiling problems" .... that is something you probably
should not do. It doesn't work like "the more stuff of it I have, the
better it is..."

A few things to considder (I'm not too much of a professional either, and
I'm not a native english speaker, but I'll point it out as far as I know
it):

1.) Evolution
Evolution is quite a sophisticated, most comlicated piece of software - by
the way, are you running gnome or KDE? If gnome, you have more chances
that needed libraries are allready there in place for other things to do.
But if KDE, you need every single gnome lib for every single app that
might request it. Evolution does quite a job and from that alone I'd
guess if something is more complicated to build, in must be an office
suite or so. I don't say that to frighten you but more to point out why
this doesn't work out of the box. Be patient, it should work in the end.
It must!

2.) Compiler
The compiler needs source- and object files to link them together with
other sources that come in those tgz-files (like from sourceforge) and
then builds binaries from all this which fit neatly into your particular
system.

Packages usually have binaries and configuration files. Devel-packages in
turn (hence the name "development packages") have additional sources and
information a compiler might need.

3.) rpm
rpm is a packet manager (originally "redhat packet manager"). It holds a
package database on your system to provide information to it what is
installed and in which version.

Thus, if you first install an rpm, for example, then afterwards get the
same thing as source-tgz in a different version and compile it, then the
rpm database won't know the second version is there!

But compilers usually don't care for rpm's anyway... They just look around
what they see from what "./configure" says should be there.

Other distibutions use different packet managers, like deb on debian for
example. But sources should be plattform independent, so "./configure"
shouldn't be asking for packat managers (don't know if it does sometimes)

4.) ldconfig / ld.so
There is another "database" on the system, regardless of which packet
manager is there. It serches for libraries in a path that the command
"ldconfig" either gets from the commandline or from the file
"ld.so.conf".

The reason is simply not to have to look for libraries which are spread
through out the filesystem, maybe different partitions on various disks -
just to know if they are there. So, if only the information is needed but
not the file itself, only the ld.so is being looked at which is *much*
faster.

This in turn means: If you just unpack a tgz and spread the files, but
then don't run "ldconfig", this database has no entry. Despite the files
being somewhere around. Badly built rpms and "./configure" files forget
this to be the last thing to do automatically, so don't count on that!

By the way, when YaST says "linker cache" before starting SuSEconfig
(don't know how it says in the english version) - this is it!

5.) SuSE is special about certain things, like paths to important system
files and the way it is configured(SuSEconfig and everything
in /etc/sysconfig). That makes it easy as long as you only use SuSE
automatisms, but makes it more complicated if you want to do things on
your own. Because if you find information on the internet how to do it,
you might also need to figure out what is different in SuSE from any
thing else in the linux world. (makes me sound like ... well, no! I am
using SuSE :)

To make it short: The more of these things get mixed without knowing about
each other, the more it is likely they'll be giving different answers to
the very same question. Which usually makes a compiler stop.

So maybe it's the best way now to kick out all of those things again (so
that rpm and ld.so know they are gone) and re-install only those that
belong together plus their devel packages. From that point on, the
compiler should only complain about packages that are really still
missing. You need to get back to a clean start, i think. It's easier to
watch things happen.
.

Relevant Pages

  • Re: problems building gtkhtml-3.8.2
    ... I guess not, Suse doesn't install devel's in the beginning, eh? ... information a compiler might need. ... rpm is a packet manager. ...
    (alt.os.linux.suse)
  • Media Tray Empty - SuSE 9.1 Solved
    ... and has, after all, worked fine in SuSE 9.0 on the same machine. ... so I just told Yast to ignore those for the time being. ... I then installed the *old* cups-related rpm files from my SuSE 9.0 Pro ... CDs and proceeded to install the downloaded ghostscript files, ...
    (alt.os.linux.suse)
  • Re: [SLE] Epiphany issue
    ... Just reading everything to be found on a topic, ... things shortly after I install the latest SuSE, ... SuSE release, then my shambles remains and my motivation ... rpm database and YaST's/YOU's usefulness) ...
    (SuSE)
  • Re: RH to SUSE
    ... I use SUSE at home ... RPM -- can be used as on Red Hat, ... Windows users say Linux has to be more "Windows- ... you can't find an RPM for your distro, ...
    (alt.os.linux.suse)
  • RE: [SLE] Frustration!
    ... Isn't this an RPM problem, not a SuSE problem? ... this might be to build a new RPM for gdk-pixbuf using your updated xine ... If I choose to download and install fresh ...
    (SuSE)