<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 4/11/2013 4:01 AM, Mike Schwartz
wrote:<br>
</div>
<blockquote cite="mid:00c401ce36a3$e9469810$bbd3c830$@athenet.net"
type="cite">
<pre wrap="">(comments interspersed)
</pre>
<blockquote type="cite">
<pre wrap="">On Wed, Apr 10, 2013 at 11:31:10AM -0400, Mike Schwartz thus spoke:
</pre>
<blockquote type="cite">
<pre wrap=""> I installed what I thought were some of the most relevant RPMs,
including a couple that said "ODBC Development on them). All the
RPMs said "x86_64". I rebooted and then tried reinstalling
</pre>
</blockquote>
</blockquote>
<pre wrap="">filepro,
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap=""> but it still balked at the installation.
</pre>
</blockquote>
<pre wrap="">
*cringe* Seriously? You do -not- need to reboot after installing
</pre>
</blockquote>
<pre wrap="">libraries.
</pre>
<blockquote type="cite">
<pre wrap="">You simply run `ldconfig` to refresh the dynamic linker's knowledge of
</pre>
</blockquote>
<pre wrap="">what
</pre>
<blockquote type="cite">
<pre wrap="">is available and where.
</pre>
</blockquote>
<pre wrap="">
Yes, I did run ldconfig after installing some of the libraries. At
other times, it was more convenient just to reboot the server because I was
rearranging equipment and so forth.
</pre>
<blockquote type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap=""> I was told to look for a library named "/usr/lib/libodbc.so.1",
and if it is not there, then I don't have the correct Unix ODBC
libraries installed. All of the ODBC RPM's I installed seemed to
have put their libraries into /usr/lib64, so I presume I'm only
loading 64-bit libODBC libraries.
Any suggestions?
</pre>
</blockquote>
<pre wrap="">
On CentOS 6.4 (the downstream carbon copy of RH 6.4) 64-bit,
/usr/lib/libodbc.so.2 is provided by the unixODBC package. There is no
</pre>
</blockquote>
<pre wrap="">.so.1
</pre>
<blockquote type="cite">
<pre wrap="">versioned library. Sounds like fP-Tech linked against an old version.
You could try installing it and symlink from .so.2 to .so.1, then running
ldconfig. I give that...eh, about a 5% chance of actually solving the
</pre>
</blockquote>
<pre wrap="">problem,
</pre>
<blockquote type="cite">
<pre wrap="">since APIs usually change between major library versions, not to mention
symbol differences in the library itself that will probably collide like
</pre>
</blockquote>
<pre wrap="">mad.
</pre>
<blockquote type="cite">
<pre wrap="">But it's your best shot without getting fP-Tech to recompile on this
</pre>
</blockquote>
<pre wrap="">platform,
</pre>
<blockquote type="cite">
<pre wrap="">or without finding out -exactly- which major version of UnixODBC they
</pre>
</blockquote>
<pre wrap="">built
</pre>
<blockquote type="cite">
<pre wrap="">against and rolling a parallel install. Actually, if the symlink route
</pre>
</blockquote>
<pre wrap="">fails
</pre>
<blockquote type="cite">
<pre wrap="">(almost guaranteed to, but I'd try anyway), doing a parallel install of an
older UnixODBC is probably the sanest thing to do.
Just make sure you toss /usr/local/lib into /etc/ld.so.conf and then run
ldconfig after building and installing it.
</pre>
</blockquote>
<pre wrap="">
Yes, apparently symlinking worked (ln -s) buy linking (just ln) did not.
I'm not sure why the difference. so.2 was in /usr/lib64, but /usr/lib
resides on the same file system. I will research this later. Too busy
right now. I'm 2 days behind on this job...
I apologize to everybody for not writing down which RPM's I did end up
loading, but I probably loaded more RPM's than necessary, or not necessarily
the best RPM's to fix the aborts.
</pre>
<blockquote type="cite">
<pre wrap="">The biggest hassle in this is really going to be finding out what version
</pre>
</blockquote>
<pre wrap="">of it
</pre>
<blockquote type="cite">
<pre wrap="">compiles and links to .so.1 instead of .so.2. The rest is pretty trivial.
mark->
--
Audio panton, cogito singularis.
_______________________________________________
Filepro-list mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Filepro-list@lists.celestial.com">Filepro-list@lists.celestial.com</a>
Subscribe/Unsubscribe/Subscription Changes
<a class="moz-txt-link-freetext" href="http://mailman.celestial.com/mailman/listinfo/filepro-list">http://mailman.celestial.com/mailman/listinfo/filepro-list</a>
</pre>
</blockquote>
<pre wrap="">
_______________________________________________
Filepro-list mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Filepro-list@lists.celestial.com">Filepro-list@lists.celestial.com</a>
Subscribe/Unsubscribe/Subscription Changes
<a class="moz-txt-link-freetext" href="http://mailman.celestial.com/mailman/listinfo/filepro-list">http://mailman.celestial.com/mailman/listinfo/filepro-list</a>
</pre>
</blockquote>
<font size="+1"><font size="+1">I also did not remember what
packages to <font size="+1">install to get the new version of
Filepro installed, so I <font size="+1"><font size="+1"><font
size="+1">documented</font> what I did this time. I
copied a command from a forum for installing the linux
asterisk <font size="+1">program. The command is this:<br>
yum install unixODBC unixODBC-devel libtool-ltdl
libtool-ltdl-devel<br>
<br>
<font size="+1">I then <font size="+1">ma<font
size="+1">de the sym<font size="+1">bolic link <br>
ln -s /usr/lib/libodbc.so.2
/usr/lib/libodbc.so.1<br>
<br>
The install went without a hitch.<br>
<br>
I did however <font size="+1">install the 32bit
version of Centos 6.3 inst<font size="+1">ead
of the 64bit version. I won<font size="+1">'t
make that mistake again.<br>
<br>
<font size="+1">John</font><br>
</font></font></font><br>
<br>
<br>
<br>
</font></font></font></font><br>
<br>
that allowed me to install filep<font size="+1">ro
right after the <font size="+1">symbolic link</font></font></font></font></font><br>
</font></font></font>
</body>
</html>