From patchwork Sun Oct 30 19:15:57 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Gerald Pfeifer X-Patchwork-Id: 122661 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id E3BB2B6F7C for ; Mon, 31 Oct 2011 06:16:16 +1100 (EST) Received: (qmail 1617 invoked by alias); 30 Oct 2011 19:16:15 -0000 Received: (qmail 1606 invoked by uid 22791); 30 Oct 2011 19:16:14 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from ainaz.pair.com (HELO ainaz.pair.com) (209.68.2.66) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 30 Oct 2011 19:16:00 +0000 Received: from [192.168.0.130] (vie-188-118-240-137.dsl.sil.at [188.118.240.137]) by ainaz.pair.com (Postfix) with ESMTPSA id 555EE3F40F; Sun, 30 Oct 2011 15:15:59 -0400 (EDT) Date: Sun, 30 Oct 2011 20:15:57 +0100 (CET) From: Gerald Pfeifer To: gcc-patches@gcc.gnu.org cc: Axel Freyn Subject: [wwwdocs] Simplify FAQ around rpath Message-ID: MIME-Version: 1.0 X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org While looking into Axel Freyn's suggestion, I noticed how that answer really is too long winded. This cuts down things quite a bit, making this more digestable hopefully. Applied. Gerald Index: faq.html =================================================================== RCS file: /cvs/gcc/wwwdocs/htdocs/faq.html,v retrieving revision 1.213 diff -u -r1.213 faq.html --- faq.html 30 Oct 2011 19:00:34 -0000 1.213 +++ faq.html 30 Oct 2011 19:12:50 -0000 @@ -176,25 +176,20 @@

Dynamic linker is unable to find GCC libraries

This problem manifests itself by programs not finding shared -libraries they depend on when the programs are started. Note this -problem often manifests itself with failures in the libio/libstdc++ -tests after configuring with --enable-shared and building GCC.

+libraries they depend on when the programs are started. (This +often shows around libstdc++.)

GCC does not specify a runpath so that the dynamic linker can find dynamic libraries at runtime.

The short explanation is that if you always pass a -R option to the -linker, then your programs become dependent on directories which -may be NFS mounted, and programs may hang unnecessarily when an -NFS server goes down.

- -

The problem is not programs that do require the directories; those -programs are going to hang no matter what you do. The problem is -programs that do not require the directories.

- -

SunOS effectively always passed a -R option for every --L option; this was a bad idea, and so it was removed for -Solaris. We should not recreate it.

+linker, your programs become dependent on directories which +may be NFS mounted, and programs — even those which do not +require these directories — may hang unnecessarily when an +NFS server goes down. +(SunOS effectively always passed a -R option for every +-L option; this was a bad idea, and it was removed for +Solaris.)

However, if you feel you really need such an option to be passed automatically to the linker, you may add it to a GCC specs file. @@ -212,12 +207,6 @@ LD_RUN_PATH or equivalent (again, it's platform-dependent).

-

Yet another option, that works on a few platforms, is to hard-code -the full pathname of the library into its soname. This can only be -accomplished by modifying the appropriate .ml file within -libstdc++/config (and also libg++/config, if you are -building libg++), so that $(libdir)/ appears just before -the library name in -soname or -h options.

GCC can not find GNU as/GNU ld