From: "Mike Frysinger" <vapier@gentoo.org>
To: gentoo-commits@lists.gentoo.org
Subject: [gentoo-commits] proj/gcc-config:master commit in: /
Date: Mon, 19 Nov 2012 01:11:25 +0000 (UTC) [thread overview]
Message-ID: <1353284826.9021391c1b8aca00b3b09b03766bd0d09f7ed339.vapier@gentoo> (raw)
commit: 9021391c1b8aca00b3b09b03766bd0d09f7ed339
Author: Mike Frysinger <vapier <AT> gentoo <DOT> org>
AuthorDate: Sat Sep 29 06:32:45 2012 +0000
Commit: Mike Frysinger <vapier <AT> gentoo <DOT> org>
CommitDate: Mon Nov 19 00:27:06 2012 +0000
URL: http://git.overlays.gentoo.org/gitweb/?p=proj/gcc-config.git;a=commit;h=9021391c
gcc-config: only handle default ABI libgcc_s with split /usr
Since a split /usr system should only be running the default ABI before
mounting /usr, there's no need to walk and setup all the other ABIs.
This might break very weird systems, but they shouldn't be doing that
in the first place. And this makes the code much simpler.
Signed-off-by: Mike Frysinger <vapier <AT> gentoo.org>
---
gcc-config | 70 ++++++++++++++++++-----------------------------------------
1 files changed, 22 insertions(+), 48 deletions(-)
diff --git a/gcc-config b/gcc-config
index 9cf69fb..0445335 100755
--- a/gcc-config
+++ b/gcc-config
@@ -294,32 +294,15 @@ handle_split_usr() {
#
# The funky move magic is required for proper updating of in-use files.
#
- # XXX: This fails when configuring the native target in a cross-compiled
- # ROOT. Only way around that is to store the multilib configuration
- # in the gcc profile when we compiled it and then read that instead
- # of executing the gcc. Some day.
- #
# We use the same ordering logic as mentioned in the MY_LDPATH setup.
# We get the libs from the latest version available.
- local LATEST_GCC_PATH gcc LATEST_GCC_LDPATH
-
- eval $(gawk -F= '
- {
- if ($1 == "GCC_PATH") {
- p = gensub("\"","","g",$2)
- } else if ($1 == "LDPATH") {
- l = gensub("\"","","g",$2)
- }
- }
- END {
- print "LATEST_GCC_PATH=\"" p "\""
- print "LATEST_GCC_LDPATH=\"" l "\""
- }
- ' "${GCC_ENV_D}"/${CHOST}-*
- )
+ local LDPATH
+
+ eval $(grep -h '^LDPATH=' "${GCC_ENV_D}"/${CHOST}-* | tail -1)
+ LDPATH=${LDPATH%%:*}
# If /usr isn't a sep mount, then don't bother with linking stuff.
- if ln "${ROOT}/${LATEST_GCC_LDPATH%%:*}/libgcc.a" "${ROOT}"/lib/.gcc.config.$$ 2>/dev/null ; then
+ if ln "${ROOT}/${LDPATH}/libgcc.a" "${ROOT}"/lib/.gcc.config.$$ 2>/dev/null ; then
rm -f "${ROOT}"/lib/.gcc.config.$$
if [[ -n $(find "${ROOT}"/lib*/lib{gcc_s,unwind}.so* 2>/dev/null) ]] ; then
# If we previously had stuff in /, make sure ldconfig gets re-run.
@@ -329,34 +312,25 @@ handle_split_usr() {
return 0
fi
- gcc="${ROOT}${LATEST_GCC_PATH}/gcc"
-
- local multilib
- for multilib in $("${gcc}" -print-multi-lib); do
- local multiarg=${multilib#*;}
- multiarg=${multiarg/@/-}
- local multilibdir=${multilib%;*}
- local libdir="${ROOT}lib/"$("${gcc}" ${multiarg} -print-multi-os-directory)
-
- mkdir -p "${libdir}"/.gcc.config.new || continue # !?!?!
-
- local gcclib
- for gcclib in gcc_s unwind ; do
- # This assumes that we always have the .so symlink,
- # but for now, that should be safe ...
- gcclib=$("${gcc}" -print-file-name="lib${gcclib}.so")
- if [[ ${gcclib} == */* ]] ; then
- cp -pP "${ROOT}${gcclib}".* "${libdir}"/.gcc.config.new/
- # no need to sanity remove this as the `mv` should take
- # care of it. we also need this step to be completly atomic
- # for systems that have even `mv` linked against libgcc_s.so.
- # http://bugs.gentoo.org/150257
- #rm -f "${libdir}"/lib${gcclib}.so*
- mv -f "${libdir}"/.gcc.config.new/* "${libdir}"/
- fi
+ # Only bother with this stuff for the native ABI. We assume the user
+ # doesn't have critical binaries for non-native ABIs which is fair.
+ local gcclib
+ local libdir="${ROOT}${GENTOO_LIBDIR}"
+ mkdir -p "${libdir}"/.gcc.config.new || return 0 # !?!?!
+ for gcclib in gcc_s unwind ; do
+ # This assumes that we always have the .so symlink,
+ # but for now, that should be safe ...
+ for gcclib in "${ROOT}${LDPATH}"/lib${gcclib}.so.* ; do
+ [[ -e ${gcclib} ]] || continue
+ cp -pP "${gcclib}" "${libdir}"/.gcc.config.new/
+ # no need to sanity `rm` this as the `mv` should take care
+ # of it. we also need this step to be completely atomic
+ # for systems that have even `mv` linked against libgcc_s.so.
+ # http://bugs.gentoo.org/150257
+ mv -f "${libdir}"/.gcc.config.new/* "${libdir}"/
done
- rmdir "${libdir}"/.gcc.config.new
done
+ rmdir "${libdir}"/.gcc.config.new
return 0
}
next reply other threads:[~2012-11-19 1:11 UTC|newest]
Thread overview: 86+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-19 1:11 Mike Frysinger [this message]
-- strict thread matches above, loose matches on Subject: below --
2024-12-08 3:26 [gentoo-commits] proj/gcc-config:master commit in: / Sam James
2024-12-08 3:19 Sam James
2024-12-08 3:18 Sam James
2023-05-31 5:55 Sam James
2023-05-31 5:54 Sam James
2023-05-14 17:25 Sam James
2023-04-30 2:59 Sam James
2023-01-05 0:16 Sam James
2022-12-28 19:12 Sam James
2022-12-28 19:12 Sam James
2022-12-28 19:12 Sam James
2022-10-10 14:09 Sam James
2022-10-09 20:55 Sam James
2022-10-08 22:02 Sam James
2022-09-29 22:36 Sam James
2022-09-29 22:36 Sam James
2022-09-22 23:46 Sam James
2021-11-13 4:49 Sam James
2021-11-13 4:49 Sam James
2021-02-26 9:36 Sergei Trofimovich
2021-02-26 9:36 Sergei Trofimovich
2021-02-26 9:36 Sergei Trofimovich
2021-02-26 9:36 Sergei Trofimovich
2021-02-26 8:40 Sergei Trofimovich
2021-01-23 17:51 Sergei Trofimovich
2020-09-05 18:11 Sergei Trofimovich
2020-06-24 20:47 Sergei Trofimovich
2020-06-21 11:53 Sergei Trofimovich
2020-06-21 11:50 Sergei Trofimovich
2020-05-23 7:28 Sergei Trofimovich
2020-05-22 13:23 Sergei Trofimovich
2020-05-22 13:20 Sergei Trofimovich
2020-05-22 11:33 Sergei Trofimovich
2020-05-22 10:39 Sergei Trofimovich
2020-05-22 10:03 Sergei Trofimovich
2020-05-22 9:40 Sergei Trofimovich
2020-04-10 10:08 Sergei Trofimovich
2020-01-26 13:44 Sergei Trofimovich
2020-01-26 13:26 Sergei Trofimovich
2019-09-08 8:37 Sergei Trofimovich
2019-09-08 8:29 Sergei Trofimovich
2019-09-07 22:08 Sergei Trofimovich
2019-09-07 9:39 Sergei Trofimovich
2019-09-07 9:39 Sergei Trofimovich
2019-09-07 9:15 Sergei Trofimovich
2019-09-07 9:01 Sergei Trofimovich
2019-09-07 8:47 Sergei Trofimovich
2019-09-07 8:22 Sergei Trofimovich
2019-09-06 7:29 Sergei Trofimovich
2019-09-06 7:23 Sergei Trofimovich
2019-09-06 6:53 Sergei Trofimovich
2019-09-06 6:53 Sergei Trofimovich
2019-09-05 22:35 Sergei Trofimovich
2019-09-05 7:24 Sergei Trofimovich
2019-09-05 6:47 Sergei Trofimovich
2019-09-05 6:42 Sergei Trofimovich
2019-09-05 6:28 Sergei Trofimovich
2019-09-04 19:00 Sergei Trofimovich
2019-09-04 19:00 Sergei Trofimovich
2018-08-24 16:40 Sergei Trofimovich
2018-08-24 8:50 Sergei Trofimovich
2018-08-24 0:23 Sergei Trofimovich
2018-08-13 22:39 Sergei Trofimovich
2018-08-13 21:55 Sergei Trofimovich
2017-12-16 21:11 Andreas Hüttel
2017-12-16 20:15 Andreas Hüttel
2017-12-15 8:33 Fabian Groffen
2015-08-05 8:12 Mike Frysinger
2015-08-05 7:52 Mike Frysinger
2015-05-13 4:26 Ryan Hill
2013-05-22 23:54 Mike Frysinger
2013-01-12 17:20 Mike Frysinger
2013-01-12 17:17 Mike Frysinger
2013-01-12 17:14 Mike Frysinger
2013-01-12 17:05 Mike Frysinger
2013-01-02 18:30 Mike Frysinger
2013-01-02 3:52 Mike Frysinger
2012-12-29 21:08 Mike Frysinger
2012-11-19 6:52 Mike Frysinger
2012-11-19 1:11 Mike Frysinger
2012-06-10 4:00 Mike Frysinger
2012-06-10 4:00 Mike Frysinger
2012-04-14 1:22 Mike Frysinger
2012-04-14 1:22 Mike Frysinger
2012-04-14 1:22 Mike Frysinger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1353284826.9021391c1b8aca00b3b09b03766bd0d09f7ed339.vapier@gentoo \
--to=vapier@gentoo.org \
--cc=gentoo-commits@lists.gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox