I have never been in this situation (32/64 bit) and i don't have
red-hat for test it.
I don't know how to help you.
On Jan 26, 2008 6:28 AM, Jim Dodgen <[EMAIL PROTECTED]> wrote:
> thanks for all the help, I think I am getting closer ... but still
> broken ... look for the "---" for my comments
>
thanks for all the help, I think I am getting closer ... but still
broken ... look for the "---" for my comments
--- tail of the install of sqlite 3.5.4
--
/usr/bin/install -c -d /usr/local/bin
./libtool --mode=install
On Fri, 2008-01-25 at 15:04 -0800, Jim Dodgen wrote:
> you are correct. sorry to offend
No offense taken, dude. :) I'm usually lurking in here only, anyway.
Also, I wasn't too serious...
What I *did* mean though, is, to tell you (and a lot of other readers,
for that matter) about the difference
if you DBD::SQlite built statically, then it uses it's internal SQLite
If it's linked again libsqlite, you can check it by command ldd on:
# find /usr/lib/perl5/ -name 'SQLite.so'
/usr/lib/perl5/site_perl/5.8.8/i686-linux/auto/DBD/SQLite/SQLite.so
# ldd
you are correct. sorry to offend
Karsten Bräckelmann wrote:
On Thu, 2008-01-24 at 19:41 -0800, Jim Dodgen wrote:
sorry I attached another email by accident, it's content is not related
to my question
No, you pretty much did so on purpose.
You *replied* to a previous post, which
thanks for the education, looks like i have multiple versions floating
around, as seen below I'll blow a way the lib64 version just to
eliminate the confusion.
How do I tell which one is being used?
computer A (this has 3.5.4 installed)
lrwxrwxrwx 1 rootroot 19 Feb 8 2006
On Thu, 2008-01-24 at 19:41 -0800, Jim Dodgen wrote:
> sorry I attached another email by accident, it's content is not related
> to my question
No, you pretty much did so on purpose.
You *replied* to a previous post, which inherits special headers for
threading. Instead, you should have wrote a
On 1/25/08, Alexander Batyrshin <[EMAIL PROTECTED]> wrote:
> I have no problem with 3.5.4.
> Maybe your DBD::SQLite is linked with libsqlite in other dirrectory?
> For example your DBD::SQLite is linked against
> /usr/lib/libsqlite3.so.0, and you installed new 3.5.2 into
> /
There is two way of compiling DBD::SQLite:
1. to use his own internal version of SQLite
USE_LOCAL_SQLITE=1 perl Maker.pl
2. to use shared library of SQLite
SQLITE_LOCATION=/path/to/libsqlite perl Makefile.pl
So if you install 3.5.4 in /usr/local/lib, you should set
SQLITE_LOCATION=/usr/local/lib/
I have tend to build the DBD::SQLite from source, when ever I have built
with it looking for sqlite libs it reports a old version older than
3.3.9 or something
and then uses the current 3.4.2 stuff supplied in the module.
I do have 3.5.4 installed, it migh be that there could be a older
I have no problem with 3.5.4.
Maybe your DBD::SQLite is linked with libsqlite in other dirrectory?
For example your DBD::SQLite is linked against
/usr/lib/libsqlite3.so.0, and you installed new 3.5.2 into
/usr/local/lib ?
Here is my linking information:
# ldd /usr/lib/perl5/site_perl/5.8.8/i686
sorry I attached another email by accident, it's content is not related
to my question
Jim
Jim Dodgen wrote:
the latest DBD::SQLite (a Perl module) was buit with 3.4.2 I have
attempted to get a version up to 3.5.2 with no success so far.
anyone have any success yet? If so what is the
the latest DBD::SQLite (a Perl module) was buit with 3.4.2 I have
attempted to get a version up to 3.5.2 with no success so far.
anyone have any success yet? If so what is the magic.
Jim
John Stanton wrote:
Using Apache is the problem. The connections are not persistent so
caching is
13 matches
Mail list logo
