g++ assumes libstdc++ in library path?

[Andreas Jaeger]

geos@epost.de (Georg Schwarz) writes:

> It looks like gcc/g++ assume that the path where libstdc++ is installed,
> i.e. typically PREFIX/lib, is in the runtime library path. If that is
> not the case, launching an executable compiled with gcc/g++ fails with
> rld: Fatal Error: cannot map soname
> 'libstdc++.so.7' using any of the filenames [...]
>
> This is gcc 3.4.0 on IRIX 5.3 using the native SGI ld.
> Can gcc be compiled to link executables with an appropriate -rpath
> option, when necessary, i.e. when libstdc++ is needed? 

This is answered in our FAQ:
http://gcc.gnu.org/faq.html#rpath

Andreas
-- 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBAu13uOJpWPMJyoSYRApbIAJwO7rs20yBDXVAoFG28PPY2q0gxAwCfdnlG
aoWsoNNetU9JwljL9EMIaw0=
=Vlvq
-----END PGP SIGNATURE-----From mark@codesourcery.com Mon May 31 18:17:00 2004
From: Mark Mitchell <mark@codesourcery.com>
To: gcc@gcc.gnu.org, jason@redhat.com, nathan@codesourcery.com
Subject: Warnings in templates
Date: Mon, 31 May 2004 18:17:00 -0000
Message-id: <200405311817.i4VIHqOv027013@sirius.codesourcery.com>
X-SW-Source: 2004-05/msg01444.html
Content-length: 882

Jason --

Do you understand why we seem to be trying so hard to issue warnings
about things like functions that do not return in templates?

There's no reasonable way to avoid false positives here; consider
things like:

  extern "C" exit (int) __attribute((noreturn));
  extern void exit(float);

  template <typename T>
  void f() {
    exit (T);
  }

PR 15742 is one case similar to this.  I'm going to fix that one, but
to fix the case I give above, you'd have to consider any dependent
call to a function with the same name as one that is known not to
return as reason to suppress the warning.

I understand the motivation to warn early and to warn on the template
definitions rather than each of its instantiations, but this seems
like the kind of thing where we should just wait until instantiation
time.

Thoughts?

--
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com