From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 307 invoked by alias); 24 Feb 2005 22:51:44 -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 32621 invoked by uid 48); 24 Feb 2005 22:51:37 -0000 Date: Fri, 25 Feb 2005 06:40:00 -0000 Message-ID: <20050224225137.32620.qmail@sourceware.org> From: "aoliva at gcc dot gnu dot org" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20050223105204.20160.rearnsha@gcc.gnu.org> References: <20050223105204.20160.rearnsha@gcc.gnu.org> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug libgcj/20160] [4.0 Regression] link errors building libgcj tests X-Bugzilla-Reason: CC X-SW-Source: 2005-02/txt/msg03071.txt.bz2 List-Id: ------- Additional Comments From aoliva at gcc dot gnu dot org 2005-02-24 22:51 ------- Technically, it's not a libtool bug. When you create an archive out of object files that have overlapping basenames, ar will generally only retain the last one. Dropping the dirname portion is mandated by POSIX. The right solution would be to avoid duplicate basenames entirely. This is probably tricky and painful to do in libjava. Libtool has some trickery to at least force object files with the same basename into an archive, passing special options to ar. I suppose the best course of action would be to rename the input files internally, transparently to the caller, such that, when they're extracted, you don't one to overwrite the other. Either way, this is probably not trivial to implement in libtool. Reverting to piecewise linking and modifying the grouping strategy might be easier. I'll think a bit about it. -- What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|rth at gcc dot gnu dot org |aoliva at gcc dot gnu dot | |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20160