public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug middle-end/45508] New: Does adding configure-options for specs-hardcoding make sense?
@ 2010-09-02 19:48 nicolai dot stange at zmaw dot de
2010-09-02 19:49 ` [Bug middle-end/45508] " nicolai dot stange at zmaw dot de
` (5 more replies)
0 siblings, 6 replies; 7+ messages in thread
From: nicolai dot stange at zmaw dot de @ 2010-09-02 19:48 UTC (permalink / raw)
To: gcc-bugs
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 <gcc_prefix>/lib/gcc/<target>/<version>/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
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug middle-end/45508] Does adding configure-options for specs-hardcoding make sense?
2010-09-02 19:48 [Bug middle-end/45508] New: Does adding configure-options for specs-hardcoding make sense? nicolai dot stange at zmaw dot de
@ 2010-09-02 19:49 ` nicolai dot stange at zmaw dot de
2010-09-02 19:55 ` pinskia at gmail dot com
` (4 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: nicolai dot stange at zmaw dot de @ 2010-09-02 19:49 UTC (permalink / raw)
To: gcc-bugs
------- Comment #1 from nicolai dot stange at zmaw dot de 2010-09-02 19:49 -------
Created an attachment (id=21678)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21678&action=view)
Adds --with-link-libgcc-specs to gcc-4.5.1/gcc/configure
Made against release 4.5.1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45508
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug middle-end/45508] Does adding configure-options for specs-hardcoding make sense?
2010-09-02 19:48 [Bug middle-end/45508] New: Does adding configure-options for specs-hardcoding make sense? nicolai dot stange at zmaw dot de
2010-09-02 19:49 ` [Bug middle-end/45508] " nicolai dot stange at zmaw dot de
@ 2010-09-02 19:55 ` pinskia at gmail dot com
2010-09-02 19:55 ` [Bug middle-end/45508] New: " Andrew Pinski
` (3 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: pinskia at gmail dot com @ 2010-09-02 19:55 UTC (permalink / raw)
To: gcc-bugs
------- Comment #2 from pinskia at gmail dot com 2010-09-02 19:55 -------
Subject: Re: 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"
<gcc-bugzilla@gcc.gnu.org
> 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 <gcc_prefix>/lib/gcc/<target>/<version>/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
>
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45508
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Bug middle-end/45508] New: Does adding configure-options for specs-hardcoding make sense?
2010-09-02 19:48 [Bug middle-end/45508] New: Does adding configure-options for specs-hardcoding make sense? nicolai dot stange at zmaw dot de
2010-09-02 19:49 ` [Bug middle-end/45508] " nicolai dot stange at zmaw dot de
2010-09-02 19:55 ` pinskia at gmail dot com
@ 2010-09-02 19:55 ` Andrew Pinski
2010-09-02 20:15 ` [Bug middle-end/45508] " nicolai dot stange at zmaw dot de
` (2 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: Andrew Pinski @ 2010-09-02 19:55 UTC (permalink / raw)
To: gcc-bugzilla; +Cc: gcc-bugs
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" <gcc-bugzilla@gcc.gnu.org
> 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 <gcc_prefix>/lib/gcc/<target>/<version>/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
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug middle-end/45508] Does adding configure-options for specs-hardcoding make sense?
2010-09-02 19:48 [Bug middle-end/45508] New: Does adding configure-options for specs-hardcoding make sense? nicolai dot stange at zmaw dot de
` (2 preceding siblings ...)
2010-09-02 19:55 ` [Bug middle-end/45508] New: " Andrew Pinski
@ 2010-09-02 20:15 ` nicolai dot stange at zmaw dot de
2010-09-02 22:29 ` pinskia at gcc dot gnu dot org
2010-09-04 19:31 ` nicolai dot stange at zmaw dot de
5 siblings, 0 replies; 7+ messages in thread
From: nicolai dot stange at zmaw dot de @ 2010-09-02 20:15 UTC (permalink / raw)
To: gcc-bugs
------- Comment #3 from nicolai dot stange at zmaw dot de 2010-09-02 20:15 -------
> 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.
This would change nothing:
- The bootstrapping problem remains
- Whether I add a specs file or a wrapper script for every gcc release's
deployment doesn't make a great difference (except that I would not have to
check the default specs for changes every time)
It is not a question whether it is possible to work around it (I've already
done it), but whether it would be good to provide a more convenient way and
whether enough people would benefit from this patch to justify it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45508
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug middle-end/45508] Does adding configure-options for specs-hardcoding make sense?
2010-09-02 19:48 [Bug middle-end/45508] New: Does adding configure-options for specs-hardcoding make sense? nicolai dot stange at zmaw dot de
` (3 preceding siblings ...)
2010-09-02 20:15 ` [Bug middle-end/45508] " nicolai dot stange at zmaw dot de
@ 2010-09-02 22:29 ` pinskia at gcc dot gnu dot org
2010-09-04 19:31 ` nicolai dot stange at zmaw dot de
5 siblings, 0 replies; 7+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2010-09-02 22:29 UTC (permalink / raw)
To: gcc-bugs
------- Comment #4 from pinskia at gcc dot gnu dot org 2010-09-02 22:28 -------
The problem with the configure is the libgcc specs are very target dependent.
Anyways I don't see the issue with using -R in a wrapper script and while
bootstrapping in LIB_CFLAGS="-R" .
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45508
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug middle-end/45508] Does adding configure-options for specs-hardcoding make sense?
2010-09-02 19:48 [Bug middle-end/45508] New: Does adding configure-options for specs-hardcoding make sense? nicolai dot stange at zmaw dot de
` (4 preceding siblings ...)
2010-09-02 22:29 ` pinskia at gcc dot gnu dot org
@ 2010-09-04 19:31 ` nicolai dot stange at zmaw dot de
5 siblings, 0 replies; 7+ messages in thread
From: nicolai dot stange at zmaw dot de @ 2010-09-04 19:31 UTC (permalink / raw)
To: gcc-bugs
------- Comment #5 from nicolai dot stange at zmaw dot de 2010-09-04 19:31 -------
(In reply to comment #4)
> The problem with the configure is the libgcc specs are very target dependent.
Yes, and that's the reason why I think that others might benefit from those
configure-options.
Another remark that I forgot in my first post: There's already an --with-specs
option that sets some specs for something (I don't know for what exactly, but
it can't be used to set link options, I already tried it: Some other tools
complain about unknown options).
If your concern is about the work, not about the additional complexicity:
I would do the work to add those options, just tell me
- For which specs I should do it (all or just link_libgcc)
- How do you want the CPP-Macros for the values of the configure-options to be
named?
- Should those values override or be appended/prepended to the
platform-specific default-specs?
* If appended/prepended: How do you want the CPP-macro for the concatenated,
final spec string to be named?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45508
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2010-09-04 19:31 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-09-02 19:48 [Bug middle-end/45508] New: Does adding configure-options for specs-hardcoding make sense? nicolai dot stange at zmaw dot de
2010-09-02 19:49 ` [Bug middle-end/45508] " nicolai dot stange at zmaw dot de
2010-09-02 19:55 ` pinskia at gmail dot com
2010-09-02 19:55 ` [Bug middle-end/45508] New: " Andrew Pinski
2010-09-02 20:15 ` [Bug middle-end/45508] " nicolai dot stange at zmaw dot de
2010-09-02 22:29 ` pinskia at gcc dot gnu dot org
2010-09-04 19:31 ` nicolai dot stange at zmaw dot de
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).