./configure --prefix=/usr [default: /usr/local] why???
 

Hey people! I was having a problem about installing a new version of gtk, atk, glib, cairo and pango as described in this thread:

http://www.linuxquestions.org/questi...d.php?t=457899

As you can see, ./configure from atk was not finding glib, because it was installed in /usr/local . So I needed to use ./configure --prefix=/usr not only on glib but in all the other packages . My question is: why? I am still a little nb in Linux and I don't understand why ./configure doesn't find glib in /usr/local, why it has to be in /usr and if there is any way to change that.

Thanks! :)

that's just the "slackware way" as far as locations are concerned... pretty much all of the packages you build for slack will need --prefix=/usr specified for ./configure, unless the default install prefix is already /usr, of course... sometimes you can get away with a /usr/local prefix, and sometimes you can't... my suggestion would be to use /usr whenever possible...

some programs need to be referenced in the pkgconfig path.
if a configure can't find the dep it's looking for it
will usually tell you this and how to manually specify
a different path. if libs are concerned, you would need
to make sure their path is defined in your ld.so.conf

According to the stadards, /usr/ contains the distro-provided packages. Add-on packages are supposed to go to /usr/local (or sometimes /opt).

Slackware-current already has up-to-date versions of gtk etc. If you install a custom compiled package to /usr/loal you can make configure use it by passing suitable arguments (usually like --with-gtk-dir). Probably you will also need to set PKG_CONFIG_PATH to /usr/local as the .pc files of your compiled packages will be in /usr/local/pkgconfig.

I usually do a './configure --help' before I begin to see what options I can pass to the configure. More often then not, there will be an option to specify the location of dependencies.

regards,
...aaron

Hey! Thanks for the answers...so in another dists. there is already a PATH to /usr/local?

i think /usr/local/bin should already be in your $PATH for normal users and root, while /usr/local/sbin should be only in root's $PATH... also, /usr/local/lib should already be in your /etc/ld.so.conf...

Thanks! :) But where do I edit the PATHs?

you can edit the /etc/profile file...

to *see* what's in your current $PATH do a:

if you need to modify the pkgconfig path...
you can just type it on the command line
before running configure.
eg `PKG_CONFIG_PATH=/dir1:/dir2:/dir3:etc`

Thanks guys! So, according to what Ilgar said, about the standards for /usr and for /usr/local, would be a wise idea to install programs which other programs don't depend in /usr/local and programs and libraries which other programs depend to compile/run into /usr? :D

Since /usr/ is supposed to contain the official installations provided by the distro, I wouldn't install there unless necessary. I install things like games, amsn, kile, wine, teamspeak, skype etc. under /usr/local/ or /opt/. If I were to install gtk I'd first remove the installed ones and then install mine to /usr, however. There could be programs expecting to find gtk there. Installing to /usr/local should also be fine (pkg-config will tell the applications where gtk is) but who knows what kind of oddities may come up...

If one day you replace your own gtk with official packages, make sure it's uninstalled properly (use checkinstall to make a tgz package for example). Otherwise two different gtks may appear as installed and you'll have some headache when compiling programs...

if they are both on the same partition
it really doesn't matter at all

in fact, putting just about everything
in /usr would be the easier route there

Ilgar, thanks again! :)

I always remove the packages using pkgtool before installing new ones... :)

I think I am making a "tunned Slackware" here :P . Uninstalling many of the original packages and installing newer versions from the source heheheh...

But slackware-current's gtk is already up-to-date. Of course if you're trying the unstable 2.9 branch, then yes, you need to compile yours.