Re: [Bug middle-end/45508] New: Does adding configure-options for specs-hardcoding make sense?
You could use a small wrapper script that adds R option instead of a
specs file or adds the specs file to the command line.
On Sep 2, 2010, at 12:48 PM, "nicolai dot stange at zmaw dot de" > wrote:
Hi everybody,
I'm not involved in any gcc development nor am I familiar with gcc
and its
components and thus, the attached patch is just a place to start
from if you
agree with me that my request for adding more control over the specs
via
configure options makes sense.
My problem is this one:
At our site, we provide many versions of several compilers,
including the great
GCC, at non-standard locations. The problem is with the runtime
search paths
for the libgcc_s, ...: The runtime linker always finds the most
wrong one: The
one from Blastwave in /opt/csw/lib (this is Solaris-specific, but if
it were
Linux or sth. other, it would also find the wrong libgcc_s, shipped
with the
distribution, or none at all).
Asking the kind guys in #gcc at freenode, they told me that I might
want to
supply a specs file. Hmm, I want to set site-wide specs for all users
transparently. Reading the sourcecode of gcc, I recognized that I
can put a
complete specs file to /lib/gcc///specs.
(I didn't find any documentation about that feature, so maybe this
lack of docs
is another bug?).
But this solution has two drawbacks for me:
- I'm bootstrapping and the linking of the runtime libraries for the
target
would not be influenced by placing this specs-file _after_
installation. Ok, I
could go with LDFLAGS_FOR_TARGET, but this would make the whole
thing more
non-convenient (at least in my opionion).
- Creating that specs-file for every GCC-release makes automating
the GCC
deployment harder: At first I have to check if the default-specs are
still the
same, the I have to modify them to insert a runtime search path for
the new
installation location and then I have to put it at the right
location. It seems
that I have to exercise some bash/sed/diff/m4-tasks...
Another solution would be this:
Adding a --with-link-libgcc-specs option to the configure in the
gcc-subdirectory, I could configure gcc with
../gcc-4.5.1/configure
--with-link-libgcc-specs="\${!m64:-R/opt/gcc-4.5.1/lib}\${m64:-R/opt/
gcc-4.5.1/lib/sparcv9}"
...
(btw: "-R" is the "-rpath"-equivalent of the Sun Linker on Solaris)
If this user-supplied spec would be prepended/appended to the default
link_libgcc spec, all would be fine.
The attached patch is for link_libgcc spec only, but maybe altering
the other
specs by configure-options might be useful for other people under
other
circumstances, too?
Please note again, that the attached patch is just a quick hack, if
you agree
to add those options, one should have a closer look.
Best wishes
Nicolai
--
Summary: Does adding configure-options for specs-
hardcoding make
sense?
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nicolai dot stange at zmaw dot de
GCC build triplet: sparc-sun-solaris2.10
GCC host triplet: sparc-sun-solaris2.10
GCC target triplet: sparc-sun-solaris2.10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45508
[Bug middle-end/45508] New: Does adding configure-options for specs-hardcoding make sense?
Hi everybody,
I'm not involved in any gcc development nor am I familiar with gcc and its
components and thus, the attached patch is just a place to start from if you
agree with me that my request for adding more control over the specs via
configure options makes sense.
My problem is this one:
At our site, we provide many versions of several compilers, including the great
GCC, at non-standard locations. The problem is with the runtime search paths
for the libgcc_s, ...: The runtime linker always finds the most wrong one: The
one from Blastwave in /opt/csw/lib (this is Solaris-specific, but if it were
Linux or sth. other, it would also find the wrong libgcc_s, shipped with the
distribution, or none at all).
Asking the kind guys in #gcc at freenode, they told me that I might want to
supply a specs file. Hmm, I want to set site-wide specs for all users
transparently. Reading the sourcecode of gcc, I recognized that I can put a
complete specs file to /lib/gcc///specs.
(I didn't find any documentation about that feature, so maybe this lack of docs
is another bug?).
But this solution has two drawbacks for me:
- I'm bootstrapping and the linking of the runtime libraries for the target
would not be influenced by placing this specs-file _after_ installation. Ok, I
could go with LDFLAGS_FOR_TARGET, but this would make the whole thing more
non-convenient (at least in my opionion).
- Creating that specs-file for every GCC-release makes automating the GCC
deployment harder: At first I have to check if the default-specs are still the
same, the I have to modify them to insert a runtime search path for the new
installation location and then I have to put it at the right location. It seems
that I have to exercise some bash/sed/diff/m4-tasks...
Another solution would be this:
Adding a --with-link-libgcc-specs option to the configure in the
gcc-subdirectory, I could configure gcc with
../gcc-4.5.1/configure
--with-link-libgcc-specs="\${!m64:-R/opt/gcc-4.5.1/lib}\${m64:-R/opt/gcc-4.5.1/lib/sparcv9}"
...
(btw: "-R" is the "-rpath"-equivalent of the Sun Linker on Solaris)
If this user-supplied spec would be prepended/appended to the default
link_libgcc spec, all would be fine.
The attached patch is for link_libgcc spec only, but maybe altering the other
specs by configure-options might be useful for other people under other
circumstances, too?
Please note again, that the attached patch is just a quick hack, if you agree
to add those options, one should have a closer look.
Best wishes
Nicolai
--
Summary: Does adding configure-options for specs-hardcoding make
sense?
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nicolai dot stange at zmaw dot de
GCC build triplet: sparc-sun-solaris2.10
GCC host triplet: sparc-sun-solaris2.10
GCC target triplet: sparc-sun-solaris2.10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45508
