Ruby

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)

Lauri Tirkkonen wrote:

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.

Yes please! We still carry around the patch in Fedora:

https://src.fedoraproject.org/rpms/ruby/blob/rawhide/f/ruby-2.1.0-Enable-configuration-of-archlibdir.patch

Although I have not checked what is the situation with the --with-rubyarchprefix for a long time.

@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?

nobu (Nobuyoshi Nakada) wrote in #note-9:

@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:

rubyarchprefix=${multiarch+'${archlibdir}/${RUBY_BASE_NAME}'}${multiarch-'${rubylibprefix}/${arch}'}

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?

Can this be reopened or should create new ticket?