GNU bug report logs - #26389
Portable way to enforce error on undefined symbols

Previous Next

To reply to this bug, email your comments to 26389 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Simon Richter <Simon.Richter <at> hogyros.de>
To: bug-libtool <at> gnu.org
Subject: Portable way to enforce error on undefined symbols
Date: Fri, 7 Apr 2017 05:19:17 +0200

[Message part 1 (text/plain, inline)]

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.

   Simon

[signature.asc (application/pgp-signature, attachment)]

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Peter Rosin <peda <at> lysator.liu.se>
To: bug-libtool <at> gnu.org
Subject: Re: bug#26389: Portable way to enforce error on undefined symbols
Date: Fri, 7 Apr 2017 08:53:38 +0200

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

Message #11 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Bob Friesenhahn <bfriesen <at> simple.dallas.tx.us>
To: Simon Richter <Simon.Richter <at> hogyros.de>
Cc: 26389 <at> debbugs.gnu.org, bug-libtool <at> gnu.org
Subject: Re: bug#26389: Portable way to enforce error on undefined symbols
Date: Sat, 8 Apr 2017 09:06:31 -0500 (CDT)

On Fri, 7 Apr 2017, Simon Richter wrote:
> 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.

Successfully enforcing that there are no unresolved symbols at all is 
difficult to accomplish on GNU/Linux.  In my experience, if the 
compiler/linker is told not to allow any unresolved symbols, then 
additional system libraries in non-portable (architecture specific) 
locations need to be specifically applied before all the symbols are 
successfully resolved.  The problem is that there are unresolved 
symbols by default produced by system libraries which are not related 
to the code being built.

Bob
-- 
Bob Friesenhahn
bfriesen <at> simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.