Ping: [PATCH] New configuration options to enable additional executable/startfile/shared library prefixes
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. -- Michael Meissner, IBM 5 Technology Place Drive, M/S 2757, Westford, MA 01886-3141, USA meiss...@linux.vnet.ibm.com fax +1 (978) 399-6899
Re: [PATCH] New configuration options to enable additional executable/startfile/shared library prefixes
On Mon, Nov 5, 2012 at 12:27 PM, Michael Meissner meiss...@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
Re: [PATCH] New configuration options to enable additional executable/startfile/shared library prefixes
On Sat, Nov 03, 2012 at 07:01:04PM -0400, David Edelsohn wrote: On Thu, Nov 1, 2012 at 5:17 PM, Michael Meissner meiss...@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. -- Michael Meissner, IBM 5 Technology Place Drive, M/S 2757, Westford, MA 01886-3141, USA meiss...@linux.vnet.ibm.com fax +1 (978) 399-6899
Re: [PATCH] New configuration options to enable additional executable/startfile/shared library prefixes
On Thu, Nov 1, 2012 at 5:17 PM, Michael Meissner meiss...@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
Re: [PATCH] New configuration options to enable additional executable/startfile/shared library prefixes
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.
--
Michael Meissner, IBM
5 Technology Place Drive, M/S 2757, Westford, MA 01886-3141, USA
meiss...@linux.vnet.ibm.com fax +1 (978) 399-6899
[PATCH] New configuration options to enable additional executable/startfile/shared library prefixes
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 meiss...@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
Re: [PATCH] New configuration options to enable additional executable/startfile/shared library prefixes
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
