[MacPorts] #66385: SoapyRTLSDR fails to build with GCC: ld: unknown option: --no-undefined

MacPorts noreply at macports.org
Sat Dec 3 04:40:51 UTC 2022

#66385: SoapyRTLSDR fails to build with GCC: ld: unknown option: --no-undefined
  Reporter:  barracuda156  |      Owner:  ra1nb0w
      Type:  defect        |     Status:  assigned
  Priority:  Normal        |  Milestone:
 Component:  ports         |    Version:  2.8.0
Resolution:                |   Keywords:
      Port:  SoapyRTLSDR   |
Changes (by ryandesign):

 * cc: michaelld, gedgy63@… (added)


 Even though you're building with g++ I think you're still linking with
 Apple's ld. I think `--no-undefined` is an option that would be understood
 by the GNU linker but not by Apple's linker.
 to-no-undefined-gcc-flag According to a quick search], Apple's ld would
 need `-Wl,-undefined,error` instead.

 I see from the log that you're on Snow Leopard but building for ppc. I
 assume this is why it's building with g++. I don't see anything gcc-
 related in the port so I assume on standard configurations it would build
 with clang++ and not encounter this problem.

 I'm not sure what's causing `--no-undefined` to be used in the build. I
 don't see any occurrences of that string in the SoapyRTLSDR source code.
 Perhaps it comes from SoapyRTLSDR's dependency SoapySDR whose
 SoapySDRUtil.cmake file does contain these lines (or from some other file
 in the build chain that contains similar lines):

         #force a compile-time error when symbols are missing
         #otherwise modules will cause a runtime error on load
         target_link_libraries(${MODULE_TARGET} PRIVATE "-Wl,--no-

 These lines appear to assume that, if the compiler is GNU, then the linker
 must also be GNU, which is evidently not the case on your system at least
 and perhaps on all Mac systems.

Ticket URL: <https://trac.macports.org/ticket/66385#comment:1>
MacPorts <https://www.macports.org/>
Ports system for macOS

More information about the macports-tickets mailing list