Misc #13296
closedbuilding ruby for windows always puts the version number into the ruby library, resulting in redundancy when using --with-soname
Description
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.
Updated by nobu (Nobuyoshi Nakada) over 7 years ago
- Status changed from Open to Rejected
Remove ${ver}
from --with-soname
.
Updated by ntzrmtthihu777 (Marty Plummer) over 7 years ago
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.
Updated by nobu (Nobuyoshi Nakada) over 7 years ago
Yes, soname already includes major and minor version numbers, don't append them more.
Updated by ntzrmtthihu777 (Marty Plummer) over 7 years ago
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.
Updated by nobu (Nobuyoshi Nakada) over 7 years ago
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.
Updated by ntzrmtthihu777 (Marty Plummer) over 7 years ago
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.
Updated by shyouhei (Shyouhei Urabe) over 7 years ago
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
Updated by nobu (Nobuyoshi Nakada) over 7 years ago
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?
Updated by ntzrmtthihu777 (Marty Plummer) over 7 years ago
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)
Updated by nobu (Nobuyoshi Nakada) over 7 years ago
- Status changed from Rejected to Closed
OK, you can try it now.
Updated by ntzrmtthihu777 (Marty Plummer) over 7 years ago
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.
Updated by nobu (Nobuyoshi Nakada) over 7 years ago
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.
Updated by ntzrmtthihu777 (Marty Plummer) over 7 years ago
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
Updated by nobu (Nobuyoshi Nakada) over 7 years ago
Of course, it's only in the trunk.
Updated by ntzrmtthihu777 (Marty Plummer) over 7 years ago
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?