re: Dependancy info for libc12
> Suggestions on how to properly figure out which libraries things must link
> against (especially involving libraries which may or may not be present,
> such as libi386 and libm387 - especially the latter) would be appreciated.
>
> well, libi386 is linked into applications that use "-li386". however,
> libm387 is, i believe, specially selected by ld.elf_so instead of libm
> when the copro is present. this entry is /etc/ld.so.conf does this
>
> libm.so.0 machdep.fpu_present 1:libm387.so.0,libm.so.0
>
> nothing does "-lm387" manually that i'm aware of.
This matches what I've been able to dig out of the archives; things will
try to link against libm387, then fall back to libm, *if* it's relevant to
the arch (machdep.fpu_present being true, which only happens, AFAICT, on
x86 machines with an FPU present)
right; the above line basically says:
for libm.so.0, if `sysctl machdep.fpu_present` returns 1, then use
libm387.so.0, otherwise use libm.so.0.
this is generic for any sysctl / library you put in ld.so.conf.
> - libcdk probably depends on libcurses
Not relevant, we don't build it right now (what *is* it? Should we be?)
'curses development kit'. it's used by a few utilities in the netbsd
source tree.
> - libcurses depends on libtermcap _I THINK_
This is not a problem for libc12, but rather, for the ncurses package.
ah of course, you don't use our curses :-( :-)
> - libposix probably does NOT depend on libc
Hmmm. I'll have to dig into that.
i think GCC specs take care of this one for you, for a real netbsd target anyway
(no i don't just mean the netbsd source tree compiler :). basically if you say
"cc -posix" it will add "-lposix" for you, so that you get posix versions of a
handful of system calls...
splode ~> grep rename /usr/src/lib/libposix/sys/Makefile.inc
PSEUDO= chown.S fchown.S lchown.S rename.S
these system calls have minor semantic differences on netbsd systems compared
to true "posix" systems. from rename(2):
STANDARDS
The rename() function deviates from the semantics defined in IEEE Std
1003.1-1990 (``POSIX''), which specifies that if both from and to link to
the same existing file, rename() shall return successfully and performs
no further action, whereas this implementation will remove the file spec-
ified by from unless both from and to are pathnames of the same file in
the file system's name space.
and from *chown(2):
STANDARDS
The chown() function deviates from the semantics defined in IEEE Std
1003.1-1990 (``POSIX''), which specifies that, unless the caller is the
super-user, both the set-user-id and set-group-id bits on a file shall be
cleared, regardless of the file attribute changed. The lchown() and
fchown() functions, as defined by X/Open Portability Guide Issue 4,
Version 2 (``XPG4.2''), provide the same semantics.
they then go on to say to use "-lposix" etc. (hmm maybe i should update
them to say to use 'cc -posix'...)
> that may be all there is? i dunno...
Really what I'm trying to find is a way to examine a dump of the object, or
maybe trying to build a static version from the .so, and finding out what
symbols are, and are not, declared in the library ('are not' meaning we
need to find where they come from, 'are' giving us that information).
Upon boiling it down that way, it strikes me that a bit of magic with
perl and objdump might well suffice to tell me what I need to make this
determination...
sounds like a good idea to me.
.mrg.
Reply to: