On Thu, Mar 13, 2008 at 2:23 PM, Robert L Cochran
<[EMAIL PROTECTED]> wrote:
>
>
>  Zbigniew Baniewski wrote:
>  > On Thu, Mar 13, 2008 at 01:03:01PM -0500, P Kishor wrote:
>  >
>  >
>  >> why is it the I had to do the above? Why is LD_LIBRARY_PATH not set
>  >> automatically? And, since it wasn't set, how come other programs were
>  >> working fine (assuming that other programs in the /usr/local/bin space
>  >> were looking for libs in /usr/local/lib as well
>  >>
>  >> And, what can I do to make LD_LIBRARY_PATH permanent?
>  >>
>  >
>  > You don't have to.
>  >
>  >
>  > If you run "./configure --help" before any compilation, it'll show you its
>  > switches. For example:
>  >
>  > #v+
>  > [..]
>  >
>  > Installation directories:
>  >   --prefix=PREFIX         install architecture-independent files in PREFIX
>  >                           [/usr/local]
>  > [..]
>  >   --libdir=DIR           object code libraries [EPREFIX/lib]
>  >
>  > ...and some "influential environment variables" as well:
>  >
>  >   LDFLAGS     linker flags, e.g. -L<lib dir> if you have libraries in a
>  >               nonstandard directory <lib dir>
>  >   LIBS        libraries to pass to the linker, e.g. -l<library>
>  > #v-
>  >
>  > So, you can set it all *before*.
>  >
>  I agree with Zbigniew. When I compile SQLite in CentOS 5, I use
>  something like the following `configure` line:
>
>  (First unpack the source code, then create an sqlite-x.x.x/bld
>  directory, then cd into that)
>
>  ../configure --prefix=/usr/local/sqlite-x.x.x --enable-threadsafe
>  --disable-tcl
>  make
>  su
>  make install

right, but for most other programs (and, in fact, as I understand it,
this is the normal behavior for GNU's autoconf), the default behavior
is to put everything that matters under /usr/local... that is,
binaries under /usr/local/bin, libraries under /usr/local/lib, and so
on, *unless* specified otherwise.

In other words, I don't have specify the prefix. It is /usr/local to begin with.

>
>  You could put '3.5.6' where you see x.x.x and get a
>  /usr/local/sqlite-3.5.6 binary directory when you `make install`.
>
>  After `make install` I like to edit /etc/ld.so.conf to point to the
>  /usr/local/sqlite-x.x.x/lib directory and then run `ldconfig`.

this is what is so interesting, on two counts -- this particular
machine already had /usr/local/lib in its ld.so.conf. I can find ldd
but I can't find ldconfig at all.

In any case, on setting LD_LIBRARY_PATH, it all worked fine.

I guess, what I am trying to understand is that when I tried to not
act smart and just have the program stick stuff where it sticks stuff
in by default, it just didn't work. It works just well on other
machines I have installed using GNU's make.

Obviously, there is much about Linux that I don't know, but I want to
learn just enough about it to get by and no more.




>
>  However I don't know if this is a best practice or what others would
>  recommend. I know I can run into trouble if I have multiple sqlite
>  version libraries in /etc/ld.so.conf:
>
>  /usr/local/sqlite-3.5.3/lib
>  /usr/local/sqlite-3.5.6/lib
>
>  What happens here is the running `sqlite3` results in version 3.5.3
>  being run, even if my path is set to point to
>  /usr/local/sqlite-3.5.6/bin. I'm not sure what I'll do if the day comes
>  when I need to access earlier versions of sqlite. I have a bunch of
>  those in /usr/local now.
>
>  The final step I do after building SQLite is to change my path to point
>  to /usr/local/sqlite-x.x.x/bin. Again, understand that x.x.x refers to
>  the version you are building.
>
>
>  Thanks
>
>  Bob Cochran
>  Greenbelt, Maryland, USA
>
>
>
>
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to