Forum Home
Press F1
Thread ID: 37572	2003-09-11 09:44:00	Removing old version of glib in Red Hat 9	Jen C (20)	Press F1

Post ID	Timestamp	Content	User
174592	2003-09-11 09:44:00	Hi all :) I am trying to compile the new GNOME 2.4 from source at the moment and I have run into a wee problem. When I ./configure Pango I get this error message: checking for pkg-config... (cached) /usr/local/bin/pkg-config checking for GLIB - version >= 2.1.3... *** 'pkg-config --modversion glib-2.0' returned 2.2.3, but GLIB (2.2.1) *** was found! If pkg-config was correct, then it is best *** to remove the old version of GLib. You may also be able to fix the error *** by modifying your LD_LIBRARY_PATH enviroment variable, or by editing *** /etc/ld.so.conf. Make sure you have run ldconfig if that is *** required on your system. *** If pkg-config was wrong, set the environment variable PKG_CONFIG_PATH *** to point to the correct configuration files no configure: error: *** Glib 2.1.3 or better is required. The latest version of *** Glib is always available from ftp://ftp.gtk.org/. Now I have already compiled the glib-2.2.3 with no problems and the message above suggests I should remove the old version. This is what is showing currently in the installed RPM logs: glib-1.2.10-10.i386.rpm glib2-2.2.1-1.i386.rpm glib2-devel-2.2.1-1.i386.rpm Those rpm's came either with the installation or I got them from the up2date Red Hat Network site and they would of installed automatically. I really don't want to get this wrong, so what is the best way for me to remove the old version(s). Bear in mind my head is already hurting from trying to figure this out and I will need very easy step-by-step instructions. Any help would be most appreciated :) Cheers Jen	Jen C (20)
174593	2003-09-12 04:23:00	ldconfig is quite important. That sorts out what the library paths are. You don't usually "remove" old libraries; the installation scripts normally just change a symbolic link to point to the new one. Have a look with 'ls -l /lib/glib*" You could also have a look at /etc/lib.so.conf ... without changing anything if you aren't sure. There might be an "obvious" thing you can change. If you compiled the library, did it have a "make install" referred to in its README? If there is, and you didn't do that, do it now, then "ldconfig --help" to see what it says about how to run itself, then run that. Those two steps should be enough. Changing libraries can be dangerous (most of the system commands use shared libraries ... if the libraries they need are changed to ones that don't work with them, things get messy :)) Even removing a symbolic link to one of the essentials, so it can be replaced, can be disastrous: it can leave the "ln" command without a library it needs to make the new link. :_| The scripts use the -f option so that the link is changed in one operation. People have to remember to do that.	Graham L (2)
174594	2003-09-12 05:56:00	Hi Graham With the glib-2.2.3 source I used "./configure" then "make" and then switched to root for "make install" first time around. Having a read of the Install.txt it also had this line "rm -rf /install-prefix/include/glib.h /install-prefix/include/gmodule.h" between the make and make install. So I repeated the process with the additional line, and then tried the pango ./configure again but still got the same error message as before :( I also had a look with "ls -l /lib/glib*" but got "No such file or directory". Sticking my nose into that directory myself also showed no glib's present. I did a search and found glib hiding in /usr/lib, /usr/local/include/glib-2.0/, /usr/include/glib-2.0/, /usr/local/share/gtk-doc/html/, /usr/local/include/gtk-doc/html/. Moving right on, I then had a look in /etc/lib.so.conf which only had this: /usr/kerberos/lib /usr/X11R6/lib /usr/lib/qt-3.0.5/lib /usr/lib/sane /usr/lib/wine /usr/lib/qt-3.1/lib To install the new GNOME 2.4, I have been following the installation order given here (www.gnome.org). I have done everything up to pango which is what I am currently stuck on. Is there anything else I could try, or add to the /etc/lib.so.conf file which could help? Thanks very much :) Jen	Jen C (20)
174595	2003-09-12 06:17:00	Ummm . I'd guess that /usr/lib would be the one . . . include/ directories tend to hold header ( . h) files used in compiles (and the /html/ ones are documentation) . I'd have a peek at some of those . A good programme for finding files is "locate" . (It uses a database which is updated by a cron task . I find it pays to (as root) do "updatedb &" when I have added any files to get the use of it immediately -- the task might show as "slocate" in top or ps) . The second most useful command is "file" . . . try "file /usr/lib/glib*" . That will tell you what sort of files are there . It looks as if you could just enter /usr/lib into that /etc/lib . so . conf file, and do ldconfig . You could try, in desperation, try setting that THING_IN_CAPITALS . . . the easiest way is to say "export THING_IM_SETTING=/usr/lib" .	Graham L (2)
174596	2003-09-12 06:24:00	Had another look at the first posting and a think. Have a good look ("ls -l" ) in /usr/lib . If there is glib (or glib-2.0 or something) which is a symbolic link pointing to the older of two or more glib-2.2.1 and glib2.2.3 or whatever, actual files, that's the problem. Do "ln -sf glib-<newest> glib" to change it. (Of course ... if it's glibc rather than glib use the correct name. :D I'm a few miles from my Linux boxes.)	Graham L (2)
174597	2003-09-12 06:38:00	PPS. "echo $LD_LIBRARY_PATH" will certainly show /usr/lib ... it's a standard directory. It will certainly be the symbolic link which is wrong. :D	Graham L (2)
174598	2003-09-12 09:36:00	I'm getting myself horribly confused the more I look into this :_| What I have tried now: [root@origin root]# updatedb & [1] 9351 [root@origin root]# ls -l /usr/lib/glib* /usr/lib/glib: total 4 drwxr-xr-x 2 root root 4096 Jul 15 18:55 include /usr/lib/glib-2.0: total 4 drwxr-xr-x 2 root root 4096 Jul 15 18:55 include [1]+ Done updatedb [root@origin root]# Using "locate glib" only seemed to show glib-2.0 and no glib-2.2.3 (apart from my new glib source files) Looking at that it seems my glib-2.2.3 is AWOL, yet pkg-config in the error message said: *** 'pkg-config --modversion glib-2.0' returned 2.2.3, but GLIB (2.2.1) *** was found! Out of curiosity I tried this (after updating the database): [root@origin root]# pkg-config --version 0.14.0 Now, what is mildy upsetting is that I have already compiled 0.15.0, so why does it show version 0.14.0? :( I am beginning to suspect that nothing is being updated, despite what seems to be successful compiles of the modules. I think I need to sort out what is really happening (or more likely, what am I doing wrong), before I continue any further. Jen	Jen C (20)
174599	2003-09-12 10:45:00	OK, well I have now consumed a bowl of ice-cream and I am feeling marginally better about this compiling thing :) I have taken a look into several of the already compiled modules config.log and they all have this: configure: failed program was: #line 1313 "configure" #include "confdefs.h" The line number is different for each of course, and some of them have this "failed program" message with the includes "confdefs.h" more than once. Yet all of them went through the ./configure, make, make install process without any whimpers. So, is this relevant at all? Thanks Jen	Jen C (20)
174600	2003-09-13 04:04:00	That "ought to be" very relevant . :D . h files are "header files", which contain declarations of procedures, constants, calls ("includes") of other . h files, etc . Any one of them missing will often cause "successful" compilations (!!! -- I hate C) with results which won't work, or "nearly" work . Usually . :D Sometimes the compile doesn't work . :D :D I wish the developers would clean up their code so that a kernel compile didn't give page after page of "warning" messages . In my book --- which says "there's no such thing as a warning; it's either right or wrong" either code compiles or it doesn't . When something says "failed" that's usually a "fail", which will stop later things from happening . I had a look at /usr/lib this morning . My Mandrake 9 . 0 has libglib-1 . 2 . so . 0 which is a link to libglib-1 . 2 . so . 0 . 0 . 10, and libglib-2 . 0 . so . 0 which is a link to libglib-2 . 0 . so . 0 . 0 . 6 . If I had compiled a new one, I would expect to see the same two links, but three big files which are the libraries, and the libglib-2 . . . blah would point to the new one . More often the links would be called libglib-2 . 0 . so (without any digit afterwards) . Have a look at the main /lib directory, and they will all be like that . This is so that the . so name always stays the same . Thinking about it, people who package libraries needed for kernel compilation would get the installation right . They'd make it Me-proof, because I'm the very highest class of idiot . "ldconfig -n /usr/lib" would have fixed the situation for you, I think, if you actually have the new library . . . but I've never had to do it, and I have installed quite a few libraries over the years . The installation scripts are pretty well established . So your problem might be that you are never getting the new library to be installed . Or the system doesn't know where it is . I also had a quick look at the Program-Library-HOWTO --- if you haven't had a look around the HOWTOs, you should do it . So you need to search for confdefs . h . locate :D	Graham L (2)
174601	2003-09-13 07:32:00	Thanks so much for your help so far Graham :) I tried locate confdefs.h and it appears to be an extinct item on my system - nowhere to be found at all (tried with and without the .h). Now don't cringe, but I also had a momentous discovery that Idconfig starts with a lower case L and not capital i (they both appear as the same l I) as I thought. This probably didn't help matters :D. I think I might quit trying to compile GNOME-2.4 from source whilst my system is still in one piece and look for an easier installation method, like RPM's. There were over 50 modules to compile so I think I should stick to smaller compilations for the time being which I have done in the past :) Thanks again Jen	Jen C (20)
1 2