------- Comment #2 from pinskia at gmail dot com  2010-09-02 19:55 -------
Subject: Re:   New: Does adding configure-options for specs-hardcoding make

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 <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



Reply via email to