Opened 3 years ago

Closed 5 months ago

#66385 closed defect (fixed)

SoapyRTLSDR fails to build with GCC: ld: unknown option: --no-undefined

Reported by: barracuda156 Owned by: ra1nb0w
Priority: Normal Milestone:
Component: ports Version: 2.8.0
Keywords: Cc: michaelld (Michael Dickens), gedgy63@…, ryandesign (Ryan Carsten Schmidt)
Port: SoapyRTLSDR

Description

[100%] Linking CXX shared module librtlsdrSupport.so
/opt/local/bin/cmake -E cmake_link_script CMakeFiles/rtlsdrSupport.dir/link.txt --verbose=ON
/opt/local/bin/g++-mp-12 -pipe -Os -DNDEBUG -I/opt/local/include -D_GLIBCXX_USE_CXX11_ABI=0 -std=c++11 -std=c++11 -Wc++11-extensions -O3 -DNDEBUG -arch ppc -mmacosx-version-min=10.6 -bundle -Wl,-headerpad_max_install_names -L/opt/local/lib -Wl,-headerpad_max_install_names -o librtlsdrSupport.so CMakeFiles/rtlsdrSupport.dir/Registation.cpp.o CMakeFiles/rtlsdrSupport.dir/Settings.cpp.o CMakeFiles/rtlsdrSupport.dir/Streaming.cpp.o CMakeFiles/rtlsdrSupport.dir/Version.cpp.o  -Wl,-rpath,/opt/local/lib /opt/local/lib/librtlsdr.dylib -pthread /opt/local/lib/libSoapySDR.0.8.1.dylib -Wl,--no-undefined -pthread -flat_namespace 
ld: unknown option: --no-undefined
collect2: error: ld returned 1 exit status
make[2]: *** [librtlsdrSupport.so] Error 1
make[2]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_science_SoapyRTLSDR/SoapyRTLSDR/work/build'
make[1]: *** [CMakeFiles/rtlsdrSupport.dir/all] Error 2
make[1]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_science_SoapyRTLSDR/SoapyRTLSDR/work/build'
make: *** [all] Error 2
make: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_science_SoapyRTLSDR/SoapyRTLSDR/work/build'
Command failed:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_science_SoapyRTLSDR/SoapyRTLSDR/work/build" && /usr/bin/make -j6 -w all VERBOSE=ON 
Exit code: 2

Attachments (1)

main.log (21.5 KB) - added by barracuda156 3 years ago.

Download all attachments as: .zip

Change History (7)

Changed 3 years ago by barracuda156

Attachment: main.log added

comment:1 Changed 3 years ago by ryandesign (Ryan Carsten Schmidt)

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. 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):

    if(CMAKE_COMPILER_IS_GNUCXX)
        #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-undefined")
    endif()

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.

comment:2 in reply to:  1 Changed 3 years ago by barracuda156

Replying to ryandesign:

Thank you for responding and helping to find the cause! I have checked the source code prior to opening the ticket and did not find anything there.

I guess this should be fixed with SoapySDR then, since this is not a Rosetta issue and apparently not even a PPC issue (but of course on PPC we only have GCC for now).

comment:3 Changed 3 years ago by ra1nb0w

Probably you should contact the upstream developer of SoapySDR at https://github.com/pothosware/SoapySDR

comment:4 in reply to:  3 Changed 5 months ago by barracuda156

Replying to ra1nb0w:

Probably you should contact the upstream developer of SoapySDR at https://github.com/pothosware/SoapySDR

Looks like was fixed in upstream in https://github.com/pothosware/SoapySDR/commit/f8d57652d12f9d212f373a81e493eba1a0b058c5#diff-874a31c4c14da2ec6917bbc06ff02575b75330f5db86bea535fc95bbca2355dd but still broken in MacPorts.

comment:5 Changed 5 months ago by ryandesign (Ryan Carsten Schmidt)

Cc: ryandesign added

comment:6 Changed 5 months ago by ryandesign (Ryan Carsten Schmidt)

Resolution: fixed
Status: assignedclosed

In f403859a69a14aa2a86197b2c59868b3f7be0d10/macports-ports (master):

SoapySDR: Fix build of dependents using gcc on macOS

Closes: #66385

And fix configuration with cmake 4.

Note: See TracTickets for help on using tickets.