From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19745 invoked by alias); 21 Jan 2005 17:40:06 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 18410 invoked by uid 48); 21 Jan 2005 17:38:27 -0000 Date: Fri, 21 Jan 2005 17:40:00 -0000 Message-ID: <20050121173827.18409.qmail@sourceware.org> From: "hp at gcc dot gnu dot org" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20050115184713.19461.hp@gcc.gnu.org> References: <20050115184713.19461.hp@gcc.gnu.org> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug bootstrap/19461] hidden __eprintf referenced by DSO, gas+gld X-Bugzilla-Reason: CC X-SW-Source: 2005-01/txt/msg03082.txt.bz2 List-Id: ------- Additional Comments From hp at gcc dot gnu dot org 2005-01-21 17:38 ------- Digging further, there *is* a __eprintf reference in /tmp/hptmp/obj/sparc-sun-solaris2.8/libstdc++-v3/src/.libs/libstdc++.so, the one supposedly complained about when building the test-application. Now, how did it get there? Ah, it's in debug.o, from libstdc++-v3/src/debug.cc. Apparently from the asserts there, likely from the gcc-2.95.2 installation? Perhaps we need to fixinclude away all __eprintf usage? Strange that libstdc++.so could be created but not used (linked to). Supposedly because there's another, non-hidden __eprintf somewhere? I seem to recall a related problem discussed some time the last few months. I don't remember the resolution. Maybe it was seen on darwin? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19461