Bug #8973
closed
Allow to configure archlibdir for multiarch
Added by vo.x (Vit Ondruch) over 10 years ago.
Updated 3 months ago.
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
- Status changed from Open to Feedback
- 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.
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.
- 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
Although I have not checked what is the situation with the --with-rubyarchprefix for a long time.
- Status changed from Feedback to Assigned
@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?
- Status changed from Assigned to Feedback
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.
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?
Also available in: Atom
PDF
Like0
Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0
Updated by 
Updated by 
Updated by 
Updated by