Why portconfigure::configure_get_ld_archflags?

[Ryan Schmidt]

portconfigure.tcl has this function:


# internal function to determine the ld flags to select an arch
# Unfortunately there's no consistent way to do this when the compiler
# doesn't support -arch, because it could be used to link rather than using
# ld directly. So we punt and let portfiles deal with that case.
proc portconfigure::configure_get_ld_archflags {args} {
    global configure.build_arch configure.compiler
    if {${configure.build_arch} != "" && [arch_flag_supported ${configure.compiler}]} {
        return "-arch ${configure.build_arch}"
    } else {
        return ""
    }
}


This was added in https://trac.macports.org/changeset/60680 but the commit message doesn't say why. I don't understand the issue. Why can't ld_archflags fall back to -m32 / -m64 like portconfigure::configure_get_archflags does for the other *_archflags variables? And why are portfile authors better equipped than MacPorts base to handle whatever the issue is?

I am modifying a portfile and want it to use ${configure.cc} as ld to create a dylib. It might be any version of MacPorts gcc, not all of which support -arch flags. Doesn't it need to know what architecture to use? If so, how do I tell it, if I can't use -m32 / -m64 / -arch flags?

I tried using ${configure.cc_archflags} instead of ${configure.ld_archflags}. It added -m64 like I expected, and it compiled without complaint.