Finally version libjulia with a proper filename

[staticfloat]

@nalimilan Do you know if we should be setting -Wl,-soname=libjulia.so or -Wl,-soname=libjulia.so.0.1?

Closes #8038

[nalimilan]

The latter AFAIK. But then you also want SOMAJOR := 0.1.

[nalimilan]

To be more preciseI would say Increase SOMINOR with every minor release, and SOMAJOR with every major (ABI-breaking) release (and reset SOMINOR to 0)

[tkelman]

any way of making this a little more automatic, or harder to forget?

[nalimilan]

A solution I find natural, and which works well with semantic versioning, it to have SOMAJOR equal to the major Julia version, and SOMINOR to the minor version. The parallel between SOVERSION and the official version makes things clearer.

Until 1.0, SOMAJOR would be equal to 0.$minorversion and SOMINOR to $patchversion.

[tkelman]

that would be easy to automate, and I know there are other libraries that do that, but I think I've also read that tying API version numbers to soname ABI version numbers is actually wrong. I'm not sure what the downsides would be though.

[vchuravy]

https://autotools.io/libtool/version.html and http://plan99.net/~mike/writing-shared-libraries.html discuss library version in some detail

[nalimilan]

Indeed, the second link explicitly says "The software version of your library should match the interface version.". That matches the semantic versioning contract.

[staticfloat]

I don't think you can make the major version a decimal like that, so I'm opting instead to set the major version number to Y in Julia's X.Y.Z version number. Once we hit 1.0, we'll add W to the major soversion, where W is the number of major releases before 1.0, so that we continue to count up with major releases.

[nalimilan]

I think you can perfectly do that, that's even the solution required by Fedora when upstream does not set a SONAME: use SOMAJOR=0.X until upstream ships a release with SOMAJOR = 1. See https://fedoraproject.org/wiki/Packaging:Guidelines?rd=Packaging/Guidelines#Downstream_.so_name_versioning

[staticfloat]

Good points @nalimilan. I want things to be as consistent as possible, which means I would like the SOMAJOR and SOMINOR that we use in the SONAME to match the extensions added onto libjulia.so. I would also like SOMAJOR and SOMINOR to be some predictable function of Julia's actual VERSION (broken up as Major.Minor.Patch). With that being said, here's what happens now:

Pre v1.0.0, SOMAJOR is equal to Major.Minor (e.g. 0.5), and SOMINOR is equal to Patch (e.g. 0). This results in an SONAME of libjulia.so.0.5.0 and a matching filename on Linux, and an SONAME/filename of libjulia.0.5.0.dylib on OSX. One weird thing is that the symlinks that get created are libjulia.0.5.dylib and libjulia.dylib; that's a consequence of the SOMAJOR being a two-decimal. That is the most likely place for us to run into problems I think, so I'd like to get anybody who deals with embedding Julia to weigh in and see if this would impact them. (I'm guessing most people have been loading libjulia.so, so this won't be a problem)

Post v1.0.0, SOMAJOR is equal to Major (e.g. 1) and SOMINOR is equal to Minor (e.g. 0). This brings us into the bland world of being just like everyone else.

I've included some recently-merged changes to openlibm and openspecfun in order to get them to version themselves properly as well. libjulia.so is also installed into the global <prefix>/lib directory now, instead of our private <prefix>/lib/julia directory.

[tkelman]

we should only be using tagged releases

[staticfloat]

So what is the meaning of OPENLIBM_BRANCH? Would OPENLIBM_TAG be more appropriate?

[tkelman]

Possibly. I can't really read what the git externals makefile macros are doing. It's only used in one or two minor places. More saying for the sake of making release tags for packagers to be aware of as opposed to picking some random commit hash. Also note the VERSION and SONAME look out of date on master of both openlibm and openspecfun. We need a better way of enforcing that those get updated for releases.

[StefanKarpinski]

Possibly. I can't really read what the git externals makefile macros are doing.

I think that @vtjnash is the only person who understands this git externals business. Maybe @Keno as well.

[staticfloat]

I think I understand it. The confusing part is that with git, a branch name and a tag name are often interchangeable. I've tagged new releases of openlibm and openspecfun, and pushed a new commit with those tag names in the _BRANCH variables.

[vtjnash]

I think the technical name would have been _TREEISH, but branch seemed a bit clearer. the only real requirement is that the desired sha1 value will always be locatable in the history of tree-ish.

@StefanKarpinski they're just simple string interpolation macros

[tkelman]

The VERSION and soversion are still out of date on the commits you just tagged.

[staticfloat]

All tests passing, unless I've missed something I think we're ready to merge here.

[tkelman]

Good candidate for squash-on-merge I think, considering the libdl test change at the very end.

[staticfloat]

Agreed, not much use for having it split up. Ready when you are, commander.
-E

On Wed, May 18, 2016 at 12:29 PM, Tony Kelman notifications@github.com
wrote:

Good candidate for squash-on-merge I think, considering the libdl test
change at the very end.

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#16362 (comment)

[stevengj]

Should this be a NEWS item, and be documented in the "Embedding Julia" section of the manual?

[stevengj]

PS. In general, the SONAME version might be different from the Julia version. The reason is that the SONAME version indicates C ABI compatibility, whereas the Julia version indicates Julia source compatibility, and these two might not agree.

[staticfloat]

Yeah, probably. I sent out an email to julia-dev, but I'll put together the documentation PR.

[staticfloat]

In general, the SONAME version might be different from the Julia version. The reason is that the SONAME version indicates C ABI compatibility, whereas the Julia version indicates Julia source compatibility.

So far, our C ABI has followed the Julia source compatibility fairly closely, right? We haven't introduced major backwards-incompatible changes within a single major release, unless I am mistaken. (Not that this is a huge priority for us or anyone else right now, but I think we're at least pretty close to proper behavior here)

[stevengj]

In general, my feeling is that PRs should not be merged until the documentation is added/updated as needed.

[staticfloat]

Agreed. PR here.

[tkelman]

Yep, sorry, forgot about docs on this one since I didn't realize it would be a visible change.