libtool
[Top][All Lists]
Advanced

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

libtool-1.4 -- libltdl_cv_sys_dlopen_deplibs=yes on Uw7


From: Matthew Schalit
Subject: libtool-1.4 -- libltdl_cv_sys_dlopen_deplibs=yes on Uw7
Date: Fri, 04 May 2001 12:44:50 -0700

Hi folks,

I had this discussion with Gary on this list a week or
so ago.  Does UnixWare 7.x.x load deplibs, or does libltdl
have to do so...

Trying to build libtool-1.4.

I got an answer back from comp.unix.sco.programmer.

In summary, I think Dave Prosser, from SCO, trys to
explain that the anwer is yes, even though what he said
was a bit convoluted.



Here's the ng thread, where:


> >  == Matt Schalit
>    == Gary Vaughn
     == Dave Prosser

-----------------------------------------------------------------
> On Saturday 21 April 2001 10:02 pm, Matthew Schalit wrote:
> > The only other thing I noticed was this section in libltdl/configure:
> >
> >         # PORTME does your system automatically load deplibs for dlopen()?
> >         libltdl_cv_sys_dlopen_deplibs=unknown
> >         case "$host_os" in
> >         linux*)
> >           libltdl_cv_sys_dlopen_deplibs=yes
> >           ;;
> >         netbsd*)
> >           libltdl_cv_sys_dlopen_deplibs=yes
> >           ;;
> >         solaris*)
> >           libltdl_cv_sys_dlopen_deplibs=yes
> >           ;;
> >         esac


As a general rule, UnixWare and Solaris have common roots here
and thus should act the same.


> > I noticed that I got an unknown from this.  I don't understand what it's
> > checking for, so I don't know how to ask about it or fix it.

Presumably the owner of the configure script should be told to
include UnixWare in the list of "yes"s.


> Setting this variable to yes tells libltdl that if a dlopened library
> depends an another unloaded library that the OS takes care
> of loading the deplib too.
> 
> For instance, if I use libltdl to load libgtk.so into my app, will the
> OS also load libgdk, libglib, libX11 etc for me?
> 
> If the variable is not set to yes, libltdl will dlopen() those
> libraries for me (and recursively any of their deplibs) before
> trying to perform the dlopen actually asked for.  Needless to
> say this slows down dlopening a lot, especially when it is
> not needed.

If a dynamic library has DT_NEEDED entries for other dynamic
libraries (see dump -Lv output), then they are *required* to
be present before the original dynamic library can be completely
loaded.  That's what the dependency means.  If the depended-on
libraries have initialization routine(s) -- also listed in the
dump -Lv output -- they need to be run before any initialization
of the original library.

If the dependent libraries have already been included in the
process, the dynamic linker just points to these, so there isn't
any real overhead after the system calls necessary to verify
that we've got a duplicate.

If this is too much overhead, don't list other dynamic libraries
when building (cc/CC -G) dynamic libraries.  However, I don't
recall anyone ever complaining about the speed of dlopen() -- not
that that means there isn't a problem for some applications.


> So I'm wondering how UnixWare 7.x.x deals with this aspect?
> I guess it'd be helpful to know how it relates it OSR 5.0.x, too.
> 
> This will help SCO's OS's get well supported by libtool and hopefully,
> some better software for us all.

OpenServer and UnixWare share the same behavior here.  The
basics of dynamic library dependencies and the like are common
across many UNIX systems and are found in the Generic Application
Binary Interface specification.  There is an up-to-date version
of the key portions of this available on SCO's web site:

        http://www.sco.com/developer/gabi

-- 
Dave Prosser    dfp at sco dot com      SCO, Murray Hill, NJ
------------------------------------------------------------------------


That's all.
Matthew



reply via email to

[Prev in Thread] Current Thread [Next in Thread]