From dev-return-6929-apmail-stdcxx-dev-archive=stdcxx.apache.org@stdcxx.apache.org Mon Feb 11 23:10:02 2008 Return-Path: Delivered-To: apmail-stdcxx-dev-archive@www.apache.org Received: (qmail 73750 invoked from network); 11 Feb 2008 23:10:01 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 11 Feb 2008 23:10:01 -0000 Received: (qmail 95694 invoked by uid 500); 11 Feb 2008 23:09:55 -0000 Delivered-To: apmail-stdcxx-dev-archive@stdcxx.apache.org Received: (qmail 95628 invoked by uid 500); 11 Feb 2008 23:09:55 -0000 Mailing-List: contact dev-help@stdcxx.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@stdcxx.apache.org Delivered-To: mailing list dev@stdcxx.apache.org Received: (qmail 95618 invoked by uid 99); 11 Feb 2008 23:09:55 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 11 Feb 2008 15:09:55 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of msebor@gmail.com designates 209.85.200.174 as permitted sender) Received: from [209.85.200.174] (HELO wf-out-1314.google.com) (209.85.200.174) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 11 Feb 2008 23:09:23 +0000 Received: by wf-out-1314.google.com with SMTP id 27so219319wfd.2 for ; Mon, 11 Feb 2008 15:09:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:sender; bh=rYtPYwJvQsYXaXmkUEjnA0O1b178ULxLr8sBec4IQAk=; b=pJwyHKYcSOEbYusGGK9RPMntySt2QLwsL77iqs67kWau5ZbgNLZMjI3wQU5oEg8Nbcm7wL0LqGU4nYyXqd1oicfaOFCo0IQ5gh99ZgiUUUqfQhhNIRMBDLtCJl5IX61azIqkiQrxa/E9I+JbUuA36MMZQ039HP1rsIggfT7NTj4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:sender; b=W04wSOwNA74UVb7cWaz2QQaLyfxbo3tUYfT248EDMHI5IptxWtUWaqKjWUkBTGlhFrrkfZ+wlS7hytYTR6v7vsSSJwo6KcwJd0y4Rp1QQkvaUvh3r3qTq6wQE23P5ql+S/XqveTtaIyUkNSHWpjkUjyVF9dcPCgrKxVWHOCL6tQ= Received: by 10.142.240.9 with SMTP id n9mr527101wfh.6.1202771371063; Mon, 11 Feb 2008 15:09:31 -0800 (PST) Received: from localhost.localdomain ( [71.229.200.170]) by mx.google.com with ESMTPS id 22sm5464042wfg.15.2008.02.11.15.09.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 11 Feb 2008 15:09:30 -0800 (PST) Message-ID: <47B0D5A8.1080601@roguewave.com> Date: Mon, 11 Feb 2008 16:09:28 -0700 From: Martin Sebor Organization: Rogue Wave Software, Inc. User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Scott Zhong CC: SourcePro Dev , dev@stdcxx.apache.org Subject: Re: HP-UX link warnings when linking in with -lstd References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: Martin Sebor X-Virus-Checked: Checked by ClamAV on apache.org Scott Zhong wrote: > Hi All, > > I had finally found the source of the link warnings: it is occurring > because in the linker we use relative path in the library lookup "-L > " which confuses the linker as to which stdcxx library to > use. This is because the compiler comes with a version of the stdcxx > library: libstd.sl. This might be a compiler bug. I do not know how to > proceed from here, do we do nothing and leave the linker warnings and > submit the bug to HP? do we require absolute pathing to the stdcxx > library? Do we have the user set an environment variable that would > point to the stdcxx library? Any suggestions would help greatly. If you think it's a compiler bug we should definitely let HP know about it. If you put together a small test case that reproduces it I'll be happy to forward it to HP. As to how to deal with it, one approach would be for SourcePro to use the traditional naming convention for the stdcxx library (i.e., libstd.sl, such as libstd12d.sl) instead of just libstd.sl. I don't think using an absolute pathname when linking with libstd is the way to go (it would assume the lib will always be present at that location which is unlikely). Martin