Date: Tue, 5 Jan 1999 19:04:23 -0800 (PST) From: John Polstra <jdp@polstra.com> To: hgoldste@bbs.mpcs.com Cc: current@FreeBSD.ORG Subject: Re: ELF interpreter /usr/lib/libc.so.1 not found (on 3.0-CURRENT 12/20/98) Message-ID: <199901060304.TAA36807@vashon.polstra.com> In-Reply-To: <13962.6777.503181.771874@penny.south.mpcs.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <13962.6777.503181.771874@penny.south.mpcs.com>,
Howard Goldstein <hgoldste@bbs.mpcs.com> wrote:
>
> My own program seems to be calling for a shared library I didn't link
> it against, at runtime. I don't recall having this happen when
> running everything through cc, but alas I don't have that option since
> one of the modules had to be ported from masm to nasm, so here I am....
>
>
> slice:~/src/develop$ ./v2show
> ELF interpreter /usr/lib/libc.so.1 not found
> Abort trap
Add "-dynamic-linker /usr/libexec/ld-elf.so.1" to your "ld"
command. The "ELF interpreter" is the dynamic linker that the
kernel is trying to load. Its pathname defaults (in the linker) to
"/usr/lib/libc.so.1", which is the old SVR4 version. This must be
overridden on the linker command line. "cc" automatically does that.
You really should try to use "cc" for linking, because there's lots
of non-obvious stuff that needs to go onto the command line for
"ld". Take some simple program "hello.c", and do this:
cc -v hello.c
You'll see the generated linker command at the end. It's pretty
complicated.
I don't understand why your masm/nasm problem would affect linking.
The linker only deals with object files, not with assembly language
sources.
John
--
John Polstra jdp@polstra.com
John D. Polstra & Co., Inc. Seattle, Washington USA
"Nobody ever went broke underestimating the taste of the American public."
-- H. L. Mencken
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901060304.TAA36807>