Since r39347, there is impossible to configure placement of rubylib.so when build is configured with "--with-multiarch". That is probably OK for Debian, but it breaks Fedora :/ The attached patch allows to configure the archlibdir, but I feel that it is suboptimal, since the "--with-rubyarchprefix" should probably be the parameter which influences placement of the arch specific libraries. Any chance that this patch is accepted or better if rubyarchprefix is respected for every arch specific library, including libruby.so. Thanks.
In Ruby 2.0, when using "--with-multiarch" together with "--with-rubyarchprefix", it used ${libdir} for libruby.so library placement (i.e. /usr/lib64/). Now it is hardcoded to ${libdir}/${arch} (i.e. /usr/lib64/x86_64-linux). Hence there is no way how to get rid of x86_64-linux folder and place the library directly into /usr/lib64.
I second this patch. I was using --with-multiarch --with-archlibdir --with-rubylibprefix --with-rubyarchprefix --with-rubyarchsiteprefix on ruby 2.0.0 to get a correct directory layout on OmniOS, but on 2.1.2 that no longer works: $(arch) is "i386-solaris2.11" for both 32 and 64 bit builds on illumos, so the default behavior is the wrong thing and should be configurable. With this patch I can get the shared library placed where I want it to be.
Looks like there's another related issue though. Having built with this patch it looks like --with-rubyarchprefix=lib/amd64/ruby has no effect: the arch-specific libs end up in lib/ruby/2.1.0/i386-solaris2.11 anyways (rubyarchdir seems to be set explicitly to that somewhere, I'm trying to figure out where)
Looks like there's another related issue though. Having built with this patch it looks like --with-rubyarchprefix=lib/amd64/ruby has no effect: the arch-specific libs end up in lib/ruby/2.1.0/i386-solaris2.11 anyways (rubyarchdir seems to be set explicitly to that somewhere, I'm trying to figure out where)
I'm wrong: the flag for multiarch is --enable-multiarch, not --with-multiarch, which is what caused my issue. The patch for this issue does work, sorry for the noise.
@vo.x With your patch and --with-multiarch --with-archlibdir='${libdir}', not only libruby.so but also all standard library extensions are placed under ${libdir} without ${arch}.
Is this intentional?
@vo.x With your patch and --with-multiarch --with-archlibdir='${libdir}', not only libruby.so but also all standard library extensions are placed under ${libdir} without ${arch}.
Is this intentional?
On Fedora, we don't use the ${arch} anywhere. It is not assumed that we will mix e.g. aarch64 with x86_64 on one filesystem. We only mix 32/64 bit systems, i.e. i686 together with x86_64. But in that case, the 32 bit code is stored in /usr/lib while the 64 bit code is in /usr/lib64.
Strictly speaking, we still have troubles with headers, but we are using small platform independent wrapper for them. And the ${arch} could be useful for some user installed gems, but that is different topic.
Actually, the real intention here is to get rid of the ${arch} from the paths. The thing is that --enable-multiarch used to make it possible, because this is the implementation:
As you can see, when multiarch is not defined, then the ${arch} is mandatory. With multiarch enabled, it is enough to modify the ${archlibdir} and whatever is there is there. It does not impose any expectations.
BTW out of curiosity, assuming that upstream expect that Ruby is installed via ./configure && make && make install, what is the reason to bother with ${arch} for non multiarch configurations? Does anybody really use single installation directory with multiple architectures?
Updated by 
Updated by 
Updated by 
Updated by