COIN-OR::LEMON - Graph Library

Opened 4 years ago

Closed 3 years ago

#482 closed enhancement (fixed)

Consider giving libemon.so a real soname when building a shared library

Reported by: amluto Owned by: alpar
Priority: major Milestone: LEMON 1.4 release
Component: core Version: hg main
Keywords: Cc:
Revision id:

Description

Hi-

I'm playing with packaging lemon for Fedora. Currently everything works (as long as I don't try to link against glpk), but the resulting libemon.so doesn't have an associated version. This will cause issues when lemon gets upgraded.

Would you be willing to version it for real or at least to create libemon-1.3.so and symlink it to libemon.so? (The latter is a bit annoying in that it will force all users to rebuild for each new major release, but it's better than causing silent failures.)

Thanks!

Attachments (1)

d6a6b83bebd0.patch (636 bytes) - added by alpar 3 years ago.

Download all attachments as: .zip

Change History (6)

comment:1 Changed 4 years ago by alpar

Thanks for the effort for Fedora packaging, should it get into public repository, please let us know either here or on the mailing list.

To be honest, I can't see any advantage of providing a shared library instead of a static one. The vast majority of LEMON is implemented as templates, the library (libemon.a/libemon.so) is very tiny. The benefit of sharing it among processes is really negligible.

comment:2 follow-up: Changed 4 years ago by amluto

The coin-or-lemon package is now in updates-testing for Fedora 19 and 20.

Fedora policy says that everything should be a shared library. Even for something like lemon, there's a good reason: when lemon 1.4 comes and and I update the Fedora package, everything using lemon should be rebuilt. If there's a shared library with a real soname, then bumping the soname version will be enough to get all the version dependencies right and to tell me what needs to be rebuilt.

I'm currently patching lemon like this:

sover_prefix="SET_TARGET_PROPERTIES(lemon PROPERTIES OUTPUT_NAME emon"
grep -q "${sover_prefix})" lemon/CMakeLists.txt
sed -i -e "s/${sover_prefix})/${sover_prefix} VERSION %{libemon_soversion} SOVERSION %{libemon_soversion})/" lemon/CMakeLists.txt

where %{libemon_soversion} is '0.1'.

If upstream lemon did something as simple as making the soversion equal to the version of lemon, then this would happen for free, and people linking against lemon shared libraries wouldn't have to worry about silent breakage if their libemon.so stopped matching the things built against it. (And different versions could be installed in parallel.)

Changed 3 years ago by alpar

comment:3 in reply to: ↑ 2 ; follow-up: Changed 3 years ago by alpar

Replying to amluto:

Could you please confirm that this patch is what you need?

On the other hand, wouldn't it be possible/useful to include both the static and the shared version of the lib into the package?

comment:4 in reply to: ↑ 3 Changed 3 years ago by amluto

Replying to alpar:

Replying to amluto:

Could you please confirm that this patch is what you need?

Yes, exactly. I probably won't push it out to Fedora 19 and 20 until Lemon 1.4 is released to avoid unnecessary recompilation, though.

On the other hand, wouldn't it be possible/useful to include both the static and the shared version of the lib into the package?

I could do that. Technically, I'd create an optional -static subpackage to supply the .a file. I'd probably only do that if there were demand. No Fedora packages would use it, but Fedora users could certainly use it.

--Andy

comment:5 Changed 3 years ago by alpar

  • Resolution set to fixed
  • Status changed from new to closed

This fix is in branches default and 1.3 as [9153e490f09c].
So, it will be included in the upcoming bugfix release 1.3.1.

Note: See TracTickets for help on using tickets.