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. _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev