From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 503 invoked by alias); 14 Apr 2003 05:14:01 -0000 Mailing-List: contact binutils-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sources.redhat.com Received: (qmail 494 invoked from network); 14 Apr 2003 05:14:00 -0000 Received: from unknown (HELO mail.hal.cx) (68.32.53.147) by sources.redhat.com with SMTP; 14 Apr 2003 05:14:00 -0000 Received: from ieee.org (unknown [192.168.0.108]) by mail.hal.cx (Postfix) with ESMTP id 5D8B32EC95 for ; Mon, 14 Apr 2003 01:14:00 -0400 (EDT) Message-ID: <3E9A4397.5010309@ieee.org> Date: Mon, 14 Apr 2003 05:14:00 -0000 From: Hal Black User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030328 X-Accept-Language: en,pdf,ja MIME-Version: 1.0 To: binutils Subject: Re: [BUG] ld behavior varies for C++ static initializer depending on .a or .o input References: <3E9639F9.9050503@vt.edu> <3E978F84.4050603@vt.edu> <3E98219D.7010506@ieee.org> <3E98546A.9060507@ieee.org> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-04/txt/msg00301.txt.bz2 Ian Lance Taylor wrote: > Hal Black writes: > > >>>It means that including any class with a static initializer in a .a >>>file would mean that that class would be included in all programs >>>linked with that .a file. >> >>Yes. That's the desired behavior. If a developer were to develop a >>library with a static initializer with side-effects, it would be >>something that should be called whenever that library was used. > > > No Unix linker has ever worked that way. Well, for most of the lifetime of Unix, there were no static initializers, since there was no C++, so this is not surprising. > Also, while this is not the reason for not making the change, it turns > out that it is not an efficient change to make. It would require the > linker to examine every object in every archive, which obviates the > entire point of having archives in the first place. Again, this > inefficiency, while severe, is not the reason for not making the > change; the reason for not making the change is that ld and ar > implement behaviour which has not changed for decades, and should not > be changed now. For the C code that ld has been linking for decades, I agree with you 100%. But, C++ has additional requirements. Either the tool needs to change to meet these requirements, or a different tool needs to be used to meet them. If .a is meant only for what it has been used for decades without changing to accomodate the full C++ specification, you're right, I misunderstood the usage for it. That is definately not what I want. Based on the other replies, I guess that .so can be used to acheive the desired behavior even though it includes too much. Anyway, thank you for responding and for your time, Ian.