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
Created attachment 21678 [details] Adds --with-link-libgcc-specs to gcc-4.5.1/gcc/configure Made against release 4.5.1
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 >
> 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.
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" .
(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?
Created attachment 21960 [details] Adds --with-link-{libgcc,ssp}-specs to gcc-4.5.1/gcc/configure
libgomp, libgcc and libssp are the shared libs of gcc. (actually the correct libstdc++ and libgfortran are also found if the correct libgcc is found as they never are linked in without it). libgomp comes with an spec file that is installed into the lib dir. I've added switches to gcc's configure to specify the link specs of these two libs. I've tested it and it works perfectly for me.
I think handling this via specs is the wrong (read: far too complicated) approach. I agree that gcc/g++/... not adding needed RPATHs to its runtime libraries is a major nuissance for every site with more than a single system and a central installation of gcc and it has bothered me for a long time. I'm (slowly) working towards a generic approach to solve this problem, maybe I'll have something ready for gcc 4.7.0.
Hi there, it's always a pleasure to comment on an old thread. :-) > I think handling this via specs is the wrong (read: far too complicated) > approach. well, maybe, but at least it's better to have something that works than having nothing. > I agree that gcc/g++/... not adding needed RPATHs to its runtime libraries is > a major nuissance for every site with more than a single system and a central > installation of gcc and it has bothered me for a long time. > > I'm (slowly) working towards a generic approach to solve this problem, maybe > I'll have something ready for gcc 4.7.0. well, anything done already? If not, what kind of solution do you have in mind? Cheers, Olaf
> --- Comment #9 from gellert at dkrz dot de 2012-09-25 17:00:22 UTC --- [...] >> I agree that gcc/g++/... not adding needed RPATHs to its runtime libraries is >> a major nuissance for every site with more than a single system and a central >> installation of gcc and it has bothered me for a long time. >> >> I'm (slowly) working towards a generic approach to solve this problem, maybe >> I'll have something ready for gcc 4.7.0. > > well, anything done already? If not, what kind of solution do you have in mind? Unfortunately not since I had to massively cut down my gcc work in recent months. The work consists of 3 parts, I think: * A configure option to selectively enable/disable this since unconditional enabling has found massive opposition in the past. * Changing the build procedure so shared runtime libraries are optionally build with RPATHs pointing at the installed locations of their dependencies. * Changing the drivers to add RPATHs for the shared runtime libraries linked. No idea when I'll get around to this, unfortunately. Rainer
*** Bug 7957 has been marked as a duplicate of this bug. ***