<br><br><div class="gmail_quote">On Fri, Feb 20, 2009 at 12:38 PM, m. allan noah <span dir="ltr">&lt;<a href="mailto:kitno455@gmail.com">kitno455@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I&#39;m not sure, but i think the build system used to overwrite all the<br>
.so and .so.1 symlinks. It no longer does. I think this is a useful<br>
feature, because you can tell users just to build from source and they<br>
will be using the new version. Otherwise, they have to uninstall the<br>
old version, and this can get hairy with novice users and helpful<br>
package managers.<br>
<br>
</blockquote><div><br>You mean during install phase, right?<br><br>When backend was converted
to automake, it uses the standard automake support to install
libraries.&nbsp; That does install symlinks on fresh install.<br><br>
I think your point is that now if a user installs, libsane.so.1.1.0 on
top of a previous libsane.so.1.0.19 install then libsane.so symlink
still points to libsane.so.1.0.19?<br><br>I&#39;ve
not tried above yet but seems reasonable libtool behavior to me.&nbsp; I&#39;ll
read up on libtool and see if they have an &quot;opinion&quot; on this.<br>
<br>I didn&#39;t port over the following logic from old &quot;install-be&quot; target
but it must have been doing what you said (move symlink to
libsane.so.1.1.0).&nbsp; The comment suggested that libtool simply wasn&#39;t
working but since it was I didn&#39;t bother porting over...&nbsp; <br>
<br>If people agree with old behavior, I can add it back. Old logic
seems dangerious if we ever have a libsane.so.2.0.0 (as apposed to
libsane2.so.0.0.0).&nbsp; We don&#39;t want to move libsane.so to
libsane.so.2.0.0 blindly or else will break a lot of applications that
were working fine.&nbsp; But since we are not at that point yet, no issue to
restore it.&nbsp; Moving libsane.so.x to lastest version of libsane.so.x.y.z
seems safe.<br>
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; @# Create library links manually. Actually this is libtool&#39;s job but it<br>doesn&#39;t<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; @# seem to work on some platforms.<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; @# Assume the dll name without any versions is last<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; @if test &quot;$(USE_LINKS)&quot; = &quot;yes&quot; ; then&nbsp; \<br>

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; dllend=`../tools/libtool-get-<div>dll-ext <a href="http://libsane-dll.la/" target="_blank">libsane-dll.la</a>`; \<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; list=&quot;$(ALL_BACKENDS)&quot;; cd $(DESTDIR)$(libsanedir) &amp;&amp; for be in $$list<br>
; do \<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; file=libsane-$${be}.$$dllend.$(V_MAJOR); \<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; lib=`grep dlname= libsane-$${be}.la | cut -f2 -d&quot;&#39;&quot;`; \<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if test ! -f $${file} -a -n &quot;$${lib}&quot;; then \<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; $(LN_S) $${lib} $${file}; \<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; fi; \<br>

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; done; \<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; fi<br><br><br>Chris</div>&nbsp;</div></div><br>