Re: -dlopen self and optimizing away symbols

[Albert Chin]

On Thu, Aug 17, 2006 at 08:22:08AM +0200, Ralf Wildenhues wrote:
> * Albert Chin wrote on Thu, Aug 17, 2006 at 07:55:14AM CEST:
> > On Thu, Aug 17, 2006 at 07:42:00AM +0200, Ralf Wildenhues wrote:
> > 
> > > But say, why is -Wl,-E not passed to the link line?  It should be
> > > export_dynamic_flag_spec.  And it should have the desired effect:
> > > |  -E             Mark all symbols defined by a program for export
> > > |                 to shared libraries.  In a +compat mode link, ld
> > > |                 marks only those symbols that are actually
> > > |                 referenced by a shared library seen at link time.
> > > |                 In a +std link, all symbols are exported by
> > > |                 default, so -E is not necessary to make symbols
> > > |                 visible.  However, it has an additional side
> > > |                 effect of identifying all exported symbols as
> > > |                 necessary, so that they will not be removed when
> > > |                 using dead code elimination (+Oprocelim).
> > 
> > Because -export-dynamic is not specified.
> 
> It should not need to be.  IOW, either the Libtool documentation or the
> implementation is broken:
> | `-dlopen FILE'
> |      Same as `-dlpreopen FILE', if native dlopening is not supported on
> |      the host platform (*note Dlopened modules::) or if the program is
> |      linked with `-static', `-static-libtool-libs', or `-all-static'.
> |      Otherwise, no effect.  If FILE is `self' Libtool will make sure
> |      that the program can `dlopen' itself, either by enabling
> |      `-export-dynamic' or by falling back to `-dlpreopen self'.
> 
> But anyway, if you have other modules, you should specify
> -export-dynamic, I think.  At least I can't infer from the above snippet
> that `-dlopen self' would be sufficient.  What do you think?

I agree. I think the program in question should be linked with
`-export-dynamic'. I'll ping the developers and try to find out why
they're using `-dlopen self'. In any case, we need to find a fix as
`-dlopen self' works on AIX but `-export-dynamic' does not.

> > > Otherwise, -Wl,+Onoprocelim should be the hammer we're looking for, I
> > > guess; but that should not even be necessary, given above documentation
> > > (from ld(1)).
> > 
> > Well, export_dynamic_flag_spec isn't even looked at when -dlopen self
> > is being handled. Maybe it should and only use the -dlopen self code
> > when export_dynamic_flag_spec is empty?
> 
> I still need to look at that code.

Ok, I should have looked closer. The documentation is correct:

        case $prev in
        dlfiles|dlprefiles)
          ...
          case $arg in
          *.la | *.lo) ;;  # We handle these cases below.
          force)
          ...
          self)
            if test "$prev" = dlprefiles; then
              dlself=yes
            elif test "$prev" = dlfiles && test "$dlopen_self" != yes; then
              dlself=yes
            else
              dlself=needless
              export_dynamic=yes
            fi
            prev=
            continue
            ;;

On HP-UX 11.23/IA, dlopen_self=unknown. Hence, we never set
export_dynamic=yes. Why isn't export_dynamic=yes on this platform?
Because lt_cv_dlopen!=dlopen as we prefer shl_load rather than dlopen
(this change was made a long time ago because on HP-UX 11.00, dlopen()
required a patch while shl_load() is always available):
  http://lists.gnu.org/archive/html/libtool/2001-04/msg00221.html

Because of this, the following code never gets executed:
  case $lt_cv_dlopen in
  dlopen)
    save_CPPFLAGS="$CPPFLAGS"
    test "x$ac_cv_header_dlfcn_h" = xyes && CPPFLAGS="$CPPFLAGS -DHAVE_DLFCN_H"

    save_LDFLAGS="$LDFLAGS"
    wl=$lt_prog_compiler_wl eval LDFLAGS=\"\$LDFLAGS $export_dynamic_flag_spec\"

    save_LIBS="$LIBS"
    LIBS="$lt_cv_dlopen_libs $LIBS"

    AC_CACHE_CHECK([whether a program can dlopen itself],
          lt_cv_dlopen_self, [dnl
          _LT_AC_TRY_DLOPEN_SELF(
            lt_cv_dlopen_self=yes, lt_cv_dlopen_self=yes,
            lt_cv_dlopen_self=no, lt_cv_dlopen_self=cross)
    ])

So, what do we do? Revert the dlopen() change and agree that enough
time has passed and all HP-UX 11.x users should have the dlopen()
patch? It's been 5 years so I say we can now prefer dlopen!

Or do we do the above _and_ try to fix this somehow? It doesn't seem
to be a problem on HP-UX 10.20 which uses shl_load().

-- 
albert chin (address@hidden)