trying to upgrade gtk... agh!!

[Vdubjunkie]

I installed glib 2.0.7 from tar.gz This went off more or less without a hitch.

Next I attempted to install atk 1.0.3 from tar.gz, but pkg-config apparently reported NO version for glib.

I know I'm exposing myself and my "green-ness" but I'm not sure why pkg-config doesn't know, or how to make it know the glib v. I remembered one time using ldconfig to "update" something when attempting xine, so I tried that. Still no go.

I run two seperate MD machines, 8.2 and 9.0, and I seem to have quite a few problems when attempting to install/upgrade wherein versions are either reported as insufficient or nonexistent.

I prefer to install from tar.gz because I think I will learn more that way, so I respectfully ask that nobody attempt to steer me in the direction of rpms unless someone I repect like Aru :lol: gives me reason to think I should avoid tar.gz's when rpms are available. I'm starting to wonder about this..

 

Oh yeah, I had to

export PKG_CONFIG_PATH=/usr/local/bin:/usr/lib/pkgconfig

to get GLIB installed in the first place. That was hard to find.

So, my questions are as follows:

• Why does pkg-config misreport.. what do I do to keep it "in the know"?

Is there a reason I should use/not use tar.gz vs. rpms?

What the heck is the purpose of ldconfig?

Any thoughts on why a lot of the programs I install are in, for example:

/usr/local/bin instead of /usr/bin like they are expected to be?

 

Somewhere along the way I learned to run ./configure and make as a normal user whenever possible and do the make install as root. I've always done that, but sometimes found it necessary to su for the make procedure to complete without errors. Don't know if that is helpful or if somebody may have thoughts about that as well..

[bvc]

Well, I can't come close to bash4breakfast/lunch/and dinner-Aru...and I may be wrong....I can only tell you how I see it. When you use a tarball, and pkgconf, you're dealing with sources and programs that aren't normally used, or made to run on rpm-based sytems. They can be made to do so, in most cases, but they're not usually built with that purpose. In building an app from a tarball, if it finds deps in /usr instead of /usr/local, it's because person that made the source/source tarball told it to look there. If it doesn't find /usr, then you have to tell it to;

./configure --prefix=/usr

Isn't this the purpose of pkgconf? This, I know you've figured out....everyone does the first time around. When I built waimea-wm by tarball, it said it couldn't find Imlib.h. It was looking in /usr/local/includes which on an rpm-based sys (mostly default) is empty. I had to tell it to look in /usr with --prefix=/usr. I also tried to build a waimea-x.x.x-xxx.src.rpm, and it said that I needed Imlib-x.x.x-mdk.xxx.rpm when I had libImlib rt version.

Is there a reason I should use/not use tar.gz vs. rpms?

If you want to learn it, and write everything you do down so you know what is and isn't, go ahead. A reason? No...the question is, how much time do you have and what are you willing to learn?

 

 

 

What the heck is the purpose of ldconfig?

[bvc@localhost bvc]$ urpmf --summary --description --name ldconfig

ldconfig:summary:Creates a shared library cache and maintains symlinks for ld.so

ldconfig:description:Ldconfig is a basic system program which determines run-time link

ldconfig:description:bindings between ld.so and shared libraries. Ldconfig scans a running

ldconfig:description:system and sets up the symbolic links that are used to load shared

ldconfig:description:libraries properly. It also creates a cache (/etc/ld.so.cache) which

ldconfig:name:ldconfig-2.2.5-16mdk.i586

 

 

 

Any thoughts on why a lot of the programs I install are in, for example: 

/usr/local/bin instead of /usr/bin like they are expected to be?

/usr/local/bin=tarball

/usr/bin=rpm

 

Have you looked at ./configure --help for options? I believe you can either tell it which and where your glibc is, or edit the makefile.

 

You could use rpmbuild to do the same thing as a tar, and it looks in the rt places. It also excepts ./configure options, but to what extent I'm not sure because I haven't had to use them much. :wink:

[Vdubjunkie]

I feel like I pretty much get everything you are saying. I guess my question then would be..

on a "non-rpm based system" there wouldn't really be a utility running in linux that tells the compiler(lack of more correct term) where to look for various programs?.. and it more or less relies on what it has been told (by the person writing the script) about where the program should be or where the person compiling it tells it the program should be(i.e. --prefix=..)

i know that is a bit convoluted, but..

I think this may help a lot..

But I still feel a little unsure of exactly why pkg would incorrectly report version numbers.. maybe if I think back, some of them maybe just weren't reported at all, still coming up with the generic program=>v. requirement message. But I know some of it comes up with bad numbers. Perhaps I am not completely cleaning out old versions of programs and pkg is still looking in their directories to find v#.

Does that theory make any sense to anybody else?

[bvc]

I thought pkgconfig was suppose to work with mdk. May you should try to install the pkgconfig rpm from texstar. I installed it, but haven't needed it yet. I don't understand why it would report wrong v#'s. I can see not finding, but not wrong v#'s.

 

pkgconfig-0.14.0-1tex.i586.rpm

ftp://ftp.ibiblio.org/pub/Linux/distribut...drake/9.0/rpms/

 

You could use rpmbuild to do the same thing as a tar, and it looks in the rt places.

I should have said; You could use rpmbuild to do the same thing as ./configure, make, make install, and it looks in the rt places.

[aru]

I prefer to install from tar.gz because I think I will learn more that way, so I respectfully ask that nobody attempt to steer me in the direction of rpms unless someone I repect like Aru :lol: gives me reason to think I should avoid tar.gz's when rpms are available.  I'm starting to wonder about this..

 

You should avoid tar.gz when rpms are available!!! :P

 

If you want to deal with tar.gz (tgz) w/o compromising your system with later rpm's updates, install a real man's distro like Slackware.

 

Btw, If you want to play with your system, don't use pkg-config(1), install the tarballs by hand... or buid a rpm package from the tarball (rpmbuild)

 

I suscribe 100% what bvc said (btw, bvc, you forgot to say that I use the bash reference manual as my pillow, there is plenty of time between dinner and breakfast, isn't it?)

 

(1) why? because there are many chances of messing your system. By hand you have 100% of control of what you're doing, and is up to you to take control of what you are installing, when and where. This principle can be applied with rpm vs urpmi et al.

[Vdubjunkie]

Looks, then, like I may be on my way to upgrading to a real man's distro..

I'm sick of hunting down 15 rpm dependencies only to find that one which the whole thing hinges on isnt available and freaking with that mess for HOURS just to get damned mplayer gui working for CHRIST"S SAKE !!!

 

...

.

 

ok, im all better now. Thanks for letting me vent here on the pages of Mandrakeusers.org

[bvc]

I completely understand. B4 ML9.0 I almost had an updated ML8.1 done by hand and gnorpm. A very respected Mod from the old board would always suggest as he did....keep one mostly default install and have another for tinkering. Now, I use urpmi and have only had one rpm that it didn't find and I couldn't find either, but I was able to tell rpm where the libs were with a configure option. There's also apt (apt-get for mdk from texstar) and synaptic from texstar. I havent used either yet but have installed them recently with plans to try them out. Many have found they like these better than urpmi.

 

I don't think you'll find yourself saving any time by going with a real mans distro, because you'll be having to compile all the pkges, but you'll learn a lot and you sound like the kind that will have fun doing so. You'll also have the benefit of everything be built from source, and on slackware and others the result will be a flying machine. :wink: