Commit Message

I may have submitted this shortly before the Caudren, and it got lost.
This patch adds 4 additional configuration switches, that allow the person
building the compiler to add additional prefixes to search for additional
executables and startfiles.
If the backend has the appropriate tweaks installed, it will also add
additional prefixes to search for the dynamic linker. At the moment, only the
PowerPC Linux port has the modifications. It is fairly easy to modify other
targets if desired.
The motivation for this comes from the IBM Advance Toolchain (AT), which runs
on PowerPC Linux 64-bit system running on IBM server class machines (power4
through power7). AT provides its own version of the standard libraries and its
own dynamic linker. Unlike a cross compiler environment where you want to use
--sysroot to not reference any of the host libraries, a release compiler like
this wants to be able to use the system libraries and include files if it
doesn't provide for them in the release.
The released version of the AT has the sources modified so that it uses the
pathnames for the release instead of the standard library and executable
pathnames. When we are doing development, it would be convenient to have the
compilers that we build target the AT directly without having to use the
appropriate linker/include options to use the AT executables, libraries, and
dynamic linker.
I have built compilers without these patches, with the patches but not adding
the configuration options, and with these patches using the configuration
options. The compilers all bootstrapped. In running the regression suite
there are two differences when the option is used:
gcc.dg/cproj-fails-with-broken-glibc.c fails on SLES 11SP1, but works fine when
linked with the AT 6.0 libraries, which is expected, since the AT library is
based on a newer baseline thatn Sles 11SP1.
gfortran.dg/bessel_6.f90 fails when using the Advance Toolchain 6.0 libraries,
due to the bessel jn function returning slightly differenct values, which
causes the test to fail. If I use the Advance Toolchain 5.0 library, it works
fine. I have entered the bug into AT bugzilla.
Both of these errors show that when the options are used, it does in fact use
the alternative library instead of the system libraries.
I have broken these patches into 2 attachments. The first attachment
(gcc-power7.patch369c) are the machine independent changes. The second
attachment (gcc-power7.patch369d) are just the powerpc specific changes.
Are these patches ok to install?
2012-11-01 Michael Meissner <meissner@linux.vnet.ibm.com>
* configure.ac (--with-extra-prefix=): Add configure time switches
to add addition prefix directories for the compiler to search for
extra executables, startfiles, and directories to add to the list
of shared library locations.
(--with-extra-exec-prefix=): Likewise.
(--with-extra-startfile-prefix=): Likewise.
(--with-extra-rpath-prefix=): Likewise.
* configure: Regenerate.
* doc/install.texi (--with-extra-prefix=): Document new configure
switches.
(--with-extra-exec-prefix=): Likewise.
(--with-extra-startfile-prefix=): Likewise.
(--with-extra-rpath-prefix=): Likewise.
* gcc.c (LINK_RPATH_DIRS_SPEC): Add support for configuration time
additional executable, startfile, and shared library location
prefixes. Add %find-dynamic-linker(), %extra-rpath-dirs(),
%extra-cpu-dirs() as spec functions.
(LINK_COMMAND_SPEC): Likewise.
(CONFIGURE_STARTFILE_PREFIX): Likewise.
(configure_startfile_prefix): Likewise.
(configure_exec_prefix): Likewise.
(static_spec_functions): Likewise.
(IS_STD_DIR): Likewise.
(config_rpath): Likewise.
(build_rpath_or_cpu_dirs): Likewise.
(extra_rpath_dirs_spec_function): Likewsie.
(extra_cpu_dirs_spec_function): Likewise.
(find_dynamic_linker_spec_function): Likewise.
(add_multiple_prefix): New function that is like add_prefix, but
splits the prefix at PATH_SEPARATOR.
(process_command): Simplify processing COMPILER_PATH, LPATH, and
LIBRARY_PATH_ENV environment variables by using the function
add_multiple_prefix to do the splitting of the separate prefixes.
Add support for the configuration switch to add new executable,
startfile, and shared library prefixes.
* gcc.h (extra_cpu_dirs_spec_function): Add declaration.
* config.in (CONFIGURE_EXEC_PREFIX): Add defines for the configure
switches to add executable, startfile, and shared library
configuration directories.
(CONFIGURE_STARTFILE_PREFIX): Likewise.
(CONFIGURE_RPATH_PREFIX): Likewise.
* config/rs6000/x-rs6000 (driver-rs6000.o): Add $(GCC_H)
dependency.
* config/rs6000/linux64.h (GLIBC_DYNAMIC_LINKER32): If
--with-extra-startfile-prefix or --with-extra-prefix was used, use
%find-dynamic-linker() to find the dynamic linker in the startfile
prefixes.
(GLIBC_DYNAMIC_LINKER64): Likewise.
(LINUX_EXTRA_STATIC_LIBDIRS64): Likewise.
(LINK_OS_LINUX_SPEC32): Likewise.
(LINK_OS_LINUX_SPEC64): Likewise.
* config/rs6000/rs6000.h (EXTRA_SPEC_FUNCTIONS): Likewise.
(LOCAL_CPU_EXTR_SPEC_FUNCTIONS): Likewise.
* config/rs6000/sysv4.h (GLIBC_DYNAMIC_LINKER): Likewise.
(LINUX_EXTRA_STATIC_LIBDIRS32): Likewise.
(LINK_OS_LINUX_SPEC): Likewise.
(rs6000_extra_static_libdirs): Likewise.
(SUBTARGET_EXTRA_SPEC_FUNCTIONS): Likewise.
* config/rs6000/driver-rs6000.c (toplevel): Include gcc.h.
(rs6000_extra_static_libdirs): If we have extra configure
startfile prefixes, look for a machine specific file as a
subdirectory in the startfile prefixes if the user used
-mcpu=<xxx>.

Comments

On Thu, 1 Nov 2012, Michael Meissner wrote:
> * doc/install.texi (--with-extra-prefix=): Document new configure> switches.> (--with-extra-exec-prefix=): Likewise.> (--with-extra-startfile-prefix=): Likewise.> (--with-extra-rpath-prefix=): Likewise.
+On powerpc64-linux systems, the dynamic linker will be searched for in
+the directories specified by the prefixed, that is used instead of the
^^^^^^^^
+standard system dynamic linker.
Is the use of "prefixed" correct her, or would that be "prefixes"?
+In addition on powerpc64-linux systems, if the user used static
"the user used" comes across a bit oddly. How about "requests"?
+linking, as well as the @option{-mcpu=} option, the linker will be
Do I understand this correctly that both must hold? Perhaps say "plus"
to avoid any ambiguity?
+for that particular machine. If dynamic linking is used, these cpu
+tuned libraries will not be searched, since the dynamic linker will
+load the appropriate cpu tuned library, based on the system that is
+executing the code.
CPU (uppercase) in two cases.
+@item --with-extra-rpath-prefix=@var{prefixes}
+Specify additional directories for finding shared libraries when
+the compiler is run. Each prefix is separated by the standard path
+sepator (usually colon, @option{:}). By default no extra prefixes are
+used. If this option is used, each of the directories if they exist
+will be specified to the linker via the @option{-rpath=} option.
"each of the directories if they exist" is a bit confusing ("each"
versus "they").
Do you mean "each of the directories that exists on the build system
will be..." or something like that?
Gerald

On Fri, Nov 02, 2012 at 12:22:07AM +0100, Gerald Pfeifer wrote:
> On Thu, 1 Nov 2012, Michael Meissner wrote:> > * doc/install.texi (--with-extra-prefix=): Document new configure> > switches.> > (--with-extra-exec-prefix=): Likewise.> > (--with-extra-startfile-prefix=): Likewise.> > (--with-extra-rpath-prefix=): Likewise.> > +On powerpc64-linux systems, the dynamic linker will be searched for in> +the directories specified by the prefixed, that is used instead of the> ^^^^^^^^> +standard system dynamic linker.> > Is the use of "prefixed" correct her, or would that be "prefixes"?
You are right that doesn't make sense. The paragraph should read:
On powerpc64-linux systems, the dynamic linker will be searched for in
the directories specified by the prefixes before falling back to the
standard system dynamic linker which is used if an alternate dynamic
linker could not be found.
> +In addition on powerpc64-linux systems, if the user used static> > "the user used" comes across a bit oddly. How about "requests"?> > +linking, as well as the @option{-mcpu=} option, the linker will be> > Do I understand this correctly that both must hold? Perhaps say "plus"> to avoid any ambiguity?> > +for that particular machine. If dynamic linking is used, these cpu> +tuned libraries will not be searched, since the dynamic linker will> +load the appropriate cpu tuned library, based on the system that is> +executing the code.
Yes. The paragraph should read:
In addition on powerpc64-linux systems, if the user used static
linking and the @option{-mcpu=} option at the same time, the linker
will be told to search in appropriate directories for libraries that
are built for that particular machine. If dynamic linking is used,
these cpu tuned libraries will not be searched, since the dynamic
linker will load the appropriate cpu tuned library, based on the
system that is executing the code.
> CPU (uppercase) in two cases.> > +@item --with-extra-rpath-prefix=@var{prefixes}> +Specify additional directories for finding shared libraries when> +the compiler is run. Each prefix is separated by the standard path> +sepator (usually colon, @option{:}). By default no extra prefixes are> +used. If this option is used, each of the directories if they exist> +will be specified to the linker via the @option{-rpath=} option.> > "each of the directories if they exist" is a bit confusing ("each"> versus "they").> > Do you mean "each of the directories that exists on the build system> will be..." or something like that?
What the compiler does is search for the directories to exist when the compiler
is run (not when it is built). If they exist, the linker on powerpc64-linux
will be told via -rpath to add these paths so that when the program is run, the
right libraries are loaded.
For example, if I have AT 6.0 installed on my Sles 11SP1 system, it is
installed in:
/opt/at6.0
Normally when you build the compiler using the host libraries, the linker gets
passed:
-dynamic-linker /lib64/ld64.so.1
With the alternatate configuration support, the linker would get passed:
-rpath=/home/meissner/fsf-install-ppc64/atdirs2/lib64
-rpath=/opt/at6.0/lib64
-dynamic-linker /opt/at6.0/lib64/ld64.so.1
where /home/meissner/fsf-install-ppc64/atdirs2/lib64 happens to be the install
directory for the compiler being built, so its libraries override the AT 6
libraries.

On Thu, Nov 1, 2012 at 5:17 PM, Michael Meissner
<meissner@linux.vnet.ibm.com> wrote:
> This patch adds 4 additional configuration switches, that allow the person> building the compiler to add additional prefixes to search for additional> executables and startfiles.>> If the backend has the appropriate tweaks installed, it will also add> additional prefixes to search for the dynamic linker. At the moment, only the> PowerPC Linux port has the modifications. It is fairly easy to modify other> targets if desired.
Why does the documentation refer to powerpc64-linux when the changes
affect all PowerPC Linux and affect the 32 bit dynamic linker search
path?
Thanks, David

On Sat, Nov 03, 2012 at 07:01:04PM -0400, David Edelsohn wrote:
> On Thu, Nov 1, 2012 at 5:17 PM, Michael Meissner> <meissner@linux.vnet.ibm.com> wrote:> > > This patch adds 4 additional configuration switches, that allow the person> > building the compiler to add additional prefixes to search for additional> > executables and startfiles.> >> > If the backend has the appropriate tweaks installed, it will also add> > additional prefixes to search for the dynamic linker. At the moment, only the> > PowerPC Linux port has the modifications. It is fairly easy to modify other> > targets if desired.> > Why does the documentation refer to powerpc64-linux when the changes> affect all PowerPC Linux and affect the 32 bit dynamic linker search> path?
Yes, obviously I should have included powerpc-linux as well as powerpc64-linux
in the documentation. Thanks. If it is approved, I will update the
documentation.

On Mon, Nov 5, 2012 at 12:27 PM, Michael Meissner
<meissner@linux.vnet.ibm.com> wrote:
> Yes, obviously I should have included powerpc-linux as well as powerpc64-linux> in the documentation. Thanks. If it is approved, I will update the> documentation.
The rs6000 parts of the patch are okay with that change.
Thanks, David

Other than David approving of the powerpc stuff, and Gerald Pfeifer asking a
question, I didn't get any response for my patch to add new configuration
options to enable additional executable/startfile/shared library prefixes:
http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00144.html
Can I get a global maintainer or driver maintainer to look at it? Thanks in
advance.