[torqueusers] Soname went back in time

[Garrick]

HPCC/Linux Systems Admin

On Nov 13, 2008, at 11:06 AM, Josh Butikofer  
<josh at clusterresources.com> wrote:

> Chris Samuel wrote:
>> ----- "Garrick Staples" <garrick at usc.edu> wrote:
>>> But now the soname has gone back in time to libtorque.so.0, breaking
>>> binaries again.... during a stable release branch.
>> Hmm, won't that cause distro packagers issues too ?
>> Though many of them may still be packaging 2.1.x (Ubuntu
>> Intrepid has 2.1.8 for example).
>
> Obviously this was not intended. Looks like there was a  
> misunderstanding on our side that using a -version-info of 2:0:2  
> would create both a libtorque.so.0 and libtorque.so.2. This is not  
> the case and I suspect that during our tests we had an old  
> libtorque.so.2 floating around...

Note you can't really predict what libtool will do because it behaves  
differently in each is.


>
>
> In any case, this does need to be fixed. I think the best thing to  
> do is to revert back to the 2:0:0 versioning and release 2.3.5. We  
> do, however, also need a libtorque.so.0 symlink in the lib dir, as  
> there are still many binaries that link against that (which when the  
> library was moved to libtorque.so.2, has caused some inconveniences  
> for a lot of people). This was the whole motivation for going to a  
> 2:0:2 version.

I dunno.  Tough problem. I can't think of anything other than ugly  
hacks.

Personally, I don't see a problem with soname changes between branches.

Sometimes there are changes.


> I propose we add a install-exec-hook to the Makefile.am/.in files in  
> src/lib/Libpbs which creates this symlink. What does everyone think?
>
> For example, here is what I propose:
>
> install-exec-hook:
>  cd $(DESTDIR)$(libdir) && \
>    rm -f $(DESTDIR)$(libdir)/libtorque.so.0 && \
>    $(LN_S) libtorque.so.2.0.0 libtorque.so.0

Also needs a uninstall hook and add it to the automake filelist to  
satisfy 'make distcheck'.  It will work on Linux, but will fail to  
install on OSX and windows.


>
>
> The only problem with this is I'm hard coding the filenames. I'm not  
> a automake/autoconf wizard ... does anyone know a more portable way  
> of doing this?

I don't think there is a portable method because the automake<- 
 >libtool interface is being violated.