From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15089 invoked by alias); 31 May 2011 05:43:37 -0000 Received: (qmail 15077 invoked by uid 22791); 31 May 2011 05:43:35 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST X-Spam-Check-By: sourceware.org Received: from mail-pw0-f41.google.com (HELO mail-pw0-f41.google.com) (209.85.160.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 31 May 2011 05:43:21 +0000 Received: by pwi12 with SMTP id 12so2324234pwi.0 for ; Mon, 30 May 2011 22:43:21 -0700 (PDT) Received: by 10.68.60.9 with SMTP id d9mr2435049pbr.488.1306820601010; Mon, 30 May 2011 22:43:21 -0700 (PDT) Received: from bubble.grove.modra.org ([115.187.252.19]) by mx.google.com with ESMTPS id n4sm3443762pbj.40.2011.05.30.22.43.18 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 30 May 2011 22:43:19 -0700 (PDT) Received: by bubble.grove.modra.org (Postfix, from userid 1000) id 0274416DE443; Tue, 31 May 2011 15:13:14 +0930 (CST) Date: Tue, 31 May 2011 10:18:00 -0000 From: Alan Modra To: J Cc: binutils@sourceware.org Subject: Re: dlclose() doesn't unload any .so that uses Boost Message-ID: <20110531054313.GA12792@bubble.grove.modra.org> Mail-Followup-To: J , binutils@sourceware.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-IsSubscribed: yes Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2011-05/txt/msg00385.txt.bz2 On Mon, May 30, 2011 at 03:18:52PM +0200, J wrote: > As you can see, dlclose() doesn't properly unload the .so, even though > it claims that it has done so. If you'll remove this line: > > boost :: signal< void () > signal; > > it works properly: On x86 with gcc-4.4.3, ld 2.21.51.20110509, glibc 2.11.1, libboost 1.40.0 I get host: Loading libchild.so... child: Constructor host: so = 0x8240020 host: Unloading libchild.so... child: Destructor host: Unloaded. host: (nil) ie. the same result as your "works properly". My guess would be that your version of glibc handles dlclose differently to mine. Note that there are quite legitimate reasons that dlclose might not behave as you expect, eg. if libchild.so was built with DF_1_NODELETE set. That probably isn't the case here, but worth checking with readelf whether that flag is set for libchild.so and any of its dependencies. "LD_DEBUG=files ./host" for me shows (in part) 26306: calling init: ./libchild.so 26306: child: Constructor 26306: opening file=./libchild.so [0]; direct_opencount=1 26306: host: so = 0x9a86020 host: Unloading libchild.so... 26306: 26306: calling fini: ./libchild.so [0] 26306: child: Destructor 26306: 26306: calling fini: /usr/lib/libboost_signals.so.1.40.0 [0] 26306: 26306: 26306: file=./libchild.so [0]; destroying link map 26306: 26306: file=/usr/lib/libboost_signals.so.1.40.0 [0]; destroying link map host: Unloaded. host: (nil) 26306: 26306: calling fini: ./host [0] -- Alan Modra Australia Development Lab, IBM