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
