`-undefined dynamic_lookup` confuses `configure`

[nbrachet]

Synopsis

Bazel insists on defining -undefined dynamic_lookup on darwin_x86_64 which makes the TRY_LINK rule always succeed.

I'm not sure what the best course of action is. Should this be considered a bug in autoconf? Or a bug in bazel? But it seems pretty specific to using configure_make.

How to reproduce

libcurl 7.73.0 exhibits this problem when building on macosx using GCC (not the native Clang).

        http_archive(
            name = "curl",
            urls = ["https://curl.haxx.se/download/curl-7.73.0.tar.gz",],
            strip_prefix = "curl-7.73.0",
            build_file_content = """
load("@rules_foreign_cc//tools/build_defs:configure.bzl", "configure_make")

filegroup(
    name = "all",
    srcs = glob(["**"]),
)

configure_make(
    name = "curl",
    visibility = ["//visibility:public"],
    configure_env_vars = select({
        "@bazel_tools//src/conditions:darwin": {
            # see https://github.com/bazelbuild/rules_foreign_cc/issues/185
            # for why this magic is required for the OSX build
            "AR": "",
        },
        "//conditions:default": {},
    }),
    configure_options = select({
            "@bazel_tools//src/conditions:darwin": [
                "--without-libpsl",
                "--without-idn2",
                "--without-ssl",
                # "--with-darwinssl",
            ],
            "//conditions:default": [
                "--with-ssl",
            ],
        }) + [
        "--enable-http",
        "--enable-proxy",
        "--disable-ftp",
        "--disable-file",
        "--disable-ldap",
        "--disable-ldaps",
        "--disable-rtsp",
        "--disable-dict",
        "--disable-telnet",
        "--disable-tftp",
        "--disable-pop3",
        "--disable-imap",
        "--disable-smb",
        "--disable-smtp",
        "--disable-gopher",
        "--disable-mqtt",
        "--disable-manual",
        "--disable-doh",
        "--without-zlib",
        "--without-gnutls",
        "--without-mbedtls",
        "--without-wolfssl",
        "--without-mesalink",
        "--without-nss",
        "--without-bearssl",
        "--without-libmetalink",
        "--without-librtmp",
        "--without-ngtcp2",
        "--without-nghttp2",
        "--without-nghttp3",
        "--without-quiche",
        "--disable-shared",
    ],
    lib_source = ":all",
    out_include_dir = "include",
    static_libraries = ["libcurl.a"],
    linkopts = select({
        "@bazel_tools//src/conditions:darwin": [
            "-framework", "Security",
        ],
        "//conditions:default": [
            "-lssl",
            "-lcrypto",
        ],
    }),
)
"""
        )

[jsharpe]

I would suggest that this is a bug in autoconf since it should be aware that for clang on osx that this flag modifies the behaviour of the thing it is trying to test.
I don't think there is anything we can do in rules_foreign_cc to fix this?

[djmarcin]

I just spent most of the day tracking this down. It manifests as the configure script incorrectly detecting the presence of features that the platform does not have, resulting in missing headers or symbols during the build. Considering that the version of autoconf that a lot of software expects is from 2012, the practical solution here is probably to filter this flag out somehow. Do you have a suggestion for how to accomplish that, short of falling all the way back to a genrule?

One thing that confuses me in particular about rules_foreign_cc is that configure scripts often take on the responsibility of setting up valid CFLAGS and LDFLAGS for the build, and while some of the toolchain flags are required (like where to find headers and system libraries) others seem like preferences, or, like -undefined dynamic_lookup, an actively problematic guess. It seems like if a project's build required this flag to be set, its own configure script would probably set it. I'm not sure if there's a way to differentiate between the required and optional classes of flags, but I've had trouble using rules_foreign_cc because of non-essential toolchain flags that conflict with what the project expects in both projects I've tried.

[fandyushin]

@djmarcin is it possible to remove this flag? I found the place in bazel sources where it is set. But I have no idea how to remove it.

[djmarcin]

I didn't find a way to unset it, I fell back to using a set of genrules that allow me to exercise more precise control over these sorts of flags.

[fandyushin]

Workaround for 0.7.1 provided in #859 (comment).