Subject: Re: libtool and a.out
To: Todd Vierling <>
From: Nick Hudson <>
List: tech-toolchain
Date: 06/22/2000 17:06:49
Todd Vierling wrote:
> On Wed, 21 Jun 2000, Nick Hudson wrote:
> : # 'none' -- dependencies not supported.
> : # `unknown' -- same as none, but documents that we really don't know.
> : # 'pass_all' -- all dependencies passed with no checks.
> : # 'test_compile' -- check by making test program.
> : # 'file_magic [regex]' -- check by looking for files in library path
> : # which responds to the $file_magic_cmd with a given egrep regex.
> : # If you have `file' or equivalent on your system and you're not sure
> : # whether `pass_all' will *always* work, you probably want this one.
> a.out shared objects on NetBSD *do* support interlibrary dependencies, and
> path--this was "rediscovered" some time ago (see tech-pkg archives in early
> 1999), and I verified it just now by randomly linking one a.out shared
> object against another on i386, and then running "ldd" on a binary linked
> only with the shared object with the dependency.

The last message I saw from you on the subject just said the toolchain
needs auditting, but if you say it work then great.

> To my knowledge, this can be set safely to "pass_all" on all current NetBSD
> platforms for which shared libraries exist (and that goes for O*BSD
> platforms, which branched from the NetBSD codebase after the necessary
> support for a.out went in).
> Better, though, this could probably be "test_compile" so systems that may,
> for whatever reason, still be running a system somewhere before 1.1something
> when the support went in, will work.

I'll have a quick look at the test_compile option, but if its too much
work I'll go for pass_all.

> Again, file(1) is NOT part of the ABI and should _never_ be used to check
> for ABI features.  That's why the toolchain can compile test programs.  8^)

This is a libtool guys decision not mine.

> --
> -- Todd Vierling (