From: Nathanael Nerode <neroden@twcny.rr.com>
To: gcc-patches@gcc.gnu.org, binutils@sources.redhat.com,
gdb-patches@sources.redhat.com
Subject: [toplevel patch] Remove future variable name conflict in configure.in
Date: Thu, 26 Jun 2003 17:24:00 -0000 [thread overview]
Message-ID: <20030626172426.GA1569@doctormoo> (raw)
This is the only variable name conflict with config-lang.in fragments.
It turns out that target_libs isn't used after its late assignment
from the config-lang.in fragments, which makes the assignment worthless,
so I just deleted it.
Tested on i686-pc-linux-gnu.
This is the precursor to simply sourcing the config-lang.in fragments
at the top level rather than running them through ungodly sed expressions.
* configure.in: Rename 'target_libs' to 'target_libraries'.
Remove useless reference to 'target_libs'.
* configure: Regenerate.
Index: configure.in
===================================================================
RCS file: /cvs/gcc/gcc/configure.in,v
retrieving revision 1.241
diff -u -r1.241 configure.in
--- configure.in 23 Jun 2003 00:42:54 -0000 1.241
+++ configure.in 26 Jun 2003 17:19:29 -0000
@@ -136,7 +136,7 @@
# these libraries are built for the target environment, and are built after
# the host libraries and the host tools (which may be a cross compiler)
#
-target_libs="target-libiberty \
+target_libraries="target-libiberty \
target-libgloss \
target-newlib \
target-libstdc++-v3 \
@@ -144,10 +144,10 @@
${libgcj} \
target-libobjc"
-# these tools are built using the target libs, and are intended to run only
-# in the target environment
+# these tools are built using the target libraries, and are intended to
+# run only in the target environment
#
-# note: any program that *uses* libraries that are in the "target_libs"
+# note: any program that *uses* libraries that are in the "target_libraries"
# list belongs in this list. those programs are also very likely
# candidates for the "native_only" list which follows
#
@@ -162,7 +162,7 @@
## ${target_configdirs} is directories we build using the target tools.
#
configdirs=`echo ${host_libs} ${host_tools}`
-target_configdirs=`echo ${target_libs} ${target_tools}`
+target_configdirs=`echo ${target_libraries} ${target_tools}`
# Only make build modules if build != host.
# This should be done more generally, but at the moment it doesn't matter.
@@ -805,7 +805,7 @@
*) add_this_lang=no ;;
esac
if test x"${add_this_lang}" = xyes; then
- eval target_libs='"$target_libs "'\"$this_lang_libs\"
+ :
else
eval noconfigdirs='"$noconfigdirs "'\"$this_lang_libs $this_lang_dirs\"
fi
next reply other threads:[~2003-06-26 17:24 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-06-26 17:24 Nathanael Nerode [this message]
2003-06-26 18:38 ` DJ Delorie
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=20030626172426.GA1569@doctormoo \
--to=neroden@twcny.rr.com \
--cc=binutils@sources.redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=gdb-patches@sources.redhat.com \
/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