#62580 closed request (fixed)
hamlib @4.1: please enable python (and python3) bindings.
| Reported by: | RobK88 | Owned by: | ra1nb0w |
|---|---|---|---|
| Priority: | Normal | Milestone: | |
| Component: | ports | Version: | 2.6.4 |
| Keywords: | Cc: | ||
| Port: | hamlib |
Description
I have been trying to compile and install "Hamlib" with python bindings support. Even though Macports has Hamlib in its repo, Macports does not offer Hamlib with python bindings support.
If one want hamlib with python bindings support, one must do it manually. (see https://github.com/Hamlib/Hamlib/blob/master/bindings/README.python )
Unfortunately, when I try to compile hamlib with python bindings support, the compile fails.
./configure --with-python-binding --prefix=/usr/local
(all is good!)
make
...
...
"__Py_NotImplementedStruct", referenced from:
_SwigPyObject_richcompare in hamlibpy_wrap.o
ld: symbol(s) not found for architecture x86_64
collect2: ld returned 1 exit status
make[2]: *** [_Hamlib.la] Error 1
make[1]: *** [all] Error 2
make: *** [all-recursive] Error 1
One of the hamlib developers told me that it was a swig related error. He told me to reinstall swig and try again. I did that. The compile of hamlib failed again with the same error.
So I uninstalled swig and swig-python using Macports. Then I compiled swig manually from source. swig compiled and installed just fine. But when I ran "make check", errors show up when the python related test suite is run.
Given my experiences above, I am pretty confident that the Macports "swig" and "swig-python" packages are also broken on Lion. They compile and install fine but do NOT run as expected.
P.S. I also have the same experience with py39-numpy. The Macports port compiles and installs fine on my old Mac running Lion but py39-numpy does not run properly. (see https://trac.macports.org/ticket/59616 )
So it looks like a number of python related packages are broken on the older Macs even though they compile and install fine.
Attachments (3)
Change History (53)
comment:1 Changed 3 years ago by kencu (Ken)
comment:2 Changed 3 years ago by kencu (Ken)
The other general method of approaching your problem, other than modify the Portfile which I find simplest, is to set up or pass the instructions on where to look for the headers and libraries to your build. You do this either by setting build arguments like this
-I/opt/local/include -L/opt/local/lib
or the environment variables that are needed.
To see exactly how MacPorts sets these, do something like this:
sudo port -d configure hamlib
and you will see a whole mess of options that MacPorts has set for you listed there.
comment:3 Changed 3 years ago by jmroot (Joshua Root)
| Cc: | michaelld@… removed |
|---|---|
| Owner: | set to michaelld |
| Status: | new → assigned |
comment:4 Changed 3 years ago by RobK88
Many many thanks Ken. I learned a lot! Now I know how easily modify existing ports. I wish that info was in the Macports Guide on the web.
P.S. One day I will figure out how to create a local Macports repo holding my own ports.
By the way, I following your instructions and modified the existing Hamlib port by adding "configure.args-append --with-python-binding". But the port still failed to compile.
$ sudo port -v build hamlib
......
......
__Py_NotImplementedStruct", referenced from:
_SwigPyObject_richcompare in hamlibpy_wrap.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [_Hamlib.la] Error 1
make[2]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_hamlib/hamlib/work/hamlib-4.1/bindings'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_hamlib/hamlib/work/hamlib-4.1/bindings'
make: *** [all-recursive] Error 1
make: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_hamlib/hamlib/work/hamlib-4.1'
Command failed: cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_hamlib/hamlib/work/Hamlib-4.1" && /usr/bin/make -j4 -w all
Exit code: 2
Error: Failed to build hamlib: command execution failed
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_hamlib/hamlib/main.log for details.
Error: Follow https://guide.macports.org/#project.tickets to report a bug.
Error: Processing of port hamlib failed
I suspect you compiled the modified Hamlib port on a Mac with a newer OS. Unfortunately, Python appears to be broken in many places on Lion and Mtn Lion.
I will likely need to give up soon using Python (via Macports) or just retire this old Mac.
Or I might try uninstalling Python via Macports and installing the latest version of Python available for Lion from https://www.python.org/downloads/mac-osx/ (which is Python 3.7.6) and see if that works better.
It still looks like the swig and swig-python ports on Macports are broken on Lion (and likely broken on Mtn Lion as well). Otherwise your modified hamlib port would have compiled okay on my old Mac running Lion.
comment:5 Changed 3 years ago by kencu (Ken)
No, I did it on 10.7 just like you. If yours failed, we can likely fix it. But now we'd need the whole MacPorts build log to do so.
comment:6 Changed 3 years ago by RobK88
Thanks for the great news that it can be done on Lion!
Do you want the main.log of the failed build of Hamlib with Python bindings?
P.S. I suspect the real problem lies with swig or python-swig. I have uninstalled them and reinstalled them using Macports. No errors were reported. But swig does not appear to be working properly. I even uninstalled swig using Macports and compiled swig manually directly from source. Swig compiles fine but fails when I run "make check". The python related self tests fail.
Changed 3 years ago by RobK88
main.log of failed attempt to build Hamlib with python bindings (--with-python-binding)
comment:7 Changed 3 years ago by kencu (Ken)
Because it builds and installs fine on my 10.7 system, it seems like something we should be able to fix on your system (ie if MacPorts' install of something was broken, my system wouldn't install it so easily).
Now, whether it works or not is to be sorted out later. I will not that precious few ports actually pass the test suites fully, and on 10.7, even fewer. Some actively used ports have like 80% of the tests fail, if you can believe that. But what we need them for works. SO I wouldn't put too much heartburn into the test suite, although it's always best if it 100% passes, for sure.
To get you working, let's see what might be different between your system and my working system. So please show me results of this:
$ port -v installed | grep swig swig @4.0.2_1 (active) platform='darwin 11' archs='x86_64' date='2021-01-17T08:51:38-0800' swig-python @4.0.2_1 (active) platform='darwin 11' archs='x86_64' date='2021-01-17T08:51:40-0800' swig3 @3.0.12_2 (active) platform='darwin 11' archs='x86_64' date='2021-01-17T08:51:37-0800' swig3-python @3.0.12_2 (active) platform='darwin 11' archs='x86_64' date='2021-01-17T08:51:40-0800'
comment:8 Changed 3 years ago by RobK88
Here is the output from my Mac running Lion. Looks like we have the same versions of swig and swig-python.
$ port -v installed | grep swig swig @4.0.2_1 (active) platform='darwin 11' archs='x86_64' date='2021-03-28T14:01:35-0400' swig-python @4.0.2_1 (active) platform='darwin 11' archs='x86_64' date='2021-03-28T14:02:54-0400' swig3 @3.0.12_2 (active) platform='darwin 11' archs='x86_64' date='2021-03-28T14:00:58-0400' swig3-python @3.0.12_2 (active) platform='darwin 11' archs='x86_64' date='2021-03-28T14:02:19-0400'
Here is some more info:
$ python --version Python 3.9.2 Grinchs-Mac-Pro:~ grinch$ python3 --version Python 3.9.2 Grinchs-Mac-Pro:~ grinch$ python2 --version Python 2.7.18 clang --version Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn) Target: x86_64-apple-darwin11.4.2 Thread model: posix
P.S. If it cannot be easily fixed. I can always trash and reinstall Macports. A good spring cleaning may be what is needed!
comment:9 Changed 3 years ago by kencu (Ken)
Most likely you have done some things to make your MacPorts installation "atypical".
The usual thing people do to mess this up is to use the "port select" mechanism to force certain binaries to be found on the PATH that really shouldn't be found. This causes untold wreckage with configure scripts that aren't expecting this, and can force weird mismatches between components.
So I see this in your configure log, and I can see that such binaries are being found.
:info:configure checking for /opt/local/bin/python version... 3.9
638 :info:configure checking for /opt/local/bin/python platform... darwin
639 :info:configure checking for /opt/local/bin/python script directory... ${prefix}/lib/python3.9/site-packages
640 :info:configure checking for /opt/local/bin/python extension module directory... ${exec_prefix}/lib/python3.9/site-packages
641 :info:configure checking Whether to build Tcl bindings... no
642 :info:configure checking whether to build lua binding... no
643 :info:configure checking for swig... /opt/local/bin/swig
644 :info:configure checking SWIG version... 4.0.2
645 :info:configure checking for SWIG library... /opt/local/share/swig/4.0.2
646 :info:configure checking whether to build bindings... yes
So I would -- at least temporarily -- disable all the "port select'd" stuff you have selected -- certainly disable all the python ones (python, python2, python3) -- but while you are at it, disable every single thing you may have "port selected" -- clang, gcc, whatever you have done. You can find these with this:
port select --summary
None of these ports are written to be sufficiently robust to overcome such forces.
Yes, sure -- ideally engineers would pore over the Portfile code and try to make sure that such forces are always considered, always dealt with, always managed.
however, MacPorts is a bunch of volunteers, and no amount of wishing it would be different will make it so. You just can't browbeat, pound, or otherwise cajole people into spending 10,000 hours fixing up Portfiles that work fine for the 99% of people to accomodate the 1% who actively go out of their way to mess themselves up...
comment:10 Changed 3 years ago by RobK88
Ken -- Many thanks for all the great tips!
I never thought my setup was atypical. But after your explanation, it was.
$ port select --summary Name Selected Options ==== ======== ======= clang none mp-clang-3.4 mp-clang-3.7 mp-clang-9.0 none cython cython39 cython27 cython39 none docutils py39-docutils py39-docutils none gcc none llvm-gcc42 mp-gcc10 mp-gcc5 mp-llvm-gcc42 none llvm none mp-llvm-3.4 mp-llvm-3.7 mp-llvm-9.0 none nosetests none nosetests27 nosetests39 none pip pip39 pip39 none pip2 none none pip3 none pip39 none pygments py39-pygments py38-pygments py39-pygments none python python39 python25-apple python26-apple python27 python27-apple python38 python39 none python2 python27 python25-apple python26-apple python27 python27-apple none python3 python39 python38 python39 none sphinx py39-sphinx py39-sphinx none
As you suggested, I undid my changes:
$ port select --summary Name Selected Options ==== ======== ======= clang none mp-clang-3.4 mp-clang-3.7 mp-clang-9.0 none cython none cython27 cython39 none docutils none py39-docutils none gcc none llvm-gcc42 mp-gcc10 mp-gcc5 mp-llvm-gcc42 none llvm none mp-llvm-3.4 mp-llvm-3.7 mp-llvm-9.0 none nosetests none nosetests27 nosetests39 none pip none pip39 none pip2 none none pip3 none pip39 none pygments none py38-pygments py39-pygments none python none python25-apple python26-apple python27 python27-apple python38 python39 none python2 none python25-apple python26-apple python27 python27-apple none python3 none python38 python39 none sphinx none py39-sphinx none
And yes, after modifying the portfile to add "--with-python-bindings" to the configuration, the port does compile and install! This is a great step forward.
But unfortunately, I need the Hamlib library compiled with python3 bindings not just python2 bindings.
So I uninstalled Hamlib using Macports and proceeded to compile Hamlib manually from source using the instructions at https://github.com/Hamlib/Hamlib/blob/master/bindings/README.python
Following these instructions, one should be able to build Hamlib with BOTH python2 and python3 bindings.
Here are the steps:
wget https://github.com/Hamlib/Hamlib/releases/download/4.1/hamlib-4.1.tar.gz tar -zxvf hamlib-4.1.tar.gz cd hamlib-4.1 ./configure --with-python-binding --prefix=/usr/local make ./configure --with-python-binding PYTHON_VERSION='3.9' --prefix=/usr/local cd bindings make cd .. (And if all goes well) sudo make install
Like with Macports, I can build hamlib with python2 bindings. But I am unable to build Hamlib with python3 bindings. After I reconfigure for python3 bindings, cd into bindings and run make, I get the same error as before:
$ ./configure --with-python-binding PYTHON_VERSION='3.9' --prefix=/usr/local
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /opt/local/bin/ggrep
checking for egrep... /opt/local/bin/ggrep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking for a BSD-compatible install... /opt/local/bin/ginstall -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /opt/local/bin/gmkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports the include directive... yes (GNU style)
checking whether make supports nested variables... yes
checking dependency style of gcc... gcc3
checking whether make supports nested variables... (cached) yes
checking for gcc... (cached) gcc
checking whether we are using the GNU C compiler... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gcc option to accept ISO C89... (cached) none needed
checking whether gcc understands -c and -o together... (cached) yes
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... gcc3
checking how to run the C preprocessor... gcc -E
checking for gawk... (cached) gawk
checking whether ln -s works... yes
checking for g++... yes
checking for ar... ar
checking the archiver (ar) interface... ar
checking for inline... inline
checking AM_CFLAGS for maximum warnings... -Wall
checking AM_CXXFLAGS for maximum warnings... -Wall
checking errno.h usability... yes
checking errno.h presence... yes
checking for errno.h... yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking getopt.h usability... yes
checking getopt.h presence... yes
checking for getopt.h... yes
checking limits.h usability... yes
checking limits.h presence... yes
checking for limits.h... yes
checking locale.h usability... yes
checking locale.h presence... yes
checking for locale.h... yes
checking malloc.h usability... no
checking malloc.h presence... no
checking for malloc.h... no
checking netdb.h usability... yes
checking netdb.h presence... yes
checking for netdb.h... yes
checking sgtty.h usability... yes
checking sgtty.h presence... yes
checking for sgtty.h... yes
checking stddef.h usability... yes
checking stddef.h presence... yes
checking for stddef.h... yes
checking termio.h usability... no
checking termio.h presence... no
checking for termio.h... no
checking termios.h usability... yes
checking termios.h presence... yes
checking for termios.h... yes
checking values.h usability... no
checking values.h presence... no
checking for values.h... no
checking arpa/inet.h usability... yes
checking arpa/inet.h presence... yes
checking for arpa/inet.h... yes
checking dev/ppbus/ppbconf.hdev/ppbus/ppi.h usability... no
checking dev/ppbus/ppbconf.hdev/ppbus/ppi.h presence... no
checking for dev/ppbus/ppbconf.hdev/ppbus/ppi.h... no
checking linux/hidraw.h usability... no
checking linux/hidraw.h presence... no
checking for linux/hidraw.h... no
checking linux/ioctl.h usability... no
checking linux/ioctl.h presence... no
checking for linux/ioctl.h... no
checking linux/parport.h usability... no
checking linux/parport.h presence... no
checking for linux/parport.h... no
checking linux/ppdev.h usability... no
checking linux/ppdev.h presence... no
checking for linux/ppdev.h... no
checking netinet/in.h usability... yes
checking netinet/in.h presence... yes
checking for netinet/in.h... yes
checking sys/ioccom.h usability... yes
checking sys/ioccom.h presence... yes
checking for sys/ioccom.h... yes
checking sys/ioctl.h usability... yes
checking sys/ioctl.h presence... yes
checking for sys/ioctl.h... yes
checking sys/param.h usability... yes
checking sys/param.h presence... yes
checking for sys/param.h... yes
checking sys/socket.h usability... yes
checking sys/socket.h presence... yes
checking for sys/socket.h... yes
checking for sys/stat.h... (cached) yes
checking sys/time.h usability... yes
checking sys/time.h presence... yes
checking for sys/time.h... yes
checking sys/select.h usability... yes
checking sys/select.h presence... yes
checking for sys/select.h... yes
checking glob.h usability... yes
checking glob.h presence... yes
checking for glob.h... yes
checking build system type... x86_64-apple-darwin11.4.2
checking host system type... x86_64-apple-darwin11.4.2
checking ws2tcpip.h usability... no
checking ws2tcpip.h presence... no
checking for ws2tcpip.h... no
checking wspiapi.h usability... no
checking wspiapi.h presence... no
checking for wspiapi.h... no
checking whether time.h and sys/time.h may both be included... yes
checking for library containing nanosleep... none required
checking pthread.h usability... yes
checking pthread.h presence... yes
checking for pthread.h... yes
checking for sys/types.h... (cached) yes
checking windows.h usability... no
checking windows.h presence... no
checking for windows.h... no
checking for winioctl.h... no
checking for winbase.h... no
checking for getopt... yes
checking for getopt_long... yes
checking for usleep... yes
checking for sleep... yes
checking for nanosleep... yes
checking for gettimeofday... yes
checking for struct timezone... yes
checking for ssize_t... yes
checking for getopt... (cached) yes
checking for getopt_long... (cached) yes
checking for usleep... (cached) yes
checking for gettimeofday... (cached) yes
checking for Sleep... no
checking whether pthreads work with -pthread... yes
checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE
checking if more special flags are required for pthreads... -D_THREAD_SAFE
checking for PTHREAD_PRIO_INHERIT... yes
checking POSIX termios... yes
checking for size_t... yes
checking whether time.h and sys/time.h may both be included... (cached) yes
checking for siginfo_t... yes
checking for sig_atomic_t... yes
checking for sin... yes
checking for connect... yes
checking for gethostbyname... yes
checking for gethostbyname... (cached) yes
checking for struct addrinfo... yes
checking whether gai_strerror is declared... yes
checking for getaddrinfo... (cached) yes
checking for cfmakeraw... yes
checking for floor... yes
checking for getpagesize... yes
checking for getpagesize... (cached) yes
checking for gettimeofday... (cached) yes
checking for inet_ntoa... yes
checking for ioctl... yes
checking for memchr... yes
checking for memmove... yes
checking for memset... yes
checking for pow... yes
checking for rint... yes
checking for select... yes
checking for setitimer... yes
checking for setlocale... yes
checking for sigaction... yes
checking for signal... yes
checking for snprintf... yes
checking for socket... yes
checking for sqrt... yes
checking for strchr... yes
checking for strdup... yes
checking for strerror... yes
checking for strncasecmp... yes
checking for strrchr... yes
checking for strstr... yes
checking for strtol... yes
checking for glob... yes
checking for socketpair... yes
checking for working alloca.h... yes
checking for alloca... yes
checking how to print strings... printf
checking for a sed that does not truncate output... /opt/local/bin/gsed
checking for fgrep... /opt/local/bin/ggrep -F
checking for ld used by gcc... /usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1/ld
checking if the linker (/usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1/ld) is GNU ld... no
checking for BSD- or MS-compatible name lister (nm)... /opt/local/bin/nm
checking the name lister (/opt/local/bin/nm) interface... BSD nm
checking the maximum length of command line arguments... 196608
checking how to convert x86_64-apple-darwin11.4.2 file names to x86_64-apple-darwin11.4.2 format... func_convert_file_noop
checking how to convert x86_64-apple-darwin11.4.2 file names to toolchain format... func_convert_file_noop
checking for /usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1/ld option to reload object files... -r
checking for objdump... no
checking how to recognize dependent libraries... pass_all
checking for dlltool... no
checking how to associate runtime and link libraries... printf %s\n
checking for archiver @FILE support... no
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /opt/local/bin/nm output from gcc object... ok
checking for sysroot... no
checking for a working dd... /bin/dd
checking how to truncate binary pipes... /bin/dd bs=4096 count=1
checking for mt... no
checking if : is a manifest tool... no
checking for dsymutil... dsymutil
checking for nmedit... nmedit
checking for lipo... lipo
checking for otool... otool
checking for otool64... no
checking for -single_module linker flag... yes
checking for -exported_symbols_list linker flag... yes
checking for -force_load linker flag... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fno-common -DPIC
checking if gcc PIC flag -fno-common -DPIC works... yes
checking if gcc static flag -static works... no
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1/ld) supports shared libraries... yes
checking dynamic linker characteristics... darwin11.4.2 dyld
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking how to run the C++ preprocessor... g++ -E
checking for ld used by g++... /usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1/ld
checking if the linker (/usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1/ld) is GNU ld... no
checking whether the g++ linker (/usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1/ld) supports shared libraries... yes
checking for g++ option to produce PIC... -fno-common -DPIC
checking if g++ PIC flag -fno-common -DPIC works... yes
checking if g++ static flag -static works... no
checking if g++ supports -c -o file.o... yes
checking if g++ supports -c -o file.o... (cached) yes
checking whether the g++ linker (/usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1/ld) supports shared libraries... yes
checking dynamic linker characteristics... darwin11.4.2 dyld
checking how to hardcode library paths into programs... immediate
checking whether C99 struct/array initializers are supported... yes
checking whether to build USB dependent backends... yes
checking for libusb_init in -lusb-1.0... no
configure: WARNING: libusb_init was not found in libusb-1.0--USB backends will be disabled
checking libusb.h usability... no
checking libusb.h presence... no
checking for libusb.h... no
checking libusb-1.0/libusb.h usability... no
checking libusb-1.0/libusb.h presence... no
checking for libusb-1.0/libusb.h... no
checking whether to use readline in rigctl/rotctl... yes
checking for a readline compatible library... -lreadline
checking readline.h usability... no
checking readline.h presence... no
checking for readline.h... no
checking readline/readline.h usability... yes
checking readline/readline.h presence... yes
checking for readline/readline.h... yes
checking whether readline supports history... yes
checking history.h usability... no
checking history.h presence... no
checking for history.h... no
checking readline/history.h usability... yes
checking readline/history.h presence... yes
checking for readline/history.h... yes
checking whether to use INDI in rigctl/rotctl... checking for nova library... checking libnova/libnova.h usability... no
checking libnova/libnova.h presence... no
checking for libnova/libnova.h... no
no
configure: WARNING: libnova support not found, required by INDI.
checking whether to build HTML rig feature matrix... check
checking gd.h usability... no
checking gd.h presence... no
checking for gd.h... no
checking whether to build rigmem XML support... no
checking whether to build USRP backend... no
checking whether to build C++ binding... yes
checking whether to build perl binding... no
checking whether to build python binding... yes
checking for python3.9... /opt/local/bin/python3.9
checking for a version of Python >= '2.1.0'... yes
checking for the distutils Python package... yes
checking for Python include path... -I/opt/local/Library/Frameworks/Python.framework/Versions/3.9/include/python3.9
checking for Python library path... -L/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib -lpython3.9
checking for Python site-packages path... /opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages
checking python extra libraries... -ldl -framework CoreFoundation
checking python extra linking flags... -L/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/config-3.9-darwin -lpython3.9 -ldl -framework CoreFoundation
checking consistency of all components of python development environment... yes
checking whether /opt/local/bin/python3.9 version is >= 2.1... yes
checking for /opt/local/bin/python3.9 version... 3.9
checking for /opt/local/bin/python3.9 platform... darwin
checking for /opt/local/bin/python3.9 script directory... ${prefix}/lib/python3.9/site-packages
checking for /opt/local/bin/python3.9 extension module directory... ${exec_prefix}/lib/python3.9/site-packages
checking Whether to build Tcl bindings... no
checking whether to build lua binding... no
checking for swig... /opt/local/bin/swig
checking SWIG version... 4.0.2
checking for SWIG library... /opt/local/share/swig/4.0.2
checking whether to build bindings... yes
checking whether to build winradio backend... yes
checking for dlopen in -ldl... yes
checking for dlfcn.h... (cached) yes
Build_OS is darwin11.4.2
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating macros/Makefile
config.status: creating include/Makefile
config.status: creating lib/Makefile
config.status: creating src/Makefile
config.status: creating c++/Makefile
config.status: creating bindings/Makefile
config.status: creating doc/Makefile
config.status: creating doc/hamlib.cfg
config.status: creating rotators/amsat/Makefile
config.status: creating rotators/ars/Makefile
config.status: creating rotators/celestron/Makefile
config.status: creating rotators/cnctrk/Makefile
config.status: creating rotators/easycomm/Makefile
config.status: creating rotators/ether6/Makefile
config.status: creating rotators/fodtrack/Makefile
config.status: creating rotators/gs232a/Makefile
config.status: creating rotators/heathkit/Makefile
config.status: creating rotators/ioptron/Makefile
config.status: creating rotators/m2/Makefile
config.status: creating rotators/meade/Makefile
config.status: creating rotators/prosistel/Makefile
config.status: creating rotators/rotorez/Makefile
config.status: creating rotators/sartek/Makefile
config.status: creating rotators/spid/Makefile
config.status: creating rotators/ts7400/Makefile
config.status: creating rotators/indi/Makefile
config.status: creating rotators/satel/Makefile
config.status: creating rigs/adat/Makefile
config.status: creating rigs/alinco/Makefile
config.status: creating rigs/aor/Makefile
config.status: creating rigs/barrett/Makefile
config.status: creating rigs/dorji/Makefile
config.status: creating rigs/drake/Makefile
config.status: creating rigs/dummy/Makefile
config.status: creating rigs/elad/Makefile
config.status: creating rigs/flexradio/Makefile
config.status: creating rigs/icmarine/Makefile
config.status: creating rigs/icom/Makefile
config.status: creating rigs/jrc/Makefile
config.status: creating rigs/kachina/Makefile
config.status: creating rigs/kenwood/Makefile
config.status: creating rigs/kit/Makefile
config.status: creating rigs/lowe/Makefile
config.status: creating rigs/pcr/Makefile
config.status: creating rigs/prm80/Makefile
config.status: creating rigs/racal/Makefile
config.status: creating rigs/rft/Makefile
config.status: creating rigs/rs/Makefile
config.status: creating rigs/skanti/Makefile
config.status: creating rigs/tapr/Makefile
config.status: creating rigs/tentec/Makefile
config.status: creating rigs/tuner/Makefile
config.status: creating rigs/uniden/Makefile
config.status: creating rigs/winradio/Makefile
config.status: creating rigs/wj/Makefile
config.status: creating rigs/yaesu/Makefile
config.status: creating tests/Makefile
config.status: creating scripts/Makefile
config.status: creating android/Makefile
config.status: creating amplifiers/elecraft/Makefile
config.status: creating hamlib.pc
config.status: creating include/config.h
config.status: executing depfiles commands
config.status: executing libtool commands
----------------------------------------------------------------------
Hamlib Version 4.1 configuration:
Prefix /usr/local
Preprocessor gcc -E
C Compiler gcc -g -O2
C++ Compiler g++ -g -O2
Package features:
With C++ binding yes
With Perl binding no
With Python binding yes
With TCL binding no
With Lua binding no
With rigmem XML support no
With Readline support yes
With INDI support no
Enable HTML rig feature matrix no
Enable WinRadio yes
Enable USRP no
Enable USB backends yes
Enable shared libs yes
Enable static libs yes
-----------------------------------------------------------------------
Grinchs-Mac-Pro:hamlib-4.1 grinch$ cd bindings/
Grinchs-Mac-Pro:bindings grinch$ make
make all-am
CC hamlibpy_wrap.lo
CCLD _Hamlib.la
Undefined symbols for architecture x86_64:
"_PyArg_UnpackTuple", referenced from:
_SwigPyObject_own in hamlibpy_wrap.o
__wrap_rig_debug in hamlibpy_wrap.o
"_PyBool_FromLong", referenced from:
_SwigPyObject_richcompare in hamlibpy_wrap.o
_SwigPyObject_own in hamlibpy_wrap.o
"_PyBytes_AsStringAndSize", referenced from:
_SWIG_AsCharPtrAndSize in hamlibpy_wrap.o
"_PyCFunction_Type", referenced from:
_SWIG_PyInstanceMethod_New in hamlibpy_wrap.o
_SWIG_Python_ConvertFunctionPtr in hamlibpy_wrap.o
"_PyCMethod_New", referenced from:
_SWIG_PyInstanceMethod_New in hamlibpy_wrap.o
"_PyCapsule_GetPointer", referenced from:
_SWIG_Python_DestroyModule in hamlibpy_wrap.o
_SWIG_Python_TypeQuery in hamlibpy_wrap.o
"_PyCapsule_Import", referenced from:
_SWIG_Python_TypeQuery in hamlibpy_wrap.o
_PyInit__Hamlib in hamlibpy_wrap.o
"_PyCapsule_New", referenced from:
_SWIG_Python_TypeQuery in hamlibpy_wrap.o
_PyInit__Hamlib in hamlibpy_wrap.o
"_PyDict_GetItem", referenced from:
_SWIG_Python_TypeQuery in hamlibpy_wrap.o
"_PyDict_New", referenced from:
_SWIG_Python_TypeQuery in hamlibpy_wrap.o
_SWIG_Python_NewPointerObj in hamlibpy_wrap.o
_PyInit__Hamlib in hamlibpy_wrap.o
"_PyDict_SetItem", referenced from:
_SWIG_Python_TypeQuery in hamlibpy_wrap.o
"_PyDict_SetItemString", referenced from:
_PyInit__Hamlib in hamlibpy_wrap.o
"_PyErr_Clear", referenced from:
_SwigPyClientData_New in hamlibpy_wrap.o
_SWIG_AsVal_double in hamlibpy_wrap.o
__wrap_dmmm2dec in hamlibpy_wrap.o
__wrap_dms2dec in hamlibpy_wrap.o
__wrap_rot_check_backend in hamlibpy_wrap.o
__wrap_rot_unregister in hamlibpy_wrap.o
__wrap_hl_usleep in hamlibpy_wrap.o
...
"_PyErr_Fetch", referenced from:
_SwigPyObject_dealloc in hamlibpy_wrap.o
_SWIG_Python_RaiseOrModifyTypeError in hamlibpy_wrap.o
"_PyErr_Format", referenced from:
_SWIG_Python_UnpackTuple in hamlibpy_wrap.o
_swig_varlink_setattr in hamlibpy_wrap.o
_swig_varlink_getattr in hamlibpy_wrap.o
"_PyErr_GivenExceptionMatches", referenced from:
_SWIG_Python_RaiseOrModifyTypeError in hamlibpy_wrap.o
"_PyErr_Occurred", referenced from:
_swig_varlink_setattr in hamlibpy_wrap.o
_swig_varlink_getattr in hamlibpy_wrap.o
_SwigPyClientData_New in hamlibpy_wrap.o
_SWIG_AsVal_double in hamlibpy_wrap.o
__wrap_dmmm2dec in hamlibpy_wrap.o
__wrap_dms2dec in hamlibpy_wrap.o
__wrap_rot_check_backend in hamlibpy_wrap.o
...
"_PyErr_Restore", referenced from:
_SwigPyObject_dealloc in hamlibpy_wrap.o
_SWIG_Python_RaiseOrModifyTypeError in hamlibpy_wrap.o
"_PyErr_SetString", referenced from:
_Swig_var_hamlib_copyright_set in hamlibpy_wrap.o
_Swig_var_hamlib_version_set in hamlibpy_wrap.o
_SWIG_Python_UnpackTuple in hamlibpy_wrap.o
__wrap_dmmm2dec in hamlibpy_wrap.o
__wrap_dms2dec in hamlibpy_wrap.o
__wrap_azimuth_long_path in hamlibpy_wrap.o
__wrap_distance_long_path in hamlibpy_wrap.o
...
"_PyErr_WriteUnraisable", referenced from:
_SwigPyObject_dealloc in hamlibpy_wrap.o
"_PyExc_AttributeError", referenced from:
_Swig_var_hamlib_copyright_set in hamlibpy_wrap.o
_Swig_var_hamlib_version_set in hamlibpy_wrap.o
_swig_varlink_setattr in hamlibpy_wrap.o
_swig_varlink_getattr in hamlibpy_wrap.o
__wrap_dmmm2dec in hamlibpy_wrap.o
__wrap_dms2dec in hamlibpy_wrap.o
__wrap_azimuth_long_path in hamlibpy_wrap.o
...
"_PyExc_IOError", referenced from:
__wrap_dmmm2dec in hamlibpy_wrap.o
__wrap_dms2dec in hamlibpy_wrap.o
__wrap_azimuth_long_path in hamlibpy_wrap.o
__wrap_distance_long_path in hamlibpy_wrap.o
__wrap_Amp_set_powerstat in hamlibpy_wrap.o
__wrap_Amp_set_freq in hamlibpy_wrap.o
__wrap_Amp_reset in hamlibpy_wrap.o
...
"_PyExc_IndexError", referenced from:
__wrap_dmmm2dec in hamlibpy_wrap.o
__wrap_dms2dec in hamlibpy_wrap.o
__wrap_azimuth_long_path in hamlibpy_wrap.o
__wrap_distance_long_path in hamlibpy_wrap.o
__wrap_Amp_set_powerstat in hamlibpy_wrap.o
__wrap_Amp_set_freq in hamlibpy_wrap.o
__wrap_Amp_reset in hamlibpy_wrap.o
...
"_PyExc_MemoryError", referenced from:
__wrap_dmmm2dec in hamlibpy_wrap.o
__wrap_dms2dec in hamlibpy_wrap.o
__wrap_azimuth_long_path in hamlibpy_wrap.o
__wrap_distance_long_path in hamlibpy_wrap.o
__wrap_Amp_set_powerstat in hamlibpy_wrap.o
__wrap_Amp_set_freq in hamlibpy_wrap.o
__wrap_Amp_reset in hamlibpy_wrap.o
...
"_PyExc_OverflowError", referenced from:
__wrap_dmmm2dec in hamlibpy_wrap.o
__wrap_dms2dec in hamlibpy_wrap.o
__wrap_azimuth_long_path in hamlibpy_wrap.o
__wrap_distance_long_path in hamlibpy_wrap.o
__wrap_rot_check_backend in hamlibpy_wrap.o
__wrap_rot_unregister in hamlibpy_wrap.o
__wrap_hl_usleep in hamlibpy_wrap.o
...
"_PyExc_RuntimeError", referenced from:
__wrap_dmmm2dec in hamlibpy_wrap.o
__wrap_dms2dec in hamlibpy_wrap.o
__wrap_azimuth_long_path in hamlibpy_wrap.o
__wrap_distance_long_path in hamlibpy_wrap.o
__wrap_Amp_set_powerstat in hamlibpy_wrap.o
__wrap_Amp_set_freq in hamlibpy_wrap.o
__wrap_Amp_reset in hamlibpy_wrap.o
...
"_PyExc_SyntaxError", referenced from:
__wrap_dmmm2dec in hamlibpy_wrap.o
__wrap_dms2dec in hamlibpy_wrap.o
__wrap_azimuth_long_path in hamlibpy_wrap.o
__wrap_distance_long_path in hamlibpy_wrap.o
__wrap_Amp_set_powerstat in hamlibpy_wrap.o
__wrap_Amp_set_freq in hamlibpy_wrap.o
__wrap_Amp_reset in hamlibpy_wrap.o
...
"_PyExc_SystemError", referenced from:
_SWIG_Python_UnpackTuple in hamlibpy_wrap.o
__wrap_dmmm2dec in hamlibpy_wrap.o
__wrap_dms2dec in hamlibpy_wrap.o
__wrap_azimuth_long_path in hamlibpy_wrap.o
__wrap_distance_long_path in hamlibpy_wrap.o
__wrap_Amp_set_powerstat in hamlibpy_wrap.o
__wrap_Amp_set_freq in hamlibpy_wrap.o
...
"_PyExc_TypeError", referenced from:
_SWIG_Python_UnpackTuple in hamlibpy_wrap.o
__wrap_dmmm2dec in hamlibpy_wrap.o
__wrap_dms2dec in hamlibpy_wrap.o
__wrap_azimuth_long_path in hamlibpy_wrap.o
__wrap_distance_long_path in hamlibpy_wrap.o
__wrap_rot_check_backend in hamlibpy_wrap.o
__wrap_rot_unregister in hamlibpy_wrap.o
...
"_PyExc_ValueError", referenced from:
__wrap_dmmm2dec in hamlibpy_wrap.o
__wrap_dms2dec in hamlibpy_wrap.o
__wrap_azimuth_long_path in hamlibpy_wrap.o
__wrap_distance_long_path in hamlibpy_wrap.o
__wrap_Amp_set_powerstat in hamlibpy_wrap.o
__wrap_Amp_set_freq in hamlibpy_wrap.o
__wrap_Amp_reset in hamlibpy_wrap.o
...
"_PyExc_ZeroDivisionError", referenced from:
__wrap_dmmm2dec in hamlibpy_wrap.o
__wrap_dms2dec in hamlibpy_wrap.o
__wrap_azimuth_long_path in hamlibpy_wrap.o
__wrap_distance_long_path in hamlibpy_wrap.o
__wrap_Amp_set_powerstat in hamlibpy_wrap.o
__wrap_Amp_set_freq in hamlibpy_wrap.o
__wrap_Amp_reset in hamlibpy_wrap.o
...
"_PyFloat_AsDouble", referenced from:
_SWIG_AsVal_double in hamlibpy_wrap.o
"_PyFloat_FromDouble", referenced from:
__wrap_dmmm2dec in hamlibpy_wrap.o
__wrap_dms2dec in hamlibpy_wrap.o
__wrap_azimuth_long_path in hamlibpy_wrap.o
__wrap_distance_long_path in hamlibpy_wrap.o
__wrap_Rig_get_split_freq in hamlibpy_wrap.o
__wrap_Rig_get_freq in hamlibpy_wrap.o
__wrap_Rig_get_level_f__SWIG_0 in hamlibpy_wrap.o
...
"_PyFloat_Type", referenced from:
_SWIG_AsVal_double in hamlibpy_wrap.o
"_PyImport_AddModule", referenced from:
_PyInit__Hamlib in hamlibpy_wrap.o
"_PyInstanceMethod_New", referenced from:
_SWIG_PyInstanceMethod_New in hamlibpy_wrap.o
"_PyList_Append", referenced from:
_SWIG_Python_AppendOutput in hamlibpy_wrap.o
"_PyList_New", referenced from:
__wrap_rig_state_attenuator_get in hamlibpy_wrap.o
__wrap_rig_state_preamp_get in hamlibpy_wrap.o
__wrap_rig_caps_attenuator_get in hamlibpy_wrap.o
__wrap_rig_caps_preamp_get in hamlibpy_wrap.o
_SWIG_Python_AppendOutput in hamlibpy_wrap.o
"_PyList_SetItem", referenced from:
__wrap_rig_state_attenuator_get in hamlibpy_wrap.o
__wrap_rig_state_preamp_get in hamlibpy_wrap.o
__wrap_rig_caps_attenuator_get in hamlibpy_wrap.o
__wrap_rig_caps_preamp_get in hamlibpy_wrap.o
_SWIG_Python_AppendOutput in hamlibpy_wrap.o
"_PyLong_AsDouble", referenced from:
_SWIG_AsVal_double in hamlibpy_wrap.o
"_PyLong_AsLong", referenced from:
__wrap_dmmm2dec in hamlibpy_wrap.o
__wrap_dms2dec in hamlibpy_wrap.o
__wrap_rot_check_backend in hamlibpy_wrap.o
__wrap_rot_unregister in hamlibpy_wrap.o
__wrap_rig_need_debug in hamlibpy_wrap.o
__wrap_rig_set_debug_time_stamp in hamlibpy_wrap.o
__wrap_rig_set_debug in hamlibpy_wrap.o
...
"_PyLong_AsUnsignedLong", referenced from:
__wrap_hl_usleep in hamlibpy_wrap.o
__wrap_rig_check_backend in hamlibpy_wrap.o
__wrap_rig_unregister in hamlibpy_wrap.o
__wrap_rig_get_caps_int in hamlibpy_wrap.o
__wrap_toneArray___setitem__ in hamlibpy_wrap.o
__wrap_channelArray___setitem__ in hamlibpy_wrap.o
__wrap_Rig_get_ext_level in hamlibpy_wrap.o
...
"_PyLong_AsUnsignedLongLong", referenced from:
__wrap_rig_setting2idx in hamlibpy_wrap.o
__wrap_Rig_get_level__SWIG_1 in hamlibpy_wrap.o
__wrap_Rig_get_func in hamlibpy_wrap.o
__wrap_Rig_passband_wide in hamlibpy_wrap.o
__wrap_Rig_passband_narrow in hamlibpy_wrap.o
__wrap_Rig_passband_normal in hamlibpy_wrap.o
__wrap_Rig_has_set_func in hamlibpy_wrap.o
...
"_PyLong_FromLong", referenced from:
__wrap_rot_load_all_backends in hamlibpy_wrap.o
__wrap_rot_check_backend in hamlibpy_wrap.o
__wrap_rot_unregister in hamlibpy_wrap.o
__wrap_hl_usleep in hamlibpy_wrap.o
__wrap_rig_load_all_backends in hamlibpy_wrap.o
__wrap_rig_check_backend in hamlibpy_wrap.o
__wrap_rig_unregister in hamlibpy_wrap.o
...
"_PyLong_FromSize_t", referenced from:
__wrap_toneArray___getitem__ in hamlibpy_wrap.o
__wrap_Rig_get_dcs_sql in hamlibpy_wrap.o
__wrap_Rig_get_ctcss_sql in hamlibpy_wrap.o
__wrap_Rig_get_dcs_code in hamlibpy_wrap.o
__wrap_Rig_get_ctcss_tone in hamlibpy_wrap.o
__wrap_Rig_get_vfo in hamlibpy_wrap.o
__wrap_rig_parse_vfo in hamlibpy_wrap.o
...
"_PyLong_FromUnsignedLongLong", referenced from:
_PyInit__Hamlib in hamlibpy_wrap.o
__wrap_freq_range_t_modes_get in hamlibpy_wrap.o
__wrap_tuning_step_list_modes_get in hamlibpy_wrap.o
__wrap_filter_list_modes_get in hamlibpy_wrap.o
__wrap_channel_mode_get in hamlibpy_wrap.o
__wrap_channel_tx_mode_get in hamlibpy_wrap.o
__wrap_channel_funcs_get in hamlibpy_wrap.o
...
"_PyLong_FromVoidPtr", referenced from:
_SwigPyObject_long in hamlibpy_wrap.o
"_PyModule_AddObject", referenced from:
_PyInit__Hamlib in hamlibpy_wrap.o
"_PyModule_Create2", referenced from:
_PyInit__Hamlib in hamlibpy_wrap.o
"_PyModule_GetDict", referenced from:
_PyInit__Hamlib in hamlibpy_wrap.o
"_PyObject_Call", referenced from:
_SWIG_Python_NewPointerObj in hamlibpy_wrap.o
"_PyObject_CallFunctionObjArgs", referenced from:
_SwigPyObject_dealloc in hamlibpy_wrap.o
_SWIG_Python_ConvertPtrAndOwn in hamlibpy_wrap.o
"_PyObject_Free", referenced from:
_SwigPyPacked_dealloc in hamlibpy_wrap.o
_SwigPyObject_dealloc in hamlibpy_wrap.o
_PyInit__Hamlib in hamlibpy_wrap.o
"_PyObject_GenericGetAttr", referenced from:
_tmp.11546 in hamlibpy_wrap.o
_tmp.11449 in hamlibpy_wrap.o
"_PyObject_GetAttr", referenced from:
_SWIG_Python_GetSwigThis in hamlibpy_wrap.o
"_PyObject_GetAttrString", referenced from:
_SwigPyClientData_New in hamlibpy_wrap.o
"_PyObject_IsInstance", referenced from:
_SwigPyClientData_New in hamlibpy_wrap.o
"_PyObject_IsTrue", referenced from:
_SwigPyObject_own in hamlibpy_wrap.o
"_PyObject_SetAttr", referenced from:
_SWIG_Python_InitShadowInstance in hamlibpy_wrap.o
_SWIG_Python_NewPointerObj in hamlibpy_wrap.o
"_PyTuple_GetSlice", referenced from:
__wrap_rig_debug in hamlibpy_wrap.o
"_PyTuple_New", referenced from:
_SwigPyClientData_New in hamlibpy_wrap.o
_SWIG_Python_NewPointerObj in hamlibpy_wrap.o
"_PyTuple_SetItem", referenced from:
_SwigPyClientData_New in hamlibpy_wrap.o
"_PyTuple_Size", referenced from:
__wrap_rig_debug in hamlibpy_wrap.o
"_PyType_IsSubtype", referenced from:
_SWIG_AsVal_double in hamlibpy_wrap.o
_SWIG_PyInstanceMethod_New in hamlibpy_wrap.o
_SWIG_Python_ConvertFunctionPtr in hamlibpy_wrap.o
"_PyType_Ready", referenced from:
_SwigPyPacked_dealloc in hamlibpy_wrap.o
_SwigPyObject_dealloc in hamlibpy_wrap.o
_SwigPyObject_Check in hamlibpy_wrap.o
_SWIG_Python_GetSwigThis in hamlibpy_wrap.o
_SWIG_Python_NewPointerObj in hamlibpy_wrap.o
_PyInit__Hamlib in hamlibpy_wrap.o
"_PyType_Type", referenced from:
_SwigPyClientData_New in hamlibpy_wrap.o
"_PyUnicode_AsUTF8String", referenced from:
_SWIG_AsCharPtrAndSize in hamlibpy_wrap.o
"_PyUnicode_Concat", referenced from:
_SwigPyObject_repr in hamlibpy_wrap.o
_swig_varlink_str in hamlibpy_wrap.o
"_PyUnicode_DecodeUTF8", referenced from:
__wrap_hamlib_port_t_pathname_get in hamlibpy_wrap.o
__wrap_channel_channel_desc_get in hamlibpy_wrap.o
__wrap_Amp_get_info in hamlibpy_wrap.o
__wrap_Amp_get_conf in hamlibpy_wrap.o
__wrap_Rot_get_info in hamlibpy_wrap.o
__wrap_Rot_get_conf in hamlibpy_wrap.o
__wrap_Rig_get_info in hamlibpy_wrap.o
...
"_PyUnicode_FromFormat", referenced from:
_SwigPyPacked_repr in hamlibpy_wrap.o
_SwigPyPacked_str in hamlibpy_wrap.o
_SwigPyObject_repr in hamlibpy_wrap.o
_SWIG_Python_RaiseOrModifyTypeError in hamlibpy_wrap.o
"_PyUnicode_FromString", referenced from:
_SwigPyPacked_str in hamlibpy_wrap.o
_swig_varlink_str in hamlibpy_wrap.o
_SWIG_Python_GetSwigThis in hamlibpy_wrap.o
_SWIG_Python_InitShadowInstance in hamlibpy_wrap.o
_SWIG_Python_DestroyModule in hamlibpy_wrap.o
_SWIG_Python_TypeQuery in hamlibpy_wrap.o
_SWIG_Python_NewPointerObj in hamlibpy_wrap.o
...
"_PyUnicode_InternFromString", referenced from:
_swig_varlink_repr in hamlibpy_wrap.o
_swig_varlink_str in hamlibpy_wrap.o
"_Py_DecRef", referenced from:
_SwigPyObject_repr in hamlibpy_wrap.o
_swig_varlink_str in hamlibpy_wrap.o
"__PyObject_New", referenced from:
_SwigPyObject_dealloc in hamlibpy_wrap.o
_SWIG_Python_NewPointerObj in hamlibpy_wrap.o
_PyInit__Hamlib in hamlibpy_wrap.o
"__Py_Dealloc", referenced from:
_SwigPyObject_dealloc in hamlibpy_wrap.o
_SWIG_Python_GetSwigThis in hamlibpy_wrap.o
_SWIG_Python_ConvertPtrAndOwn in hamlibpy_wrap.o
_SWIG_Python_RaiseOrModifyTypeError in hamlibpy_wrap.o
_SWIG_Python_DestroyModule in hamlibpy_wrap.o
_SWIG_Python_TypeQuery in hamlibpy_wrap.o
_SWIG_AsCharPtrAndSize in hamlibpy_wrap.o
...
"__Py_NoneStruct", referenced from:
_SwigPyObject_next in hamlibpy_wrap.o
_SwigPyObject_disown in hamlibpy_wrap.o
_SwigPyObject_acquire in hamlibpy_wrap.o
_Amp_swigregister in hamlibpy_wrap.o
_Rot_swigregister in hamlibpy_wrap.o
_toneArray_swigregister in hamlibpy_wrap.o
_channelArray_swigregister in hamlibpy_wrap.o
...
"__Py_NotImplementedStruct", referenced from:
_SwigPyObject_richcompare in hamlibpy_wrap.o
ld: symbol(s) not found for architecture x86_64
collect2: ld returned 1 exit status
make[1]: *** [_Hamlib.la] Error 1
make: *** [all] Error 2
Like before, the necessary symbols (or headers file?) for swig cannot be found.
Ken -- If you have time, please let me know if you can manually compile hamlib with python2 and python3 bindings on your Mac running Lion using the instructions at https://github.com/Hamlib/Hamlib/blob/master/bindings/README.python. I suspect you will have the same problem.
P.S. Do not attempt to run the tests -- pytest.py or pytest3.py. They only appear to work once hamlib is installed using "sudo make install". The instructions on the website appear to be wrong with respect to the tests.
P.S. If all goes well, hamlib should be installed in /usr/local/lib/python2.7/site-packages and /usr/local/lib/python3.9/site-packages. The user may need to set the PYTHONPATH variable so other applications can find hamlib.
export PYTHONPATH=/usr/local/lib/python2.7/site-packages:/usr/local/lib/python3.9/site-packages:$PYTHONPATH
P.S. After I made my Mac more typical (after removing my changes using the "port select" command), I uninstalled swig, swig-python and recompiled and reinstalled them using Macports. But that did not fix the problem. It was worth a try.
comment:11 follow-up: 13 Changed 3 years ago by RobK88
Maybe the problem is a /usr/local vs /opt/local issue? But why would Hamlib compile and install okay when python2 bindings are built? It looks like a Macports python3 issue relating to swig.
comment:12 follow-up: 15 Changed 3 years ago by kencu (Ken)
well -- progress!
But once again, your easiest way to success is likely going to be to sort out how to put the proper args into the MacPorts hamlib Portfile rather than try to redo all the configuration yourself. I suggest you don't export a PYTHONPATH, don't install into /usr/local, and don't try to duplicate a huge amount of MacPorts setup.
For example -- Josh Root has put about -- I won't guess how many hours -- into setting up all the python setup scripts so they properly find the right parts during a build. This is very complicated!
Even just the compilers need setup, and that is trivial to do -- look at what you found on your own:
Preprocessor gcc -E C Compiler gcc -g -O2 C++ Compiler g++ -g -O2
There is no way that trying to build much of anything with gcc and g++ is going to work on MacOS, especially not on 10.7 where we almost certainly need some newer compiler.
So let's figure out the options you need for python3 and try to get that working.
Now you might need to compromise a bit; it is not trivial to run multiple different make sessions in one MacPorts build. It's just not set up that way. So can you live with just one of the python bindings? or have a variant for either python2 or python3?
comment:13 Changed 3 years ago by kencu (Ken)
Replying to RobK88:
Maybe the problem is a /usr/local vs /opt/local issue? But why would Hamlib compile and install okay when python2 bindings are built? It looks like a Macports python3 issue relating to swig.
As far as I can see, MacPorts is working just fine. This is "pilot error" :>
comment:14 Changed 3 years ago by kencu (Ken)
Here, for example, is the background configuration MacPorts does when configuring hamlib on Mojave (this does not include all the python setup stuff that is hidden away in the various portgroups, base, etc):
DEBUG: Executing org.macports.configure (hamlib) DEBUG: Environment: CC='/usr/bin/clang' CC_PRINT_OPTIONS='YES' CC_PRINT_OPTIONS_FILE='/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_science_hamlib/hamlib/work/.CC_PRINT_OPTIONS' CFLAGS='-pipe -Os -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk -arch x86_64' CPATH='/opt/local/include' CPPFLAGS='-I/opt/local/include -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk' CXX='/usr/bin/clang++' CXXFLAGS='-pipe -Os -stdlib=libc++ -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk -arch x86_64' DEVELOPER_DIR='/Library/Developer/CommandLineTools' F90FLAGS='-pipe -Os -m64' FCFLAGS='-pipe -Os -m64' FFLAGS='-pipe -Os -m64' INSTALL='/usr/bin/install -c' LDFLAGS='-L/opt/local/lib -Wl,-headerpad_max_install_names -Wl,-syslibroot,/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk -arch x86_64' LIBRARY_PATH='/opt/local/lib' MACOSX_DEPLOYMENT_TARGET='10.14' OBJC='/usr/bin/clang' OBJCFLAGS='-pipe -Os -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk -arch x86_64' OBJCXX='/usr/bin/clang++' OBJCXXFLAGS='-pipe -Os -stdlib=libc++ -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk -arch x86_64' SDKROOT='/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk'
comment:15 Changed 3 years ago by RobK88
Replying to kencu:
Now you might need to compromise a bit; it is not trivial to run multiple different make sessions in one MacPorts build. It's just not set up that way. So can you live with just one of the python bindings? or have a variant for either python2 or python3?
Yes, I can live with Macports building hamlib with just the python 3 bindings. Better yet, update the hamlib port so one can choose between two the variants - hamlib with either the python2 bindings or the python3 bindings.
P.S. My initial approach was to build hamlib with just python3 bindings using python 3.9. I tried doing that by changing the "python" command from python 2 to python 3 (i.e. sudo port select --set python python39 ). That does not seem to work either using Macports or manually from source. It looks like Macports cannot find the symbols for "swig" when python 3 is being used. (In contrast, Macports can find the symbols for "swig" when python 2 is being used).
If you can figure out how to get Macports to build hamlib with python3 bindings that would be fantastic!
comment:16 Changed 3 years ago by kencu (Ken)
| Keywords: | Lion Hamlib removed |
|---|---|
| Owner: | changed from michaelld to ra1nb0w |
| Port: | hamlib added; swig swig-python removed |
| Summary: | swig fails test suite on Lion → hamlib @4.1: please enable python (and python3) bindings. |
| Type: | defect → request |
comment:17 Changed 3 years ago by Davide Gerhard <ra1nb0w@…>
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
comment:18 Changed 3 years ago by ra1nb0w
Now, you can install the python binding with
sudo port install hamlib +python37
comment:19 Changed 3 years ago by RobK88
Davide - Many thanks for all your work creating an updated portfile for Hamlib. But please reopen this ticket / bug report.
Yes, I can install hamlib with Python37 bindings on my Mac running Lion. So "sudo port install hamlib +python37" does work. Great progress!!
But When I try to install hamlib with Python 39 bindings on my Mac running Lion (i.e. "sudo port install hamlib +python39"), the compile fails at exactly the same point. Like before, it appears that the necessary symbols (or headers file?) for swig cannot be found.
$ sudo port clean hamlib ---> Cleaning hamlib Grinchs-Mac-Pro:~ grinch$ sudo port install hamlib +python39 ---> Computing dependencies for hamlib ---> Fetching distfiles for hamlib ---> Verifying checksums for hamlib ---> Extracting hamlib ---> Configuring hamlib ---> Building hamlib Error: Failed to build hamlib: command execution failed Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_hamlib/hamlib/main.log for details. Error: Follow https://guide.macports.org/#project.tickets to report a bug. Error: Processing of port hamlib failed
Here is the where the build fails:
CCLD _Hamlib.la
clang: warning: argument unused during compilation: '-pthread'
Undefined symbols for architecture x86_64:
"_PyArg_UnpackTuple", referenced from:
_SwigPyObject_own in hamlibpy_wrap.o
__wrap_rig_debug in hamlibpy_wrap.o
"_PyBool_FromLong", referenced from:
_SwigPyObject_richcompare in hamlibpy_wrap.o
_SwigPyObject_own in hamlibpy_wrap.o
"_PyBytes_AsStringAndSize", referenced from:
_SWIG_AsCharPtrAndSize in hamlibpy_wrap.o
"_PyCFunction_Type", referenced from:
_SWIG_PyInstanceMethod_New in hamlibpy_wrap.o
_SWIG_Python_ConvertFunctionPtr in hamlibpy_wrap.o
"_PyCMethod_New", referenced from:
_SWIG_PyInstanceMethod_New in hamlibpy_wrap.o
"_PyCapsule_GetPointer", referenced from:
_SWIG_Python_TypeQuery in hamlibpy_wrap.o
_SWIG_Python_DestroyModule in hamlibpy_wrap.o
"_PyCapsule_Import", referenced from:
_SWIG_Python_GetModule in hamlibpy_wrap.o
"_PyCapsule_New", referenced from:
_PyInit__Hamlib in hamlibpy_wrap.o
_SWIG_Python_TypeQuery in hamlibpy_wrap.o
"_PyDict_GetItem", referenced from:
_SWIG_Python_TypeQuery in hamlibpy_wrap.o
"_PyDict_New", referenced from:
_PyInit__Hamlib in hamlibpy_wrap.o
_SWIG_Python_TypeQuery in hamlibpy_wrap.o
_SWIG_Python_NewPointerObj in hamlibpy_wrap.o
"_PyDict_SetItem", referenced from:
_SWIG_Python_TypeQuery in hamlibpy_wrap.o
"_PyDict_SetItemString", referenced from:
_PyInit__Hamlib in hamlibpy_wrap.o
_SWIG_Python_SetConstant in hamlibpy_wrap.o
"_PyErr_Clear", referenced from:
_SWIG_Python_ConvertPtrAndOwn in hamlibpy_wrap.o
_SWIG_Python_GetSwigThis in hamlibpy_wrap.o
_SWIG_Python_GetModule in hamlibpy_wrap.o
_SwigPyClientData_New in hamlibpy_wrap.o
_SWIG_AsVal_long in hamlibpy_wrap.o
_SWIG_AsVal_double in hamlibpy_wrap.o
_SWIG_AsVal_unsigned_SS_long in hamlibpy_wrap.o
...
"_PyErr_Fetch", referenced from:
_SwigPyObject_dealloc in hamlibpy_wrap.o
_SWIG_Python_RaiseOrModifyTypeError in hamlibpy_wrap.o
"_PyErr_Format", referenced from:
_swig_varlink_getattr in hamlibpy_wrap.o
_swig_varlink_setattr in hamlibpy_wrap.o
_SWIG_Python_UnpackTuple in hamlibpy_wrap.o
"_PyErr_GivenExceptionMatches", referenced from:
_SWIG_Python_RaiseOrModifyTypeError in hamlibpy_wrap.o
"_PyErr_Occurred", referenced from:
_SWIG_Python_ConvertPtrAndOwn in hamlibpy_wrap.o
_SWIG_Python_GetSwigThis in hamlibpy_wrap.o
_SWIG_Python_GetModule in hamlibpy_wrap.o
_swig_varlink_getattr in hamlibpy_wrap.o
_swig_varlink_setattr in hamlibpy_wrap.o
_SwigPyClientData_New in hamlibpy_wrap.o
_SWIG_AsVal_long in hamlibpy_wrap.o
...
"_PyErr_Restore", referenced from:
_SwigPyObject_dealloc in hamlibpy_wrap.o
_SWIG_Python_RaiseOrModifyTypeError in hamlibpy_wrap.o
"_PyErr_SetString", referenced from:
_PyInit__Hamlib in hamlibpy_wrap.o
_Swig_var_hamlib_version_set in hamlibpy_wrap.o
_Swig_var_hamlib_copyright_set in hamlibpy_wrap.o
_Swig_var_debugmsgsave_set in hamlibpy_wrap.o
_SwigPyObject_append in hamlibpy_wrap.o
__wrap_confparams_token_set in hamlibpy_wrap.o
__wrap_confparams_token_get in hamlibpy_wrap.o
...
"_PyErr_WriteUnraisable", referenced from:
_SwigPyObject_dealloc in hamlibpy_wrap.o
"_PyExc_AttributeError", referenced from:
_Swig_var_hamlib_version_set in hamlibpy_wrap.o
_Swig_var_hamlib_copyright_set in hamlibpy_wrap.o
_swig_varlink_getattr in hamlibpy_wrap.o
_swig_varlink_setattr in hamlibpy_wrap.o
_SwigPyPacked_TypeOnce.tmp in hamlibpy_wrap.o
"_PyExc_IOError", referenced from:
_SwigPyPacked_TypeOnce.tmp in hamlibpy_wrap.o
"_PyExc_IndexError", referenced from:
_SwigPyPacked_TypeOnce.tmp in hamlibpy_wrap.o
"_PyExc_MemoryError", referenced from:
_SwigPyPacked_TypeOnce.tmp in hamlibpy_wrap.o
"_PyExc_OverflowError", referenced from:
_SwigPyPacked_TypeOnce.tmp in hamlibpy_wrap.o
"_PyExc_RuntimeError", referenced from:
_Swig_var_debugmsgsave_set in hamlibpy_wrap.o
__wrap_confparams_token_set in hamlibpy_wrap.o
__wrap_confparams_token_get in hamlibpy_wrap.o
__wrap_confparams_name_get in hamlibpy_wrap.o
__wrap_confparams_label_get in hamlibpy_wrap.o
__wrap_confparams_tooltip_get in hamlibpy_wrap.o
__wrap_confparams_dflt_get in hamlibpy_wrap.o
...
"_PyExc_SyntaxError", referenced from:
_SwigPyPacked_TypeOnce.tmp in hamlibpy_wrap.o
"_PyExc_SystemError", referenced from:
_SWIG_Python_UnpackTuple in hamlibpy_wrap.o
_SwigPyPacked_TypeOnce.tmp in hamlibpy_wrap.o
"_PyExc_TypeError", referenced from:
_PyInit__Hamlib in hamlibpy_wrap.o
_SwigPyObject_append in hamlibpy_wrap.o
__wrap_rig_set_debug_file in hamlibpy_wrap.o
_SWIG_Python_UnpackTuple in hamlibpy_wrap.o
_SWIG_Python_RaiseOrModifyTypeError in hamlibpy_wrap.o
_SwigPyPacked_TypeOnce.tmp in hamlibpy_wrap.o
"_PyExc_ValueError", referenced from:
__wrap_confparams_u_c_combostr_set in hamlibpy_wrap.o
__wrap_channel_levels_set in hamlibpy_wrap.o
__wrap_rig_caps_level_gran_set in hamlibpy_wrap.o
__wrap_rig_caps_parm_gran_set in hamlibpy_wrap.o
__wrap_rig_caps_preamp_set in hamlibpy_wrap.o
__wrap_rig_caps_attenuator_set in hamlibpy_wrap.o
__wrap_rig_caps_chan_list_set in hamlibpy_wrap.o
...
"_PyExc_ZeroDivisionError", referenced from:
_SwigPyPacked_TypeOnce.tmp in hamlibpy_wrap.o
"_PyFloat_AsDouble", referenced from:
_SWIG_AsVal_double in hamlibpy_wrap.o
"_PyFloat_FromDouble", referenced from:
__wrap_confparams_u_n_min_get in hamlibpy_wrap.o
__wrap_confparams_u_n_max_get in hamlibpy_wrap.o
__wrap_confparams_u_n_step_get in hamlibpy_wrap.o
__wrap_value_t_f_get in hamlibpy_wrap.o
__wrap_freq_range_t_startf_get in hamlibpy_wrap.o
__wrap_freq_range_t_endf_get in hamlibpy_wrap.o
__wrap_channel_freq_get in hamlibpy_wrap.o
...
"_PyFloat_Type", referenced from:
_SWIG_AsVal_double in hamlibpy_wrap.o
"_PyImport_AddModule", referenced from:
_PyInit__Hamlib in hamlibpy_wrap.o
"_PyInstanceMethod_New", referenced from:
_SWIG_PyInstanceMethod_New in hamlibpy_wrap.o
"_PyList_Append", referenced from:
_SWIG_Python_AppendOutput in hamlibpy_wrap.o
"_PyList_New", referenced from:
__wrap_rig_caps_preamp_get in hamlibpy_wrap.o
__wrap_rig_caps_attenuator_get in hamlibpy_wrap.o
__wrap_rig_state_preamp_get in hamlibpy_wrap.o
__wrap_rig_state_attenuator_get in hamlibpy_wrap.o
_SWIG_Python_AppendOutput in hamlibpy_wrap.o
"_PyList_SetItem", referenced from:
__wrap_rig_caps_preamp_get in hamlibpy_wrap.o
__wrap_rig_caps_attenuator_get in hamlibpy_wrap.o
__wrap_rig_state_preamp_get in hamlibpy_wrap.o
__wrap_rig_state_attenuator_get in hamlibpy_wrap.o
_SWIG_Python_AppendOutput in hamlibpy_wrap.o
"_PyLong_AsDouble", referenced from:
_SWIG_AsVal_double in hamlibpy_wrap.o
"_PyLong_AsLong", referenced from:
_SWIG_AsVal_long in hamlibpy_wrap.o
"_PyLong_AsUnsignedLong", referenced from:
_SWIG_AsVal_unsigned_SS_long in hamlibpy_wrap.o
"_PyLong_AsUnsignedLongLong", referenced from:
_SWIG_AsVal_unsigned_SS_long_SS_long in hamlibpy_wrap.o
"_PyLong_FromLong", referenced from:
_PyInit__Hamlib in hamlibpy_wrap.o
__wrap_confparams_token_get in hamlibpy_wrap.o
__wrap_confparams_type_get in hamlibpy_wrap.o
__wrap_value_t_i_get in hamlibpy_wrap.o
__wrap_value_t_b_l_get in hamlibpy_wrap.o
__wrap_freq_range_t_modes_get in hamlibpy_wrap.o
__wrap_freq_range_t_low_power_get in hamlibpy_wrap.o
...
"_PyLong_FromSize_t", referenced from:
_PyInit__Hamlib in hamlibpy_wrap.o
__wrap_freq_range_t_vfo_get in hamlibpy_wrap.o
__wrap_freq_range_t_ant_get in hamlibpy_wrap.o
__wrap_channel_vfo_get in hamlibpy_wrap.o
__wrap_channel_ant_get in hamlibpy_wrap.o
__wrap_channel_tx_vfo_get in hamlibpy_wrap.o
__wrap_channel_ctcss_tone_get in hamlibpy_wrap.o
...
"_PyLong_FromUnsignedLongLong", referenced from:
_PyInit__Hamlib in hamlibpy_wrap.o
__wrap_freq_range_t_modes_get in hamlibpy_wrap.o
__wrap_tuning_step_list_modes_get in hamlibpy_wrap.o
__wrap_filter_list_modes_get in hamlibpy_wrap.o
__wrap_channel_mode_get in hamlibpy_wrap.o
__wrap_channel_tx_mode_get in hamlibpy_wrap.o
__wrap_channel_funcs_get in hamlibpy_wrap.o
...
"_PyLong_FromVoidPtr", referenced from:
_SwigPyObject_long in hamlibpy_wrap.o
"_PyModule_AddObject", referenced from:
_PyInit__Hamlib in hamlibpy_wrap.o
"_PyModule_Create2", referenced from:
_PyInit__Hamlib in hamlibpy_wrap.o
"_PyModule_GetDict", referenced from:
_PyInit__Hamlib in hamlibpy_wrap.o
"_PyObject_Call", referenced from:
_SWIG_Python_NewPointerObj in hamlibpy_wrap.o
"_PyObject_CallFunctionObjArgs", referenced from:
_SWIG_Python_ConvertPtrAndOwn in hamlibpy_wrap.o
_SwigPyObject_dealloc in hamlibpy_wrap.o
"_PyObject_Free", referenced from:
_PyInit__Hamlib in hamlibpy_wrap.o
_SwigPyObject_dealloc in hamlibpy_wrap.o
_SwigPyPacked_dealloc in hamlibpy_wrap.o
"_PyObject_GenericGetAttr", referenced from:
_SwigPyObject_TypeOnce.tmp in hamlibpy_wrap.o
_SwigPyPacked_TypeOnce.tmp in hamlibpy_wrap.o
"_PyObject_GetAttr", referenced from:
_SWIG_Python_GetSwigThis in hamlibpy_wrap.o
"_PyObject_GetAttrString", referenced from:
_SwigPyClientData_New in hamlibpy_wrap.o
"_PyObject_IsInstance", referenced from:
_SwigPyClientData_New in hamlibpy_wrap.o
"_PyObject_IsTrue", referenced from:
_SwigPyObject_own in hamlibpy_wrap.o
"_PyObject_SetAttr", referenced from:
_SWIG_Python_NewPointerObj in hamlibpy_wrap.o
_SWIG_Python_InitShadowInstance in hamlibpy_wrap.o
"_PyTuple_GetSlice", referenced from:
__wrap_rig_debug in hamlibpy_wrap.o
"_PyTuple_New", referenced from:
_SWIG_Python_NewPointerObj in hamlibpy_wrap.o
_SwigPyClientData_New in hamlibpy_wrap.o
"_PyTuple_SetItem", referenced from:
_SwigPyClientData_New in hamlibpy_wrap.o
"_PyTuple_Size", referenced from:
__wrap_rig_debug in hamlibpy_wrap.o
"_PyType_IsSubtype", referenced from:
_SWIG_PyInstanceMethod_New in hamlibpy_wrap.o
_SWIG_AsVal_double in hamlibpy_wrap.o
_SWIG_Python_ConvertFunctionPtr in hamlibpy_wrap.o
"_PyType_Ready", referenced from:
_PyInit__Hamlib in hamlibpy_wrap.o
_SwigPyObject_type in hamlibpy_wrap.o
_SwigPyPacked_dealloc in hamlibpy_wrap.o
"_PyType_Type", referenced from:
_SwigPyClientData_New in hamlibpy_wrap.o
"_PyUnicode_AsUTF8String", referenced from:
_SWIG_AsCharPtrAndSize in hamlibpy_wrap.o
"_PyUnicode_Concat", referenced from:
_swig_varlink_str in hamlibpy_wrap.o
_SwigPyObject_repr in hamlibpy_wrap.o
"_PyUnicode_DecodeUTF8", referenced from:
_PyInit__Hamlib in hamlibpy_wrap.o
_Swig_var_hamlib_version_get in hamlibpy_wrap.o
_Swig_var_hamlib_copyright_get in hamlibpy_wrap.o
_Swig_var_debugmsgsave_get in hamlibpy_wrap.o
__wrap_confparams_name_get in hamlibpy_wrap.o
__wrap_confparams_label_get in hamlibpy_wrap.o
__wrap_confparams_tooltip_get in hamlibpy_wrap.o
...
"_PyUnicode_FromFormat", referenced from:
_SwigPyObject_repr in hamlibpy_wrap.o
_SwigPyPacked_repr in hamlibpy_wrap.o
_SwigPyPacked_str in hamlibpy_wrap.o
_SWIG_Python_RaiseOrModifyTypeError in hamlibpy_wrap.o
"_PyUnicode_FromString", referenced from:
_PyInit__Hamlib in hamlibpy_wrap.o
_SWIG_Python_GetSwigThis in hamlibpy_wrap.o
_SWIG_Python_TypeQuery in hamlibpy_wrap.o
_SWIG_Python_NewPointerObj in hamlibpy_wrap.o
_swig_varlink_str in hamlibpy_wrap.o
_SWIG_Python_DestroyModule in hamlibpy_wrap.o
_SwigPyPacked_str in hamlibpy_wrap.o
...
"_PyUnicode_InternFromString", referenced from:
_swig_varlink_repr in hamlibpy_wrap.o
_swig_varlink_str in hamlibpy_wrap.o
"_Py_DecRef", referenced from:
_swig_varlink_str in hamlibpy_wrap.o
_SwigPyObject_repr in hamlibpy_wrap.o
"__PyObject_New", referenced from:
_PyInit__Hamlib in hamlibpy_wrap.o
_SWIG_Python_NewPointerObj in hamlibpy_wrap.o
_SwigPyObject_New in hamlibpy_wrap.o
"__Py_Dealloc", referenced from:
_PyInit__Hamlib in hamlibpy_wrap.o
_SWIG_Python_SetConstant in hamlibpy_wrap.o
_SWIG_AsCharPtrAndSize in hamlibpy_wrap.o
_SWIG_Python_ConvertPtrAndOwn in hamlibpy_wrap.o
_SWIG_Python_GetSwigThis in hamlibpy_wrap.o
_SWIG_Python_TypeQuery in hamlibpy_wrap.o
_SWIG_Python_NewPointerObj in hamlibpy_wrap.o
...
"__Py_NoneStruct", referenced from:
_PyInit__Hamlib in hamlibpy_wrap.o
_Swig_var_hamlib_version_get in hamlibpy_wrap.o
_Swig_var_hamlib_copyright_get in hamlibpy_wrap.o
_Swig_var_debugmsgsave_get in hamlibpy_wrap.o
_SWIG_Python_ConvertPtrAndOwn in hamlibpy_wrap.o
_SWIG_Python_NewPointerObj in hamlibpy_wrap.o
_SwigPyObject_disown in hamlibpy_wrap.o
...
"__Py_NotImplementedStruct", referenced from:
_SwigPyObject_richcompare in hamlibpy_wrap.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [_Hamlib.la] Error 1
make[2]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_hamlib/hamlib/work/hamlib-4.1/bindings'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_hamlib/hamlib/work/hamlib-4.1/bindings'
make: *** [all-recursive] Error 1
make: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_hamlib/hamlib/work/hamlib-4.1'
Command failed: cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_hamlib/hamlib/work/Hamlib-4.1" && /usr/bin/make -j4 -w all
Exit code: 2
Error: Failed to build hamlib: command execution failed
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_hamlib/hamlib/main.log for details.
Error: Follow https://guide.macports.org/#project.tickets to report a bug.
Error: Processing of port hamlib failed
I will attach main.log
Ken or Davide -- Can you build and install hamlib with python39 bindings on your Mac running Lion? (i.e. what happens when you try "sudo port install hamlib +python39" ?)
If you are able to install Hamlib with Python39 bindings on your Mac running Lion then there is something strange with the configuration of Macports on my Mac running Lion. I might need to uninstall Macports and reinstall Macports from scratch.
Changed 3 years ago by RobK88
| Attachment: | main.2.log added |
|---|
main.log after running "sudo port install hamlib +python39"
comment:20 Changed 3 years ago by ra1nb0w
The problem lies in the check at line https://github.com/Hamlib/Hamlib/blob/c6608569fcd07895d2a1a8f523b8851fd55e3957/configure.ac#L582
You should report the problem to hamlib developers.
Then feel free to report back the solution. thank you.
comment:21 Changed 3 years ago by RobK88
Here is a summary of my tests of the Hamlib variants on Lion (10.7.5):
hamlib WORKS! hamlib+python27 WORKS! hamlib+python37 WORKS! hamlib+python38 FAILS TO BUILD :-( hamlib+python39 FAILS to BUILD :-(
comment:22 Changed 3 years ago by RobK88
Thanks Davide.
I will report this issue to the Michael Black (one of the main hamlib developers) and to the hamlib developers mailing list. I will let you know what I hear.
comment:24 Changed 3 years ago by RobK88
After more testing, I can confirm that Hamlib with python 3.9 bindings will compile manually on the Mac if the following lines are removed (or commented out) in configure.ac:
dnl Determine whether to link libpython as it is unneeded for Python >= 3.8
## AM_PYTHON_CHECK_VERSION([${PYTHON}], [3.8], [pyver_3_8="yes"], [pyver_3_8="no"])
## AS_IF([test x"${pyver_3_8}" = "xyes"],[
## PYTHON_LIBS=""
## ])
py3test.py also runs fine! So it works!
P.S. If one manually changes configure.ac with a text editor, the following commands are needed to compile Hamlib with python3.9 bindings:
autoreconf --install ./configure --with-python-binding --prefix=/usr/local make sudo make install
To run the self-tests for Hamlib with python bindings, just execute the following command:
PYTHONPATH=/usr/local/lib/python3.9/site-packages:$PYTHONPATH python bindings/py3test.py
I did not test building Hamlib with Python3.8 bindings using the updated configure.ac. But given the changes to configure.ac, I am sure it will also build fine.
Of course building Hamlib manually and using PYTHONPATH is NOT the preferred way to go for Macports' users.
I have submitted an Bug Report with the proposed fix to the Hamlib developers. I am hoping that they will update the source code for Hamlib accordingly.
comment:25 Changed 3 years ago by kencu (Ken)
Well done -- looks like we've hit a home run here <https://github.com/Hamlib/Hamlib/commit/da46e7cbdffd42675b85b96315a82f477bbec4f1> and I hope you can see that modifying Portfiles is quite simple once you get going!
Ken (VA7CUN)
comment:26 Changed 3 years ago by ra1nb0w
Ok. Now should work fine. Can you confirm RobK88? thank you for your tests and effort.
comment:27 Changed 3 years ago by RobK88
Ken and Davide -- Thanks for all your help!
Yes I can confirm that the Hamlib portfile does build hamlib with python 3.9 bindings. Best of all, I no longer have to use the PYTHONPATH environment variable!
hamlib WORKS! hamlib+python27 WORKS! hamlib+python37 WORKS! hamlib+python38 WORKS! hamlib+python39 WORKS!
You may be wondering why I needed Hamlib with python 3 bindings. I am trying to get PyQSO, a ham radio logginbg program, to run. (see https://github.com/ctjacobs/pyqso ) Hamlib with Python 3 bindings is needed if you want the pyQSO to automatically read the frequency and mode from your connected radio.
Most of the python dependencies are available on Macports but some are currently broken like py39-numpy (but the fix is in the works apparently). Once py39-numpy get fixed, I suspect (and hope) that the other broken dependencies will work!
Even with the broken and missing dependencies, pyQSO works pretty well right now. One can add, delete and edit contacts (or QSOs). And the DXCluster client works. But the world map does not work nor does some of the stats. These features should work once the various ports on Macports get fixed and once one adds the missing dependencies manually.
PyQSO Dependencies:
Basic Dependencies (Available on Macports)
Python39 py39-gobject3 py39-cairo py39-cairocffi py39-sphinx gtk3 adwaita-icon-theme
hamlib+python39
Might also need -- xorg-libxcb
Broken Dependencies on Macports (Needed for World Map)
py39-numpy py39-matplotlib py39-cartopy py39-scipy
Missing Dependencies (Install via pip3 or via source or create portfile!)
geocoder (see https://pypi.org/project/geocoder/#files )
geocoder Dependencies (Available on Macports)
py39-click py39-requests py39-six py39-future
Missing geocoder Dependencies (Install via pip3 or via source or create portfile!)
ratelim (see https://pypi.org/project/ratelim/#files )
ratelim Dependencies (Available on Macports)
py39-decorator
BOTTOM LINE:
Need to pray that the dependencies available on Macports that are currently broken get fixed and will need to create port files (or build from source manually) the following:
ratelim geocoder pyqso
I am still trying to figure out how to create working portfiles for Macports. Eventually I will get there.
73s
Rob VA2FB
comment:28 Changed 3 years ago by ra1nb0w
Why don't you use python 3.8 or python 3.7?
For GTK3 you can also use native quartz variant. To use it globally (suggested) put -x11 +no_x11 +quartz on /opt/local/etc/macports/variants.conf
ratelim and geocoder are available in macports.
I am generally use macloggerDX but pyqso seems interesting.
comment:29 Changed 3 years ago by kencu (Ken)
FYI using +quartz on 10.7 can put some demands on the system SDK that bring out build failures.
For +quartz builds, people who write the software often assume newer macOS SDK features as well.
So if you try that and run into trouble, you'll know why. Just go back to x11 if you need to.
comment:30 Changed 3 years ago by RobK88
Davide and Ken -- Thanks for all the input.
Yes one could use python 3.7 or 3.8. I just assumed that python 3.9 was better.
And yes geocoder is in Macports (py-pygeocoder) but I cannot find ratelim. Where is it?
$ port search ratelim No match for ratelim found
Maybe ratelim is not available in Macports for users on Lion?
If you use MacLoggerDX, I doubt you will like PyQSO. MacLoggerDX is probably the best logging program on the Mac. Followed by RumLog (Freeware) and Aether. P.S. Rumlog has a couple of big advantages. It is FREE! And RumLog2Go is available on iOS (for less than $10) and easily syncs with RumLog running on the Mac. So if you want to try another logging program for the Mac, you should check out RumLog. (See https://dl2rum.de/rumsoft/RUMLog.html )
But I was looking for a truly cross platform logging program since I use different OS's. They are only a few options:
jLog
KLog
pyQSO
XLog
jLog is a java program and works well. It is still being developed! But you need a free registration code to unlock it. I still am waiting to get the code from the developer!
KLog works great on Linux but is buggy on the Mac. The UI does not properly refresh on the Mac. It looks like no one has tested it on the Mac :-( (see https://www.klog.xyz/ )
pyQSO appears to work great on the Mac and Linux. But development stopped a couple of years ago. (See https://github.com/ctjacobs/pyqso )
XLog is a pretty good program and is actively being developed but it does NOT use a database engine (like sqlite or MariaDB etc). XLog just writes to a text file. I suspect the performance will be poor with a large logbook. XLog is in Macports! But the port is really outdated. It is better to download the source. I should file a ticket asking that the port be updated to pull the latest release.
So it looks like pyQSO is one of the better choices for a cross platform logging program right now. But it will never compete with a logging program designed to run on one OS like MacLoggerDX, RumLog or Aether.
comment:31 Changed 3 years ago by ra1nb0w
ratelim: strange, it is upstream https://github.com/macports/macports-ports/commit/ecc81eb06eae1c6e8717b8daf2e1e75f5853004c
Have you synced?
xlog: updated to 2.0.22 with application bundle.
Since pyQSO is not updated I avoid to add it to macports.
I know RUMLog but not that can be synced with iOS. Nice option. Thank you.
comment:32 Changed 3 years ago by RobK88
Thanks for the info. I am all synced up. But I uninstalled Xlog 2.0.14 using Macports a couple of weeks ago and installed XLog 2.0.22 form source (using ./configure, make, sudo make install) to get the latest fixes and cty.dat file.
So I will uninstall XLog manually and reinstall it but this time I will use Macports! :-)
I am still playing around with pyQSO. I will likely need to fork it and change the source code when I find the time. I really hate how one enters QSO's. It needs better options to set defaults (e.g. add the option to use values from the last entered QSO). I really hate reentering the same data over and over again. Needless typing. If I fork it and fix any bugs I see, I will let you know.
P.S. You can use RumLog2Go on iOS with MacLoggerDX. But you will need to export and EMAIL the log in ADIF format from RumLog and import it manually into MacLoggerDX.
73s
Rob VA2FB
comment:33 Changed 3 years ago by ra1nb0w
The sync must be seamless like iCloud and the MacLoggerDX solution for iOS (MacLoggerDX HD for iPad) is too expensive in my opinion.
Have a great QSOs ;-)
comment:34 Changed 3 years ago by RobK88
Yes the software from Dog Park Software is very pricey. I tell new hams who are in the Apple world to use the free RumLogNG for the Mac and the $6.99 CAD RumLog2Go for iOS. It is fantastic combo with iCloud syncing. I find it hard to justify spending a lot more money for the MacLogger DX and MacLoggerDX for iPad combo -- especially for new hams.
P.S. If you are ever looking for a good logging program for Linux. CQRLog is by far the best. It is also free. It is a pity that it will not run on the Mac.
73s Rob
comment:35 follow-up: 36 Changed 3 years ago by ra1nb0w
RumLogNG: I will give a try.
CQRLog: on macOS 10.14 it builds and runs installing sudo port install lazarus. I am not sure that latest version of lazarus/free-pascal work on 10.7.
To build lazbuild --ws=cocoa --pcp=.lazarus src/cqrlog.lpi or using Carbon lazbuild --ws=carbon --pcp=.lazarus src/cqrlog.lpi. But you need to patch src/lnet/lib/lclnet.pas adding
{$ifdef LCLCARBON}
{$i lclgtkeventer.inc} // identical code ;)
{$endif}
{$ifdef LCLCOCOA}
{$i lclgtkeventer.inc} // identical code ;)
{$endif}
at the end (before the last end). I am not sure that it works fine.
comment:36 Changed 3 years ago by kencu (Ken)
Replying to ra1nb0w:
RumLogNG: I will give a try.
CQRLog: on macOS 10.14 it builds and runs installing
sudo port install lazarus. I am not sure that latest version of lazarus/free-pascal work on 10.7.
They actually do, but ours has a 10.9 dep target set in it, that I (up to now) manually change to 10.7 when I build it. 10.6 too I think -- have to double check there.
comment:37 follow-up: 38 Changed 3 years ago by ra1nb0w
Do you mean in the Portfile? I don't see any "block". You can always open a new ticket to fix this.
comment:38 Changed 3 years ago by kencu (Ken)
Replying to ra1nb0w:
Do you mean in the Portfile? I don't see any "block".
You can always open a new ticket to fix this.
I could ... but as I'm the one who will fix it, I have never bothered :>
comment:39 Changed 3 years ago by ra1nb0w
Or you can discuss the problem privately with the maintainer karl-michael.schindler
Maybe there are many others people that can find it useful.
comment:40 Changed 3 years ago by kencu (Ken)
I know Karl. We've been working on this together for several years now. For some reason I never bothered to add myself as maintainer, as he was doing such a nice job. But he doesn't use any older systems. I'll fix it tomorrow I think; still trying to get clang-devel running on 10.6 & 10.7 first.
comment:41 Changed 3 years ago by ra1nb0w
Unfortunately, I can't help with old systems since I have only my laptop with macOS 10.14
comment:42 Changed 3 years ago by RobK88
That is great news that it may be possible to build CQRLOg on newer Macs! I do hope it can also be built on older Macs like Lion. But that might be a big ask.
I thought it was not possible to build CQRLog on the Mac especially after reading the thread on the CQRLog forums discussing porting CQRLog to the Mac.
Please read: https://www.cqrlog.com/node/176
If you are able to actually get CQRLog to build and run fine on the Mac, albeit on newer Macs only at this time, it would be great if CQRLog was added to Macports.
P.S. I tried to install Lazarus on this Mac running Lion. But it failed when it tried to build "fpc". But it sounds like you already know about the "fpc" problem on older Macs.
comment:43 Changed 3 years ago by ra1nb0w
It builds and starts fine using Cocoa on macOS 10.14 but I haven't installed mariadb or tested more. The only fix needed is on src/lnet/lib/lclnet.pas (as I said).
You can try to patch yourself the fpc file as shown by kencu
comment:44 Changed 3 years ago by RobK88
By the way, I am no longer able to install XLog on my Mac running Lion via Macports.
It fails when it tries to install one of the dependencies -- aom. "aom @3.0.0: Failed to fetch aom: Git clone failed -- self signed certificate in certificate chain"
See https://trac.macports.org/ticket/62596
$ sudo port -v install xlog ---> Computing dependencies for aom. ---> Fetching distfiles for aom Cloning into '/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_multimedia_aom/aom/work/aom-3.0.0'... fatal: unable to access 'https://aomedia.googlesource.com/aom.git/': SSL certificate problem: self signed certificate in certificate chain Command failed: /opt/local/bin/git clone --progress https://aomedia.googlesource.com/aom.git /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_multimedia_aom/aom/work/aom-3.0.0 2>&1 Exit code: 128 Error: Failed to fetch aom: Git clone failed Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_multimedia_aom/aom/main.log for details. Error: Problem while installing aom Error: Unable to execute port: upgrade librsvg failed
It looks like others cannot reproduce this git related error.
Ken do you have the same problem installing or upgrading "aom" on your Mac running Lion?
P.S. By the way here is the version of git installed on my Mac:
port installed git The following ports are currently installed: git @2.31.1_0+credential_osxkeychain+diff_highlight+doc+pcre+perl5_28 (active)
comment:45 Changed 3 years ago by ra1nb0w
Maybe you can try to use curl-ca-bundle or, in the second instance, certsync to create/manage the certification chain
comment:46 Changed 3 years ago by RobK88
Thanks. I found the problem and a workaround. Then I found another problem :-(
The problem with Macs running an old OS, like Lion, is the lack of SSL 1.2 support. So I installed an SSL proxy server using squid. (see https://forums.macrumors.com/threads/fixing-https-issues-on-old-versions-of-os-x.2281326/)
To make the SSL proxy server work, I need to use a self signed cert.
When I disable the SSL Proxy, the port for aom can use git to clone the aom repo and install the port. SO the workaround for now is to disable the SSL Proxy.
P.S. Here is the strange part. When the SSL proxy server is enabled, I can use git on the command line to clone the aom repo!
$ git clone https://aomedia.googlesource.com/aom.git Cloning into 'aom'... remote: Finding sources: 100% (43/43) remote: Total 233843 (delta 186494), reused 233818 (delta 186494) Receiving objects: 100% (233843/233843), 295.25 MiB | 3.89 MiB/s, done. Resolving deltas: 100% (186494/186494), done.
The git clone only fails when Macports tries to clone the repo. Strange. If you know of a better solution that disabling the SSL Proxy, please let me know.
In any event, once I disable my SSL proxy server and install aom via Macports, I still cannot install XLog.
sudo port install xlog ---> Computing dependencies for rust ---> Fetching distfiles for rust Error: rust is only supported on macOS 10.10 or later. Error: Failed to fetch rust: unsupported platform version Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_rust/rust/main.log for details. Error: Problem while installing rust Error: Unable to execute port: upgrade librsvg failed
Looks like rust is now only supported on Yosemite and higher. This is will likely break many ports on the older Macs.. :-(
I filed a ticket -- https://trac.macports.org/ticket/62614
comment:47 Changed 3 years ago by kencu (Ken)
I use a new copy of curl installed into /opt/bootstrap, and then build macports against that using the --with-curlprefix=/opt/bootstrap option. I've been doing this since 2016 on all my systems older than 10.10, so everything MacPorts "just works" for me (git, perl, all the downloads are fine, on Tiger on up).
Marcus added many deps to libheif due to opportunistic linking on newer systems, but most (all?) of them don't build on older systems, so I just reverted that commit locally while I sort out what to fix and when.
comment:48 Changed 3 years ago by RobK88
Thanks Ken for the info. For new installations of Macports on older Mac OS's, I can see why one would need to build Macports directly from source using "--with-curlprefix=/opt/bootstrap".
Unless I am missing something, I do not see how that would help an old Macports installation like mine where I was able to install the latest version of curl using Macports.
But if I ever have to reinstall Macports on this old Mac, I definitively will do as you suggest -- build curl from source and install curl into /opt/bootstrap and build Macports from source using "--with-curlprefix=/opt/bootstrap".
You mentioned that you "reverted that commit locally". Is there an easy way to do that with Macports. Unlike other package managers, I do not see an easy way to hold back a package from upgrading. So I typically have to wait until packages get fixed.
comment:49 Changed 3 years ago by kencu (Ken)
MacPorts is exceptionally flexible. You can do almost anything you can think of.
For example, I keep customized Repo overlays for all my older systems. Here's the current Lion one: <https://github.com/kencu/LionPorts>
<https://guide.macports.org/chunked/development.local-repositories.html>
comment:50 Changed 3 years ago by RobK88
Thanks! I see what you are doing. I didn't realize that local ports take precedence over ports stored on the rsync servers on the internet even if the ports on the rsync servers on the internet are newer versions!
That is very helpful! I will setup my own local repos for ports I would like to keep back. And I will start creating and testing my own portfiles for some applications that I always wanted in Macports.
the likely problem is that MacPorts has put the software you need in
/opt/local/, but no compilers will look there by default. They look instead in/usr/localand then/usr.So this is both the greatest and the worst thing about MacPorts, and it is why homebrew became popular in the first place I believe. Homebrew puts symlinks to most everything it installs into
/usr/local, so things like what you are trying to do "just work". The downside is that these installed files are used whether you want them to be or not, which can cause troubles.The easiest way out of this situation for the long term is to take a couple of minutes to learn how to modify Portfiles for your own use. It sounds like what you want to do is add a configuration argument to the hamlib that MacPorts already installs, that add this
--with-python-binding.So I am going to start by saying I don't know much about python or swig or hamlib. But I can usually make MacPorts run backflips. So I will show you how to do this. This will be long for clarity, but in actual use, takes me no more than a minute to really do.
I see there are several packages available on MacPorts related to swig and python, so I installed these, as I assume this should cover the needs:
Then we are going to modify the hamlib Portfile. First get rid of any hamlib you have intalled:
and clean up any leftover remnants:
now let's modify it. First we need to find it:
For this simple one, we will edit in place.
and we see there are two hamlib subports, hamlib, and a devel version. We will work on the hamlib port, which is the one below the "else". We are going to take this part:
} else { github.setup Hamlib Hamlib 4.1 github.tarball_from releases checksums rmd160 fd5e2c165c02de0b60a6af1ff812cb12dbc64de7 \ sha256 b4d4b9467104d1f316c044d002c4c8e62b9f792cbb55558073bd963203b32342 \ size 2260629 revision 0 conflicts hamlib-devel }and add your desired arguments like this:
} else { github.setup Hamlib Hamlib 4.1 github.tarball_from releases checksums rmd160 fd5e2c165c02de0b60a6af1ff812cb12dbc64de7 \ sha256 b4d4b9467104d1f316c044d002c4c8e62b9f792cbb55558073bd963203b32342 \ size 2260629 revision 0 configure.args-append --with-python-binding conflicts hamlib-devel }We then do:
and watching the build, everything looks good:
Hamlib Version 4.1 configuration: Prefix /opt/local Preprocessor /usr/bin/clang -E -I/opt/local/include -I/opt/local/include/LegacySupport C Compiler /usr/bin/clang -pipe -Os -I/opt/local/include/LegacySupport -arch x86_64 C++ Compiler /usr/bin/clang++ -pipe -Os -stdlib=libc++ -arch x86_64 Package features: With C++ binding no With Perl binding no With Python binding yes ...everything links without any errors (MacPorts has told the compiler where to find all the libraries).
Then we actually install it, using the "-s" option so we install the one we are building, not the binary from MacPorts buildbots:
And as it turns out, that is all you need to do to get what you want.
Then you test it, make sure it works.
Then for bonus points, you figure out exactly which of those swig bits you needed, add them to the build as "depends_lib-append", and generate a new variant perhaps, and then a PR. But that is tomorrow's lesson :>