bug-libtool
[Top][All Lists]
Advanced

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

bug#26389: Portable way to enforce error on undefined symbols


From: Peter Rosin
Subject: bug#26389: Portable way to enforce error on undefined symbols
Date: Fri, 7 Apr 2017 08:53:38 +0200
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0

On 2017-04-07 05:19, Simon Richter wrote:
> Version: 2.4.6
> Severity: wishlist
> 
> Hi,
> 
> I'd like to have a way for libtool fail to link a shared library with
> undefined symbols even on platforms that do support them.
> 
> Passing the "-no-undefined" flag only promises that there are no
> undefined symbols, so libtool will actually try to link a Windows DLL,
> however it will not use -Wl,-z,defs on GNU targets.
> 
> Libtool seems to define some internal variables like
> allow_undefined_flag, but these are not used after being defined.

What do you mean, not used? That's totally up to the platform. But agreed,
they do not appear to be used on Linux...

Looking at the docs, I see these variables:

Variable: allow_undefined_flag
The flag that is used by ‘archive_cmds’ to declare that there will be
unresolved symbols in the resulting shared library. Empty, if no such
flag is required. Set to ‘unsupported’ if there is no way to generate
a shared library with references to symbols that aren’t defined in that
library.

Variable: no_undefined_flag
The flag that is used by ‘archive_cmds’ to declare that there will be
no unresolved symbols in the resulting shared library. Empty, if no
such flag is required.

Looking at the code, I see this:

        # Check to see if the archive will have undefined symbols.
        if test yes = "$allow_undefined"; then
          if test unsupported = "$allow_undefined_flag"; then
            if test yes = "$build_old_libs"; then
              func_warning "undefined symbols not allowed in $host shared 
libraries; building static only"
              build_libtool_libs=no
            else
              func_fatal_error "can't build $host shared library unless 
-no-undefined is specified"
            fi
          fi
        else
          # Don't allow undefined symbols.
          allow_undefined_flag=$no_undefined_flag
        fi

      fi


$allow_undefined is default yes, and isn't no even on Windows (while
it perhaps should). Anyway, the way to get $allow_undefined to be no
is to supply -no-undefined. -no-undefined is a promise to libtool
that the library does not contain any unresolved symbols. A number of
platforms appears to enforce this with various content in the
no_undefined_flag. E.g, AIX uses "-bernotok", Solaris uses "-z defs"
and SCO uses "-z,text". I imagine that it is a small matter of the
platform to set no_undefined_flag similarly to how it is set for
Solaris when using GNU tools, and also make sure $allow_undefined_flag
is present in archive_cmds (and archive_expsym_cmds if it is set), and
the above machinery will kick in when the user supplies -no-undefined.

BUT, this is not the first time this has come up, so I suspect that
I'm missing something crucial...

Cheers,
Peter





reply via email to

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