X-Spam-Check-By: sourceware.org To: cygwin@cygwin.com From: Coatimundi Subject: Re: Does 'ar' work with native MS Windows libs? Date: Tue, 03 Oct 2006 11:35:27 -0700 Lines: 38 Message-ID: References: <20061003110319.GA27817@trixie.casa.cgf.cx> <20061003142402.GA31259@trixie.casa.cgf.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) In-Reply-To: X-IsSubscribed: yes Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Delivered-To: mailing list cygwin@cygwin.com Following up my own post... Coatimundi wrote: > > The thing I noticed first was that 'ar vt libfoo.a' did not always list > all of the member names. Some were present, some were missing. (Linking > with the lib unambiguously confirms that they're all there. The total > number of routines is about 20 in this small lib.) So far I have seen > this effect only with libs compiled with debugging information. I have > not noticed this problem with libs compiled without debugging info. > This observation is anecdotal but enough to make me wonder. > > So I decided to extract a single object from the (non-debug-info) > libfoo.a with both Cygwin's ar and Microsoft's LIB.EXE. The resulting > objects differed in byte-count, which I took (perhaps wrongly) as a > strong clue that I was headed in the wrong direction. I found a workaround. The 'ar' which ships with Cygwin works great on Microsoft libs, as long as the members of the archive are simple filenames without paths. So my workaround is to compile objects into the Visual Studio project directory (not .\Debug or .\Release) before LIB.EXE runs. After LIB, I delete *.obj from the project directory. This forces LIB to write simple names into the archive. If paths are included in the archive (which is typical for libs created by Visual Studio), then ar may in some cases claim that members (displayed with 'ar t') do not exist when doing "ar x lib.a {object}" either by path/name.obj or just name.obj. A quick review of the source (binutils-20060817) shows that 'ar' is clearly intended to handle this peculiarity of the Microsoft libs (See the normalize() function.) I'm not going to try any quick mods. But if more people experience this problem, perhaps one of them will find this post and be more motivated than me! Cheers! -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/