Richard Biener <rguent...@suse.de> writes: >> 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. */
Certainly a step in the right direction, though it will add RPATH in more cases than necessary. I've a couple of ideas for that, and would like to use $ORIGIN if available for inter-runtime lib dependencies to retain relocatability. I'll see how far I come during the next release cycle. >> > 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). Just one additional data point: I've checked mainline libtool, and it still doesn't handle (meaning: still drops) -static-libgcc/-static-libstdc++. At least they have some hints in their documentation on what testing etc. it takes to get additional options passed through to the compiler/linker. Rainer -- ----------------------------------------------------------------------------- Rainer Orth, Center for Biotechnology, Bielefeld University