[torqueusers] Soname went back in time
garrick at usc.edu
Thu Nov 13 12:28:32 MST 2008
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
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:
> 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.
More information about the torqueusers