Misc #13296: building ruby for windows always puts the version number into the ruby library, resulting in redundancy when using --with-soname

• Status: Closed
• Assignee: -

[ntzrmtthihu777 (Marty Plummer)]

Under gentoo the dev-lang/ruby-2.4.0.ebuild explicitly sets --program-suffix
and --with-soname in order to facilitate multiple ruby version installations
at the same time.

Using crossdev for the x86_64-w64-mingw32 target, ruby's build system will
set the final ruby libraries name to something like x64-msvcrt-${soname}${ver}
which results in a final name of libx64-msvcrt-ruby24240.dll.a and so on.

[nobu (Nobuyoshi Nakada)]

• Status changed from Open to Rejected

Remove ${ver} from --with-soname.

[ntzrmtthihu777 (Marty Plummer)]

Nobuyoshi Nakada wrote:

Remove ${ver} from --with-soname.

Not doable, its something you guys are doing, not downstream.
Proof: building ruby for windows without any --with-soname or --program-suffix
still sticks 'ruby${ver}' into the final lib name.

[nobu (Nobuyoshi Nakada)]

Yes, soname already includes major and minor version numbers, don't append them more.

[ntzrmtthihu777 (Marty Plummer)]

Nobuyoshi Nakada wrote:

Yes, soname already includes major and minor version numbers, don't append them more.

You seem to be misunderstanding what I'm talking about.

Building ruby-2.4.0 on gentoo without using the --with-soname=ruby${ver} will always make the library have the following names:
libruby.so, libruby.so.2.4.0, and libruby.so.2.4. Building 2.3.0 will result in libruby.so, libruby.so.2.3.0, and libruby-2.3.
Do you see the problem here? without passing --with-soname=ruby${ver}, its impossible to install two or more versions of ruby
system-wide, so it is an absolute must in order to use gentoo's slotted package architecture.

Building ruby for windows/mingw using gentoo's crossdev tool uses the exact same ebuild, and the --with-soname argument cannot
be removed from the mingw build without removing it from the native build.

[nobu (Nobuyoshi Nakada)]

Marty Plummer wrote:

Building ruby for windows/mingw using gentoo's crossdev tool uses the exact same ebuild, and the --with-soname argument cannot
be removed from the mingw build without removing it from the native build.

It's an ebuild's issue.

[ntzrmtthihu777 (Marty Plummer)]

Nobuyoshi Nakada wrote:

Marty Plummer wrote:

Building ruby for windows/mingw using gentoo's crossdev tool uses the exact same ebuild, and the --with-soname argument cannot
be removed from the mingw build without removing it from the native build.

It's an ebuild's issue.

It is not. Its a windows stupidity issue, which has to be worked around. Simply drop the version from the library name and packagers/builders can decide for themselves what is best to be done with it.

[shyouhei (Shyouhei Urabe)]

Isn't this something normal? I don't have MinGW so platform-specific situation is not clear to me but, at least GNU libtool generates similar Makefiles so I think there are lots of other libraries who install like us.

https://www.gnu.org/software/libtool/manual/html_node/Release-numbers.html

[nobu (Nobuyoshi Nakada)]

Marty Plummer wrote:

It is not. Its a windows stupidity issue, which has to be worked around. Simply drop the version from the library name and packagers/builders can decide for themselves what is best to be done with it.

It's necessary to avoid conflict across versions.
You mean ALL packagers/builders MUST ALWAYS specify it?

[ntzrmtthihu777 (Marty Plummer)]

Shyouhei Urabe wrote:

Isn't this something normal? I don't have MinGW so platform-specific situation is not clear to me but, at least GNU libtool generates similar Makefiles so I think there are lots of other libraries who install like us.

https://www.gnu.org/software/libtool/manual/html_node/Release-numbers.html

In the above example you still can't install multiple version of the same library for linux due to the libbfd.so symlink.

Nobuyoshi Nakada wrote:

Marty Plummer wrote:

It is not. Its a windows stupidity issue, which has to be worked around. Simply drop the version from the library name and packagers/builders can decide for themselves what is best to be done with it.

It's necessary to avoid conflict across versions.
You mean ALL packagers/builders MUST ALWAYS specify it?

No. Only distros that package multiple versions of ruby (rare [especially for mingw, which is rarer]) at the same time will be affected, and they already ALWAYS specify it in order to prevent library and executable conflicts
(if you don't set --with-soname you will always end up with 'libruby.so' regardless of the full version of the library, so --with-soname is required to prevent this conflict)

[nobu (Nobuyoshi Nakada)]

• Status changed from Rejected to Closed

OK, you can try it now.

[ntzrmtthihu777 (Marty Plummer)]

Nobuyoshi Nakada wrote:

OK, you can try it now.

I see you're still hardcoding ${MAJOR}${MINOR}0 into it. Still, this works well enough I suppose.

As a side note, that x64 in the libname I think may be utterly unneeded in most real world ruby installations... May draw up a chart at some point in the future.

[nobu (Nobuyoshi Nakada)]

Marty Plummer wrote:

I see you're still hardcoding ${MAJOR}${MINOR}0 into it. Still, this works well enough I suppose.

It's the fallback.

[ntzrmtthihu777 (Marty Plummer)]

Nobuyoshi Nakada wrote:

Marty Plummer wrote:

I see you're still hardcoding ${MAJOR}${MINOR}0 into it. Still, this works well enough I suppose.

It's the fallback.

Well it doesn't appear to be falling back. Still get the name libx64-msvcrt-ruby240.dll/etc and not the 'ruby24' getting passed to --with-soname

[nobu (Nobuyoshi Nakada)]

Of course, it's only in the trunk.

[ntzrmtthihu777 (Marty Plummer)]

Nobuyoshi Nakada wrote:

Of course, it's only in the trunk.

I understand that, I mean after I applied this patchset to the 2.4 build. Could be that it requires more from upstream. I'll be satisfied with this for now, I suppose.
Any release time scheduled for 2.4.1 yet?