On Tue, Oct 29, 2002 at 07:22:08PM +1100, matthew green wrote:
>
> Okay. So it's a matter of historical FUBARism - which means I should, at
> the very least, have a FIXME to find some way to fix it, and not turn
> off the warnings.
>
> NetBSD arguments aside, this information *should* be used on Debian, simply
> because it becomes very important when trying to maintain the metadata
> about what packages depend on what libraries, properly...
>
> in netbsd, all these libs are installed on every system so it isn't
> much of an issue....
Unfortunately, we don't have that excuse. :)
> 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)
> here's what i can tell you:
>
> - everything depends on libc.
Good to know, unsuprising.
> - libcdk probably depends on libcurses
Not relevant, we don't build it right now (what *is* it? Should we be?)
> - libcurses depends on libtermcap _I THINK_
This is not a problem for libc12, but rather, for the ncurses package.
> - all the kerkeros libraries probably depend on -lroken, and maybe
> more other krb support libraries.
> - libcom_err
> - libgssapi
> - libhdb
> - libkadm
> - libkadm5clnt
> - libkadm5srv
> - libkafs
> - libkdb
> - libkrb
> - libkrb5
> - libkstream
> - libsl
> - libss
These all belong to the various Kerberos packages; we don't build them.
> [ i THINK all these are the krb libraries ]
See above for any you missed. :0
> - libmenu and libform depend on libcurses
They come, in fact, from curses, and as such, are part of ncurses.
> - libposix probably does NOT depend on libc
Hmmm. I'll have to dig into that.
> 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...
--
***************************************************************************
Joel Baker System Administrator - lightbearer.com
lucifer@lightbearer.com http://users.lightbearer.com/lucifer/
Attachment:
pgpW7gX2rqn0_.pgp
Description: PGP signature