Re: Amateur e.

["Stephen J. Turnbull" <nospam [at] sk.tsukuba.ac.jp>]

>>>>> "Harvey" == Harvey Kelly <harvey [at] kelly.uklinux.net> writes:

    Harvey> Aha!  I meant I downloaded it, ran gunzip and tar, then
    Harvey> ./configure, make and make install.

OK.  What exactly was the "configure" invocation?  Just that, or did
you use any switches?  The most important switch for this purpose is
"--prefix", which is usually defaulted to "/usr/local", the hierarchy
reserved for files not under the distro's management.

    Harvey> I used SuSE's YaST to un-install the packages, and the
    Harvey> package manager to install the new?  I just ran them from
    Harvey> a terminal, did I do something naughty?  I'm a bit
    Harvey> confused...

Nothing naughty, but unless you keep track of exacly what you did it
can be hard to diagnose bugs.  Where where the newly built libraries
to start with?  Where did you put them?  And where are the includes
.. oops ...

    >> Put libraries that depend on X in /usr/X11R6/lib/, that's a
    >> good boy, and those that don't in /usr/lib/.  Then run
    >> ldconfig.

    Harvey> Oh, I see...

.. one thing I forgot: to do development you need the header files.
These often live in /usr/include/<library-short-name> or in
/usr/local/include/<library-short-name>.  If there's only one, often
it lives in /usr/lib/<library-short-name>.h.  If the ./configure
script for the application or library you are currently building is
well-written, the dependency library found by `ld' will be checked
against the includes found by `cpp'.  If they do not match,
./configure should complain.  (If you're really lucky it will tell you
"version found in /usr/include/blah.h doesn't seem to match
/usr/lib/libblah.so".  But that level of care is unusual.)

    Harvey> Thanks for helping me out, I'm going to try and do it the
    Harvey> "long way", but if I start screaming at the monitor again
    Harvey> I may have to try and use RPM's.

I don't want to discourage that, but you may not be able to get the
most up-to-date libraries that way.  Or, for very complex programs
(eg, Emacsen, ghostscript) you may want a special configuration that
is suited to your usage pattern.  Decide what you need.  Build the
ones you want to, use RPM when the stock version will do.

And despite my comments about RPM, it is an extremely important tool
for the expert sysadmin.  If you find yourself building a fair number
of packages (to get the bleeding edge, to apply third-party patches,
etc, etc), like Jules strongly advise you to learn the rudiments of
package construction and use locally built packages to manage your
local installs as well as your distro upgrades.

SRPMs are a good source of examples.  I don't recommend doing it this
time, but if you have space and time, the next time you build the
Enlightenment stuff, get the most recent SRPM, unpack it, then get the
bleeding edge source, unpack that, and start looking at the RPM stuff
in the SRPM tree, and move it over to the bleeding-edge tree when you
understand what it does (or use the appropriate options to rpm to
build it yourself---I believe dynamic library dependencies can be
constructed that way, eg).

Warning: this takes a lot of time, the first few times.  But it's
worth it, IMHO.

(I don't know much about RPMs, though---ask Jules.  I'm a .deb kinda guy!)

-- 
University of Tsukuba                Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences       Tel/fax: +81 (298) 53-5091
_________________  _________________  _________________  _________________
What are those straight lines for?  "XEmacs rules."
---------------------------------------------------------------------
Sheffield Linux User's Group - http://www.sheflug.co.uk
To unsubscribe from this list send mail to
- <sheflug-request [at] vuw.ac.nz> - with the word 
 "unsubscribe" in the body of the message. 

  GNU the choice of a complete generation.