From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 17C0C3865460; Fri, 6 Aug 2021 04:52:37 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 17C0C3865460 From: "patrick.mccarty at intel dot com" To: glibc-bugs@sourceware.org Subject: [Bug locale/28199] New: iconvconfig prefix flag behaves differently in glibc 2.34 Date: Fri, 06 Aug 2021 04:52:36 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: locale X-Bugzilla-Version: 2.34 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: patrick.mccarty at intel dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: glibc-bugs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Glibc-bugs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2021 04:52:37 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D28199 Bug ID: 28199 Summary: iconvconfig prefix flag behaves differently in glibc 2.34 Product: glibc Version: 2.34 Status: UNCONFIRMED Severity: normal Priority: P2 Component: locale Assignee: unassigned at sourceware dot org Reporter: patrick.mccarty at intel dot com Target Milestone: --- Overview: --------- In glibc 2.34, I observed that the gconv-modules cache created by `iconvcon= fig --prefix=3DPATHPREFIX` contains a module lookup path with a prepended value= of PATHPREFIX. That is, the lookup path is "PATHPREFIX/LIBDIR/gconv-modules/". However, in glibc 2.33 and earlier, the module lookup path from the cache created by the same command does *not* contain that prepended value. Instead the path is "LIBDIR/gconv-modules/". I don't know if this is an expected change or a bug, but the distro I contribute to (Clear Linux OS) relies on the behavior from glibc <=3D 2.33,= since the distro package re-creates the gconv module cache (with `iconvconfig --prefix=3D%{buildroot}`) after the `make install`, running as a non-root u= ser. Thus, the expectation has been for the cache file to be pre-populated and n= ot created via %post scripts or equivalent mechanisms. Steps to Reproduce: ------------------- I tested on Clear Linux OS, comparing the results on release 34900 (with gl= ibc 2.33) to 34930 (with glibc 2.34). But any equivalent setup to compare `iconvconfig` behavior from glibc 2.33 to 2.34 will work. 1. Run the following series of commands (or equivalent). They assume the gl= ibc under test is installed system-wide and that the installation libdir is /usr/lib64. $ mkdir -p /tmp/usr/lib64 $ cp -a /usr/lib64/gconv /tmp/usr/lib64/ $ rm -f /tmp/usr/lib64/gconv/gconv-modules.cache $ iconvconfig --prefix=3D/tmp -o foo $ strings foo | grep /usr/lib64/gconv Actual Results: --------------- The grep command prints `/tmp/usr/lib64/gconv/`, demonstrating that the path prefix, `/tmp`, is prepended to the cache lookup path.=20 Expected Results: ----------------- The grep command prints `/usr/lib64/gconv/`, demonstrating that the path pr= efix is omitted from the lookup path. This is the behavior in glibc <=3D 2.33. --=20 You are receiving this mail because: You are on the CC list for the bug.=