Jesus man! I didn't expect an essay on the problem!!
I have printed it out to read on the train on my way home from work
:-) sorta had to put down my home worries for the time being to earn my
company some money...
Thanks for taking the time! I will reply later to let you know of the
success / failure...
Cheers
T
At 21:37 22/01/2001 -0500, you wrote:
>Tom Peck wrote:
> >
> > Thanks for the concern - but I've tried what you have suggested many times
> > without success.
>
>Sorry, I wasn't paying attention to the thread because I thought it was
>solved. There are two things that might be happening - configure is
>either trying to compile a program and can't find the proper library to
>link against, in which case you need the -dev versions of the packages,
>or it is trying to run a program that depends on the library.
>
>If configure is trying to compile/link and is failing, you need both the
>headers, and the libfoo.so, or, more likely, the libfoo.a libraries.
>Now, with these libraries, they are typically libfoo.a.MAJ.MIN.REV, and
>libfoo.a is a symlink to one of these libraries, of which many can be
>installed. Further, the linker needs to know where these libraries are,
>so a -L/path/to/libfoo line must be present. There are defaults here,
>but if it is in /usr/local/lib it probably won't be found. Do a
>"./configure --help" and see what the options are. There may be a
>"./configure --with-foo=/path/to/libfoo" option that you have to use.
>The same thing applies if the problem is with header files. The
>alternate means to doing this is going into a standard (defaults) place,
>and making a symlink, such as: "cd /usr/lib" and "ln -s
>/path/to/libfoo/libfoo.* ." (or, I suppose, "ln -s
>/path/to/libfoo/libfoo.* /usr/lib"). The header line would be like: "ln
>-s /usr/local/include/foo /usr/include".
>
>You can verify a symlink by doing a "file /the/symlink". It'll either
>say "symlink to foo" or "broken symlink to foo". If it says "broken
>symlink", you need to look at what it was pointing at, see if there is
>an upgrade, and change it. For example, if you do "file /path/link" and
>get "broken symlink to /other/path/foo.2.20", do "ls -l
>/other/path/foo*". You'll probably see something like
>"/other/path/foo.2.21". This is a new version of the same library, and
>you can do a "ln -sf /path/link /other/path/foo.2.21". The option '-s'
>means make the link 'symbolic'; the option '-f' means 'force' - create a
>symlink even if one already exists.
>
>Why a symlink? There are two types of links: hard, and soft, or
>symbolic. A hard link can only exist on the same filesystem as the file
>it points to. So, for example, if you do a 'df' and you see '/home',
>and '/usr', you cannot "ln /home/link /usr/file", but you can "ln -s
>/home/link /usr/file". The difference is that symbolic links can
>obviously be broken when the file it points to is removed. With a hard
>link, the file is not removed until all links are deleted. In DOS, this
>is a "cross-linked" file. This is OK under *nix, though not under DOS.
>This is a problem though, in the library links example. That is, if
>/usr/lib/libfoo.2 points to /usr/lib/libfoo.2.10, a hard link can
>obviously be used since they are in the same directory. But what if you
>want to upgrade that library? You can create /usr/lib/libfoo.2.11, but
>instead of getting a broken link in /usr/lib/libfoo.2, you get version
>2.10, the old version. This is probably undesirable.
>
>Hard links can be used as a "poor man's backup" ... hard link every file
>to a 'recycled' directory in the same filesystem if you like, and if any
>file is ever accidentally deleted, it'll be sitting there in 'recycled',
>completely up-to-date. The beauty part of this is that it doesn't take
>up any more disk space, though it will use up inodes (file entries), and
>can't restore any previous versions. It's also useful in a chroot
>environment.
>
>So anyway, back to the problem ... If configure is trying to run a
>program, not compile, and *that* is failing, you need to make sure that
>the program exists, is being found, and has access to the right library,
>in this case, a .so file. The easiest way to do this is to try to run
>the program from the commandline and see what's failing. If the program
>isn't found, you may have to install it. If it is on the system (type
>"locate program") but not found, it may not be in your path. Add it by
>typing "export PATH=$PATH:/path/to/program". If it says a shared
>library isn't found, I'm not sure what happens. It may tell you what
>library can't be opened, in which case you're all set, or it may just
>say "command not found" when you try to run it.
>
>Either way ... find the file it's trying to run. Then, make sure that
>it can be run - it needs the 'execution' bit set. Do a "ls -l program"
>and make sure the permissions look something like "rwxr-xr-x". Those
>'x's are important - they say 'this program can be run'. Assuming all
>is well so far, but it still doesn't run, we need to find out why. Do a
>"ldd program". This shows you all the libraries the program depends on,
>where they are, and their entry points. If there's a problem, it'll say
>"... not found" as the entry point.
>
> From here, type "locate libfoo.so", for each 'foo' that's not found. If
>it's not on your system, you need to either download it if it's
>completely missing, or, if a similar library is present, create a
>symlink. That is, the program may be looking for 'libfoo.so.2', which
>you don't have, but you do have 'libfoo.so.2.13'. If this is the case,
>just create a symlink to it by typing "ln -s /path/to/libfoo.2.13
>/usr/lib/libfoo.2". Run 'ldd' again and you should see that the library
>is found and the program should now work. If you *do* have libfoo.so.2,
>note where it is, eg, '/usr/local/lib/foo/'. Now, you can either create
>a symlink to a 'proper' place, such as /usr/lib, or, you can edit
>/etc/ld.so.conf and add '/usr/local/lib/foo', then run "ldconfig". This
>permanantly add /usr/local/lib/foo to the shared library search path for
>the whole system. With the excception of /usr/local/lib or /opt/lib,
>this is probably overkill and the symlink solution is preferred.
>
>Now that that's all said and done, how the #%!! do you know what's going
>wrong? There is a file in the current directory describing what's
>happened. It's call "config.log" or "config.status" or
>"config.something" - I have no idea. One of these tells you exactly
>what failed, how and when, at the end. Type "tail -30 config.* | less"
>and you will have your answer.
>
>rgds,
>Chris
>--
>Oh My God! They Killed init! You Bastards!!
>make install; not war
>_______________________________________________
>Obs-dev mailing list
>[EMAIL PROTECTED]
>http://www.freeamp.org/mailman/listinfo/obs-dev
_______________________________________________
Obs-dev mailing list
[EMAIL PROTECTED]
http://www.freeamp.org/mailman/listinfo/obs-dev
