From owner-freebsd-hackers Wed Apr 10 19:53: 0 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from swan.prod.itd.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by hub.freebsd.org (Postfix) with ESMTP id 0946837B405 for ; Wed, 10 Apr 2002 19:52:53 -0700 (PDT) Received: from pool0513.cvx40-bradley.dialup.earthlink.net ([216.244.44.3] helo=mindspring.com) by swan.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16vUhf-0003uk-00; Wed, 10 Apr 2002 19:52:51 -0700 Message-ID: <3CB4FA68.3C5540F8@mindspring.com> Date: Wed, 10 Apr 2002 19:52:24 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: bruno@tinkerbox.org Cc: hackers@freebsd.org Subject: Re: problems with shared libraries (fwd) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG bruno@tinkerbox.org wrote: > that worked, I dlopen'ed glib in my program and put a stub for the glib > function that was failing. It was getting bad data. Guess glib needs some > stuff inited first maybe... anyway, it seems it works by spoofing it ! > > thanks Glad it working... but what you did wasn't exactly what I had in mind. The problem comes from the linkage being ld argument order at symbol resolution time, and hierarchically ordered at ld.so load time. It's very hard to draw a 3D diagram in 2D. So I'll ignore the original link time issues, and show you what I meant and what you did. What you did was: prog { f1 -> module.f1 f2 -> module.f2 libc { } module { f1 f2 g1 -> glib.g1 glib { g1 } } } What I suggested was: prog { f1 -> wrapper.f1 f2 -> wrapper.f2 libc { } wrapper { f1 -> module.f1 f2 -> module.f2 glib { g1 } module { f1 f2 g1 } } } The difference is that when the module goes to resolve symbols, it looks for the symbols in its hierarchy. It's linked against glib, but it's seeing the libc symbols, and so it's getting confused. By explicitly putting the glib into the hierarchy before the module is loaded, you ensure that it only gets libc symbols if the glib symbols aren't there. In other words, the glib symbols shadow the libc symbols. The way you have it may work for your application, but it general, can fail. Another alternative is to explicitly link the module.so against the glib.so. I have seen this fail for symbol sets 2 or more deep (which is what I think was biting you) with things like JNI implementations using shared objects for Kaffe. Probably a better approach would be to register by name the share modules, using a signle exported structure that contained the name, and some generic entry points (e.g. "register yourself", "deregister yourself", "user defined entry point", etc., via a programmatic mux. Then you could also, as part of registration, list your dependencies for particular modules, which would cause them to be loaded. You might also have worked around it with LD_PRELOAD; but doing that, you would be likely to get glib components where the main program was in fact expecting libc symbols to resolve. The man page for "rtld" is quite informative, for debugging purposes... -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message