New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Different libraries built with Autotools and CMake #75

Closed
szotsaki opened this Issue Jun 10, 2016 · 8 comments

Comments

Projects
None yet
4 participants
@szotsaki

szotsaki commented Jun 10, 2016

When building with Autotools, the following library files are created:

  • libopendht.so.0.0.0 [executable, valid shared library with correct so naming]
  • @libopendht.so.0 [link to the former one with one major version]
  • @libopendht.so [link to the first one, only useful for development purposes]

These are correct, and the package library also gets its name from the .so: libopendht0.

When bulding with CMake, the following is created:

  • libopendht.so [executable, with incorrect so naming]
  • @symlinks are missing
@aberaud

This comment has been minimized.

Show comment
Hide comment
@aberaud

aberaud Jun 12, 2016

Contributor

Thanks for reporting,
Should be fixed by 9615774

Contributor

aberaud commented Jun 12, 2016

Thanks for reporting,
Should be fixed by 9615774

@aberaud aberaud closed this Jun 12, 2016

@szotsaki

This comment has been minimized.

Show comment
Hide comment
@szotsaki

szotsaki Jun 12, 2016

This works great, thank you!

Please, be aware that the Autotools version generates .so with version 0.0.0 while CMake with 0.6.1.

szotsaki commented Jun 12, 2016

This works great, thank you!

Please, be aware that the Autotools version generates .so with version 0.0.0 while CMake with 0.6.1.

@szotsaki

This comment has been minimized.

Show comment
Hide comment
@szotsaki

szotsaki Jun 24, 2016

Just to be sure: should I open a new ticket regarding the Autotools version difference? Thank you!

szotsaki commented Jun 24, 2016

Just to be sure: should I open a new ticket regarding the Autotools version difference? Thank you!

@sim590 sim590 reopened this Jun 27, 2016

@sim590 sim590 added the bug label Jun 27, 2016

@sim590 sim590 self-assigned this Jun 27, 2016

@sim590

This comment has been minimized.

Show comment
Hide comment
@sim590

sim590 Jun 27, 2016

Contributor

@szotsaki. You're right, Autotools doesn't have correct version naming. I've reopened this issue.

Contributor

sim590 commented Jun 27, 2016

@szotsaki. You're right, Autotools doesn't have correct version naming. I've reopened this issue.

@szotsaki

This comment has been minimized.

Show comment
Hide comment
@szotsaki

szotsaki Jul 21, 2016

With the release of 0.6.2 I rebuilt the package but unfortunately CMake still builds /usr/lib64/libopendht.so without any suffix and symlinks.

szotsaki commented Jul 21, 2016

With the release of 0.6.2 I rebuilt the package but unfortunately CMake still builds /usr/lib64/libopendht.so without any suffix and symlinks.

@sim590

This comment has been minimized.

Show comment
Hide comment
@sim590

sim590 Jul 21, 2016

Contributor

In fact, it wasn't part of the 0.6.2 release. This should be part of a future release where this whole issue is fixed (including autotools). We did release 0.6.2 for covering the critical #73 bug.

Contributor

sim590 commented Jul 21, 2016

In fact, it wasn't part of the 0.6.2 release. This should be part of a future release where this whole issue is fixed (including autotools). We did release 0.6.2 for covering the critical #73 bug.

@kaldoran

This comment has been minimized.

Show comment
Hide comment
@kaldoran

kaldoran Jul 21, 2016

Collaborator

Here is an update :

Start with version information of ‘0:0:0’ for each libtool library.
Update the version information only immediately before a public release of your software.
[...]
Never try to set the interface numbers so that they correspond to the release number of your package.

Source : https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html#Updating-version-info

Then a fix could be adding -release @PACKAGE_VERSION@ line 7 of src/Makefile.am.
Which will then going to create libopendht-0.6.X.so ( x = 2 for now ).

Not sure if this is the correct way to deal with that problem.

EDIT : By the looks of it, other libraries use both -release and -version-info.
Please note that -release info seems to be the package number, and version-info is a different way of tracking version. [c.f. link above ].
Then according to that a solution would be : -version-info X[:Y[:Z]] -release @PACKAGE_VERSION@

EDIT Bis : I finally understand how those .so.X'.Y'.Z' Work, from the version-info, will update soon

Collaborator

kaldoran commented Jul 21, 2016

Here is an update :

Start with version information of ‘0:0:0’ for each libtool library.
Update the version information only immediately before a public release of your software.
[...]
Never try to set the interface numbers so that they correspond to the release number of your package.

Source : https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html#Updating-version-info

Then a fix could be adding -release @PACKAGE_VERSION@ line 7 of src/Makefile.am.
Which will then going to create libopendht-0.6.X.so ( x = 2 for now ).

Not sure if this is the correct way to deal with that problem.

EDIT : By the looks of it, other libraries use both -release and -version-info.
Please note that -release info seems to be the package number, and version-info is a different way of tracking version. [c.f. link above ].
Then according to that a solution would be : -version-info X[:Y[:Z]] -release @PACKAGE_VERSION@

EDIT Bis : I finally understand how those .so.X'.Y'.Z' Work, from the version-info, will update soon

@sim590 sim590 added this to the 0.6.3 milestone Jul 22, 2016

@sim590

This comment has been minimized.

Show comment
Hide comment
@sim590

sim590 Jul 25, 2016

Contributor

I have looked a little bit more into this. The main issue is that CMake and Libtool have different and conflicting shared object versionning system. If we want consistent version releases, we're kind of forced to do like this.

Contributor

sim590 commented Jul 25, 2016

I have looked a little bit more into this. The main issue is that CMake and Libtool have different and conflicting shared object versionning system. If we want consistent version releases, we're kind of forced to do like this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment