From owner-freebsd-hackers Tue Oct 31 22:13:40 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA24214 for hackers-outgoing; Tue, 31 Oct 1995 22:13:40 -0800 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id WAA24201 for ; Tue, 31 Oct 1995 22:13:38 -0800 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id WAA03720; Tue, 31 Oct 1995 22:13:13 -0800 To: ryan@genius.tisl.soft.net cc: FreeBSD Technical Questions Subject: Re: Shared Libraries In-reply-to: Your message of "Wed, 01 Nov 1995 11:21:30 GMT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3717.815206392.1@time.cdrom.com> Date: Tue, 31 Oct 1995 22:13:13 -0800 Message-ID: <3718.815206393@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.org Precedence: bulk > Our product has many shared libraries and we are required to provide a > cobol front end to it (ie., API). But the cobol compiler(MFCOBOL) which > our clients have does not link with shared libraries (Our platform is > SunOS 4.1.x, running on sparc 20 [sun 4m]). First off, you cannot link shared libraries against a static executable, period. Sorry! If you link your application shared, you'll also inherit the code required to link libraries dynamically at runtime. > function using fn. pointers. But the problem is dlopen,dlcose & dlsym, > which are the required fns. to load, unload and get fn addresses in SunOS > 4.1.x, are themselves present in a shared library!. Therefore I am still > unable to resolve my problem. I don't know about SunOS, but in FreeBSD they're actually the C runtime code (crt0) and a special link loader, ld.so. None of the shared library binding code is actually *in* a shared library, as that would represent something of a chicken and egg scenario! :) > public-domain software to help me out. If nothing else, can you tell me > how I could load a shared library and resolve function addresses? dlopen, dlsym, etc. Unless you're prepared to write your own dynamic loader/resolver, as some systems like KCL have done, you've no other choice. And no, please don't ask me how to write your own loader! :-) It's a big job, and it requires an intimiate knowledge of the object and symbol formats. There's no 500-words-or-less answer to the question. Jordan