Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 657330 - some package should own /usr/sbin/fix_libtool_files.sh
Summary: some package should own /usr/sbin/fix_libtool_files.sh
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Toolchain Maintainers
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-06-04 12:55 UTC by aeriksson2
Modified: 2020-07-30 18:39 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description aeriksson2 2018-06-04 12:55:24 UTC
During maintenance I discovered an orphaned file


rpi2 /usr #  qfile -o /usr/sbin/*
/usr/sbin/fix_libtool_files.sh
rpi2 /usr # equery l gcc*
 * Searching for gcc* ...
[I-O] [  ] sys-devel/gcc-6.4.0-r1:6.4.0
[IP-] [  ] sys-devel/gcc-config-1.8-r1:0
rpi2 /usr # ls /var/cache/portage/sys-devel/gcc/gcc-6.4.0-r
gcc-6.4.0-r1.ebuild  gcc-6.4.0-r2.ebuild  
rpi2 /usr # emerge -av gcc

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R    ] sys-devel/gcc-6.4.0-r1:6.4.0::gentoo  USE="cxx nptl openmp pch sanitize ssp vtv (-altivec) (-awt) (-cilk) -debug -doc (-fixed-point) -fortran (-gcj) -go -graphite (-hardened) (-jit) (-libssp) (-mpx) (-multilib) -nls -objc -objc++ -objc-gc -pgo (-pie) -regression-test -vanilla" 0 KiB

Total: 1 package (1 reinstall), Size of downloads: 0 KiB

Would you like to merge these packages? [Yes/No] n

Quitting.


Can that fix_libtool_files.sh be removed? I keep seeing statements that manually invoking it and it's "part of toolchain" or some such. if that's so, it should be owned by toolchain and likely live in /usr/libexec or whatnot.

/
Comment 1 cyrillic 2018-06-04 22:28:01 UTC
On my machines, it has been owned by gcc for as long as I can remember.

# equery belongs fix_libtool_files.sh
 * Searching for fix_libtool_files.sh ... 
sys-devel/gcc-8.1.0-r3 (/usr/share/gcc-data/x86_64-pc-linux-gnu/8.1.0/fix_libtool_files.sh)
Comment 2 Sergei Trofimovich (RETIRED) gentoo-dev 2018-06-08 19:36:33 UTC
As gcc is a multislotted package fix_libtool_files.sh has to me managed carefully from gcc ebuilds (or should be moved out to a separate package). Today fix_libtool_files.sh is installed around package manager:

https://gitweb.gentoo.org/repo/gentoo.git/tree/eclass/toolchain.eclass#n2136

Historically gcc ebuild uses gcc-config and managed orphan symlinks.
Same goes for /usr/bin/gcc and friends:

$ qfile -o /usr/bin/gcc
/usr/bin/gcc
Comment 3 Sergei Trofimovich (RETIRED) gentoo-dev 2020-06-19 17:22:36 UTC
If I read fixlafiles.awk correctly it can mangle two things in .la fils:

1. patch reference 'from .../libstdc++.la' to '-lstdc++'
2. change ${CHOST} when user switches CHOST and rebuilds the system

[1.] is not relevant since gcc-4 in Gentoo where we started deleting libstdc++.la on gcc installation. Nothing should embed libstdc++.la paths anymore.

[2.] is a rare one-off step that has a lot more caveats than just .la file patching.

Generally .la files are tracked by package manager and should not be changed after they are installed on disk. fix_libtool_files.sh breaks that invariant.

I think we can just remove fix_libtool_files.sh and fixlafiles.awk completely and if really needed reintroduce it as a separate tool.
Comment 4 Larry the Git Cow gentoo-dev 2020-06-19 20:52:51 UTC
The bug has been closed via the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=92e383747ffc633ff6e85a02bf8cdb856eb1bcdc

commit 92e383747ffc633ff6e85a02bf8cdb856eb1bcdc
Author:     Sergei Trofimovich <slyfox@gentoo.org>
AuthorDate: 2020-06-19 18:15:21 +0000
Commit:     Sergei Trofimovich <slyfox@gentoo.org>
CommitDate: 2020-06-19 20:52:43 +0000

    toolchain.eclass: drop fix_libtool_files.sh
    
    fixlafiles.awk can mangle two things in .la fils:
    
    1. patch reference 'from .../libstdc++.la' to '-lstdc++'
    2. change ${CHOST} when user switches CHOST and rebuilds the system
    
    [1.] is not relevant since gcc-4 in Gentoo where we started deleting
    libstdc++.la on gcc installation. Nothing should embed libstdc++.la
    paths anymore.
    
    [2.] is a rare one-off step that has a lot more caveats than just .la
    file patching.
    
    Generally .la files are tracked by package manager and should not be
    changed after they are installed on disk. 'fix_libtool_files.sh' breaks
    that invariant.
    
    On top of that portage's FEATURES=fixlafiles removes nested .la files
    references.
    
    Let's remove 'fix_libtool_files.sh' and 'fixlafiles.awk' completely.
    If really needed we can reintroduce it as a separate tool.
    
    Closes: https://bugs.gentoo.org/722554
    Closes: https://bugs.gentoo.org/657330
    Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

 .../gnat-gpl/files/awk/fixlafiles.awk-no_gcc_la    | 334 ---------------------
 dev-lang/gnat-gpl/files/fix_libtool_files.sh       |  66 ----
 eclass/toolchain.eclass                            |  40 +--
 sys-devel/gcc/files/awk/fixlafiles.awk             | 313 -------------------
 sys-devel/gcc/files/awk/fixlafiles.awk-no_gcc_la   | 334 ---------------------
 sys-devel/gcc/files/fix_libtool_files.sh           |  66 ----
 6 files changed, 9 insertions(+), 1144 deletions(-)