On 17/05/2024 05:50, Brian Inglis via Cygwin-apps wrote:
On 2024-05-16 15:45, Ken Brown via Cygwin-apps wrote:
On 5/16/2024 4:24 PM, Brian Inglis via Cygwin-apps wrote:
Hi folks,
Trying to update dateutils, autotools build fails with:
libtool: error: can't build x86_64-pc-cygwin shared library unless
-no-undefined is specified
Suggestions for overrides or fixes?
Tried:
LDFLAGS="$LDFLAGS -Wl,--no-allow-shlib-undefined -Wl,--no-undefined"
CYGCONF_ARGS="
--enable-contrib
--enable-tzmap-fetch
lt_no_undefined_flag=--no-undefined
no_undefined_flag=--no-undefined
You and I discussed this a few years ago in connection with curl. The
solution there, and in most similar cases, is to add -no-undefined to
the appropriate lib*_la_LDFLAGS variable(s) in Makefile.am. See
Yeah, building stuff for Cygwin often requires adding this flag in the
appropriate places, to say "yes, I really do want a shared library".
https://www.gnu.org/software/libtool/manual/html_node/Link-mode.html#Link-mode
-no-undefined
Declare that output-file does not depend on any libraries other than
the ones listed on the command line, i.e., after linking, it will not
have unresolved symbols. Some platforms require all symbols in shared
libraries to be resolved at library creation (see Inter-library
dependencies), and using this parameter allows libtool to assume that
this will not happen.
Note that because this flag doesn't do anything for non-PE targets, it's
(a) always safe to upstream, and (b) doesn't actually prevent
development from unwittingly introducing unresolved symbols.
This should probably be mentioned in the FAQ item on PE linkage
peculiarities.
