Project

General

Profile

Actions

Bug #8973

closed

Allow to configure archlibdir for multiarch

Added by vo.x (Vit Ondruch) over 10 years ago. Updated about 2 months ago.

Status:
Feedback
Target version:
-
ruby -v:
ruby 2.1.0dev (2013-09-22 trunk 43011) [x86_64-linux]
Backport:
[ruby-core:57541]
Tags:

Description

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.


Files

Updated by nobu (Nobuyoshi Nakada) over 10 years ago

  • Status changed from Open to Feedback

Was it possible ever?

Updated by vo.x (Vit Ondruch) over 10 years ago

  • Status changed from Feedback to Open

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.

Actions #3

Updated by lotheac (Lauri Tirkkonen) over 9 years ago

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)

Updated by lotheac (Lauri Tirkkonen) over 9 years ago

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.

Updated by mame (Yusuke Endoh) almost 2 years ago

  • Status changed from Open to Feedback
  • Backport deleted (1.9.3: UNKNOWN, 2.0.0: UNKNOWN)

@vo.x (Vit Ondruch) Do you still want this? I'd like to know if the patch is still need to review

Updated by vo.x (Vit Ondruch) almost 2 years ago

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

Updated by mame (Yusuke Endoh) almost 2 years ago

  • Status changed from Feedback to Assigned

Okay thanks for your quick answer. @nobu (Nobuyoshi Nakada) Could you review the patch?

Updated by nobu (Nobuyoshi Nakada) almost 2 years ago

@vo.x (Vit Ondruch) 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?

Actions #10

Updated by nobu (Nobuyoshi Nakada) almost 2 years ago

  • Status changed from Assigned to Feedback

Updated by vo.x (Vit Ondruch) about 1 year ago

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

@vo.x (Vit Ondruch) 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.

Updated by vo.x (Vit Ondruch) about 1 year ago

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?

Updated by vo.x (Vit Ondruch) about 2 months ago

Can this be reopened or should create new ticket?

Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0