[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: