Date: Tue, 31 Oct 1995 22:13:13 -0800 From: "Jordan K. Hubbard" <jkh@time.cdrom.com> To: ryan@genius.tisl.soft.net Cc: FreeBSD Technical Questions <hackers@FreeBSD.org> Subject: Re: Shared Libraries Message-ID: <3718.815206393@time.cdrom.com> In-Reply-To: Your message of "Wed, 01 Nov 1995 11:21:30 GMT." <Pine.A32.3.91.951101112003.20712A-100000@genius.tisl.soft.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3718.815206393>