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

Reply via email to