Bug 280388 - print/epson-inkjet-printer-escpr2: when DEFAULT_VERSIONS+= linux=rl9, printing is not possible
Summary: print/epson-inkjet-printer-escpr2: when DEFAULT_VERSIONS+= linux=rl9, printin...
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: Gleb Popov
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-07-21 09:15 UTC by Tatsuki Makino
Modified: 2025-05-05 06:21 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tatsuki Makino 2024-07-21 09:15:36 UTC
If the default version of Linuxulator is switched to rl9, it seems that we can't print just by installing.
For amd64 architecture, additional operations are required, such as:

Create a symlink as follows:
ln -s /compat/linux/usr/lib64/ld-linux-x86-64.so.2 /compat/linux/usr/lib64/ld-lsb-x86-64.so.3

Install linux-rl9-gnutls (security/linux-rl9-gnutls)

c7 had no abnormalities, so this is a problem specific to rl9.
Comment 1 Tatsuki Makino 2024-07-26 05:54:14 UTC
If the two executable binaries installed in /compat/linux/opt/epson-inkjet-printer-escpr2/cups/lib/filter try to be executed directly, the following error will occur

ELF interpreter /lib64/ld-lsb-x86-64.so.3 not found, error 2
Abort

The way to solve this is to create a symlink that I have already mentioned, but this affects all Linux binary ports.
The question is by what port this symlink should be created on.

If an individual port attempts to resolve this issue, it can also be done in the following ways

Install patchelf(sysutils/patchelf).
Use the following command to rewrite the ELF header.

patchelf --set-interpreter /lib64/ld-linux-x86-64.so.2 \
 /compat/linux/opt/epson-inkjet-printer-escpr2/cups/lib/filter/epson-escpr-wrapper2 \
 /compat/linux/opt/epson-inkjet-printer-escpr2/cups/lib/filter/epson-escpr2

This makes the binary executable again, but it is interesting that the result of readelf -l has been changed not only to rewrite INTERP...
Comment 2 Gleb Popov freebsd_committer freebsd_triage 2025-05-01 12:05:14 UTC
I don't get it, the patchelf workaround does work for you?
Comment 3 Tatsuki Makino 2025-05-01 21:41:45 UTC
(In reply to Gleb Popov from comment #2)

It seems that I succeeded in changing the differences in the file names of ld.
Whether it can be a workaround and whether it can perform the same operation is unknown :)

I think creating a symbolic link would be an easier solution, but since it will have an overall impact, it's not something to do this.
Will it be done on linux_base, or will a port be made for it?
Comment 4 Gleb Popov freebsd_committer freebsd_triage 2025-05-03 11:01:22 UTC
Using patchelf feels like a better solution for me. It is temporary anyways, as Rocky Linux Devel already has the redhat-lsb package that provides mentioned symlink. It probably will become available to Rocky Linux 9 soon.
Comment 5 commit-hook freebsd_committer freebsd_triage 2025-05-04 08:56:09 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=76b80cdd18028b2c151ab27e51babcfc71edc3d9

commit 76b80cdd18028b2c151ab27e51babcfc71edc3d9
Author:     Gleb Popov <arrowd@FreeBSD.org>
AuthorDate: 2025-05-03 12:09:27 +0000
Commit:     Gleb Popov <arrowd@FreeBSD.org>
CommitDate: 2025-05-04 08:55:13 +0000

    print/epson-inkjet-printer-escpr2: Use patchelf to set a correct ELF interpreter

    PR:             280388

 print/epson-inkjet-printer-escpr2/Makefile | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)
Comment 6 Tatsuki Makino 2025-05-04 22:02:06 UTC
(In reply to commit-hook from comment #5)

Thank you very much.
I don't know because I'm not following that trend, but is it no longer necessary to support i386?
It seems that i386 will be used with LINUX_DEFAULT=c7.
Comment 7 Gleb Popov freebsd_committer freebsd_triage 2025-05-05 06:21:44 UTC
(In reply to Tatsuki Makino from comment #6)
It is possible to support i386 (well, i686) with Rocky Linux, it is just a lot of work and nobody has done it.