On Thu, 13 Mar 2014, Rainer Orth wrote: > Richard Biener <rguent...@suse.de> writes: > > >> > So then if it succeeds to link to a shared libgcc_s then why > >> > is it not able to find that later? Maybe you miss setting > >> > of a suitable LD_LIBRARY_PATH to pick up the runtime for > >> > your host compiler? > >> > >> For the same reason that we use -static-libstdc++ to avoid this issue > >> for libstdc++.so. I've always considered gcc's tendency to build > >> binaries that don't run by default a major annoyance, all the weasel > >> wording in the FAQ nonwithstanding. I hope to finally do something > > > > True, but if your host compiler builds sth then it's the host > > compiler installs business to make sure it can run ... (and thus > > make the libgcc_s it links to available or only provide a static > > libgcc_s). > > Exactly my words. But gcc provides zero help for that. All proposed > workarounds (having every user of gcc set LD_LIBRARY_PATH, messing > around with ldconfig or equivalent, having every single compiler user > provide -rpath/-R on his own) are usability or functionality nightmares > one way or another: the first and second don't scale (imagine a large > site with hundreds of machines and users), and the third imposes work on > the user that the compiler can do best on its own. This may be somewhat > acceptable for single-user/single-system installations of knowledgable > users, but otherwise it's just a bad joke. The compiler has all the > information when/how to pass -rpath/-R and should provide an option to > do so. And if a target has different multilibs, the user suddenly needs > to no not only about $libdir, but about the various multilib (sub)dirs. > Not what I consider user-friendly, and I've seen a large enough share of > somewhat experienced users fail with that.
Ah, we've done that in the past for compilers with libs in non-standard install locations ... cat > $RPM_BUILD_ROOT%{libsubdir}/defaults.spec << EOF *link: + %%{!m32:%%{!m64:-rpath=%{libsubdir}}} %%{m32:-rpath=%{libsubdir}/32} %%{m64:-rpath=%{libsubdir}/64} EOF together with the following (ISTR it was posted but never approved / applied): Index: gcc/gcc.c =================================================================== --- gcc/gcc.c.orig 2012-11-28 10:36:38.000000000 +0100 +++ gcc/gcc.c 2012-12-11 12:30:30.053124280 +0100 @@ -260,6 +260,7 @@ static const char *replace_outfile_spec_ static const char *remove_outfile_spec_function (int, const char **); static const char *version_compare_spec_function (int, const char **); static const char *include_spec_function (int, const char **); +static const char *include_noerr_spec_function (int, const char **); static const char *find_file_spec_function (int, const char **); static const char *find_plugindir_spec_function (int, const char **); static const char *print_asm_header_spec_function (int, const char **); @@ -1293,6 +1294,7 @@ static const struct spec_function static { "remove-outfile", remove_outfile_spec_function }, { "version-compare", version_compare_spec_function }, { "include", include_spec_function }, + { "include_noerr", include_noerr_spec_function }, { "find-file", find_file_spec_function }, { "find-plugindir", find_plugindir_spec_function }, { "print-asm-header", print_asm_header_spec_function }, @@ -6382,6 +6384,8 @@ main (int argc, char **argv) if (access (specs_file, R_OK) == 0) read_specs (specs_file, true, false); + do_self_spec ("%:include_noerr(defaults.spec)%(default_spec)"); + /* Process any configure-time defaults specified for the command line options, via OPTION_DEFAULT_SPECS. */ for (i = 0; i < ARRAY_SIZE (option_default_specs); i++) @@ -8271,6 +8275,21 @@ get_random_number (void) return ret ^ getpid(); } +static const char * +include_noerr_spec_function (int argc, const char **argv) +{ + char *file; + + if (argc != 1) + abort (); + + file = find_a_file (&startfile_prefixes, argv[0], R_OK, 0); + if (file) + read_specs (file, FALSE, TRUE); + + return NULL; +} + /* %:compare-debug-dump-opt spec function. Save the last argument, expected to be the last -fdump-final-insns option, or generate a temporary. */ > > For this particular case at least. > > > > Note that I'm not against linking against static libgcc_s for > > lto-plugin. The -static-libstdc++ we use is just because during > > bootstrap picking up the correct libstdc++ was deemed too hard > > to implement and thus the easy way out was -static-libstdc++. > > So how should we go forward with this issue? This bootstrap failure is > a regression from all previous releases. As I said, I'd rather not > duplicate the -static-libgcc test from the toplevel, but would do so if > all else fails. Perhaps Paolo could weigh in as the build maintainer? Yeah, I'd like a build maintainer to look over your first proposed patch (workaround libtools nicyness). Richard.