pkgsrc-Users archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: compiling linrad under NetBSD
El 15/5/24 a las 0:49, Greg Troxel escribió:
Ramiro Aceves <ea1abz%gmail.com@localhost> writes:
Linrad is an X11 program by Leif Asbrink for use with SDR (Software
Defined Radios)
https://www.sm5bsz.com/linuxdsp/linrad.htm
https://www.sm5bsz.com/linuxdsp/archive/lir05-02.zip
As an amateur radio entusiast I am very interested in this piece of
sotfware. It is originally written for Linux and Windows (MinGW). I
have compiled under Linux with no effort over the years, it is written
for Linux and compiles out of the box without problems.
Has anybody had luck compiling it under NetBSD? I have seen that
FreeBSD has an outdated version port but only for amd64 and i386
only. It would be great to run this program in NetBSD, and in
particular in the RaspberryPi, for example, to be able to use the
radio receivers remotely.
I have tried to compile it myself in the RPi4 but I have not
succeeded. It uses the GNU ./configure autoconf programs but I cannot
pass the first steps.
There are going to be two categories of dealing with this, plus things I
am not guessing about.
The zeroth is to look in pkgsrc and wip, but it seems like you did and I
don't see it either.
Thanks for answering, Greg!
Yes, did not found anything in pkgsrc and wip. I am going to read
carefully all your hints and see if I can progress.
I have just written to Leif, the author of the program. We exchanged
many many emails about electronics and Ham Radio Earth Moon Earth in the
good old days. He is indeed a genius of electronics and radio
techniques. He was pionner in SDR and DSP techniques for receiving.
Linrad started at the MSDOS era. Hope he can give more hints and if
everything works incoporate NetBSD hints in the code.
I see that the CPU type detection fails in configure scripts, so I think
I have to start there. (also setterm command seems not to exist in NetBSD)
configure.ac:
AC_PREREQ(2.50)
AC_INIT(xmain.c)
AC_MSG_CHECKING([OS])
AC_CONFIG_FILES([Makefile])
AC_CONFIG_FILES([ft245.c])
BITS=`(getconf LONG_BIT)`
AC_SUBST(BITS)
setterm -term linux -back white
setterm -term linux -fore black
OS=`uname`
AC_SUBST(OS, "${OS}")
MACHINE=$(uname -m)
CPU="CPU_INTEL"
if test "$MACHINE" = "armv5l"; then
CPU="CPU_ARM"
fi
if test "$MACHINE" = "armv6l"; then
CPU="CPU_ARM"
fi
if test "$MACHINE" = "armv7l"; then
CPU="CPU_ARM"
fi
if test "$MACHINE" = "aarch64"; then
CPU="CPU_ARM"
fi
if test "$MACHINE" = "armv8l"; then
echo "The architecture is armv8l which should support 64 bit code."
echo "Please send a mail to me: <leif at sm5bsz.com>"
echo "I will send some test packages to figure out how to"
echo "add whatever might be needed to compile Linrad"
exit
CPU="CPU_ARM"
fi
if test "$MACHINE" = "arm64"; then
# Apple ARM64 architecture
CPU="CPU_ARM"
fi
AC_SUBST(CPU)
if test "$CPU" = "CPU_INTEL"; then
ASMLIB32='fftasm.ol getiq.ol fft2mmxa.ol fft2mmxb.ol fft2mmxc.ol
simdasm.ol hware.ol split.ol'
ASMLIB64='fftasm.om getiq.om fft2mmxa.om fft2mmxb.om fft2mmxc.om
simdasm.om split.om'
else
ASMLIB32="csplit.ol"
ASMLIB64="csplit.om"
fi
AC_SUBST(ASMLIB32)
AC_SUBST(ASMLIB64)
...
...
uname at NetBSD outputs this:
rpi4-netbsd$ uname
NetBSD
rpi4-netbsd$ uname -m
evbarm
So it do not work.
One is that it has dependencies, and you will have to
1) install them, probably via pkgsrc
2) tell the program to look for them, because /usr/pkg/include and
/usr/pkg/lib are not in the default paths
The general approach is something like
CPPFLAGS+=-I/usr/pkg/include
LDFLAGS+="-L/usr/pkg/lib -R/usr/pkg/lib"
The second is that you will have to fix various non-portable constructs,
which can range from easy to quite hard.
I imagined that :-(
rpi4-netbsd$ ./configure
"./configure --help" is useful
Not present: libusb-1.0.so (32bit) (./configure --with-libusb1-32)
Not present: libusb.so (32bit) (./configure --with-libusb0-32)
See pkgsrc/devel/libusb1.
ok
Not present: libvga.so (32bit) or headers (./configure --with-svgalib-32)
A larger hint written as an example:
> find . -name PLIST\* |xargs egrep /libvga
./wip/modular-xorg-server-dfbsd/PLIST:@comment lib/xorg/modules/libvgahw.la
./wip/modular-xorg-server-dfbsd/PLIST:lib/xorg/modules/libvgahw.so
./wip/compat80-x11/PLIST:emul/netbsd32/lib/modules/libvgahw.so
./wip/compat80-x11/PLIST:emul/netbsd32/lib/modules/libvgahw.so.0
./wip/modular-xorg-server-dfbsd-meson/PLIST:@comment lib/xorg/modules/libvgahw.la
./wip/modular-xorg-server-dfbsd-meson/PLIST:lib/xorg/modules/libvgahw.so
./wip/netbsd-x11-i386/PLIST:lib/modules/libvgahw.a
./wip/netbsd-x11-i386/PLIST:lib/modules/libvgahw.so
./wip/netbsd-x11-i386/PLIST:lib/modules/libvgahw.so.0
./wip/netbsd-x11-i386/PLIST:lib/modules/libvgahw_pic.a
./wip/svgalib/PLIST:etc/vga/libvga.config
./wip/svgalib/PLIST:etc/vga/libvga.et4000
./wip/svgalib/PLIST:lib/libvga.a
./wip/svgalib/PLIST:lib/libvga.so
./wip/svgalib/PLIST:lib/libvga.so.1
./wip/svgalib/PLIST:lib/libvgagl.a
./wip/svgalib/PLIST:lib/libvgagl.so
./wip/svgalib/PLIST:lib/libvgagl.so.1
./wip/svgalib/PLIST:man/man5/libvga.config.5
./wip/svgalib/PLIST:man/man5/libvga.et4000.5
./x11/modular-xorg-server/PLIST:lib/xorg/modules/libvgahw.la
Not present: libX11.so (32bit) or headers (./configure --with-x11-32)
Not present: libasound.so (32bit) (./configure --with-ALSA-32)
similar I suspect.
./configure: setterm: not found
Probably a linuxism in shell code in configure.ac. Read it, figure out
what it's doing and rewrite to be portable.
test: ==: unexpected operator
test: ==: unexpected operator
test: ==: unexpected operator
POSIX shell specifies = as the equality operator. It's been like that
since 1976. Bash made the poor decision to allow ==, I think to
accomodate people who were confused about C vs sh. This has led to many
scripts being written with == which is incorrect, and rejected by many
(most? all?) non-bash sh implementations. Just change the == to =, and
file a bug upstream.
Thanks!
./configure has problems with NetBSD /bin/test program. I have
installed GNU coreutils and changed manually the routes in .configure
script to /usr/pkg/gnu/bin/test to overcome that:
It's much better to just s/==/=/ and that's all it takes.
great
Not present: libwd_dask.so (32bit) (./configure --with-libwd_dask-32)
Not present: libperseus-sdr.so (32bit) (./configure --with-perseus-32)
Not present: libusb-1.0.so (32bit) (./configure --with-libusb1-32)
Not present: libusb.so (32bit) (./configure --with-libusb0-32)
Not present: libvga.so (32bit) or headers (./configure --with-svgalib-32)
Not present: libX11.so (32bit) or headers (./configure --with-x11-32)
Not present: libasound.so (32bit) (./configure --with-ALSA-32)
To generate servers (daemons) run ./configure --with-server
rpi4-netbsd$
./configure script finishes ok. I issued "make xlinrad64" but it seems
that it needs GNUMake.
So install it and type gmake.
after doing "gmake xlinrad64":
rpi4-netbsd$ gmake xlinrad64
cc -D_FILE_OFFSET_BITS=64 -DLUSERS_DEF=0 -DWUSERS_DEF=0 xmain.c
-DBUILD=0 -DHAVE_XKBLIB=0 \
-I/usr/include/ -O2 -DOSNUM=1 -I/usr/include/ -W -Wall -DHAVE_OSS=0
-DCPU=CPU_INTEL -DHAVE_SHM=0 -DHAVE_X11=0 -DIA64=1 -DDARWIN=0
-DSERVER=0 -DHAVE_SVGALIB=0 -DOPENCL_PRESENT=0 -DHAVE_CUFFT=0
-Wimplicit -Wreturn-type -Wformat -Wunused -Wcomment -DOSSD=0
-Wchar-subscripts -Wshadow -Wuninitialized -Wparentheses
-Wstrict-prototypes -Werror -ffast-math -Wundef -fomit-frame-pointer
-c -o xmain.om
xmain.c:50:10: fatal error: linux/fb.h: No such file or directory
50 | #include <linux/fb.h>
| ^~~~~~~~~~~~
compilation terminated.
gmake: *** [Makefile:2105: xmain.om] Error 1
rpi4-netbsd$
I removed #include <linux/fb.h> in xmain.c:
#ifndef __FreeBSD__
#if DARWIN == 0
#include <linux/fb.h>
#endif
#endif
#include <sys/mman.h>
#include <locale.h>
#include <sys/un.h>
Here, the fix is to extend the ifdef FreeBSD to also NetBSD, but here
it is probably best to replace with ifdef linux.
ok
Run again:
rpi4-netbsd$ gmake xlinrad64
In file included from /usr/include/ctype.h:100,
from xmain.c:37:
xmain.c: In function ‘main’:
xmain.c:220:14: error: array subscript has type ‘char’
[-Werror=char-subscripts]
220 | i=toupper(s[0]);
This is a common bug. toupper is defined by C99 to take an int, and it
can be the valid range of characters or -1. I think we generally cast
to int.
I removed "-Werror" everywhere in Makefile just to try and it starts
compiling for a while until it breaks after a minute or 2:
cc -D_FILE_OFFSET_BITS=64 -DLUSERS_DEF=0 -DWUSERS_DEF=0 lxsys.c
-DHAVE_PARPORT=0 -O2 -DOSNUM=1 -I/usr/include/ -W -Wall -DHAVE_OSS=0
-DCPU=CPU_INTEL -DHAVE_SHM=0 -DHAVE_X11=0 -DIA64=1 -DDARWIN=0
-DSERVER=0 -DHAVE_SVGALIB=0 -DOPENCL_PRESENT=0 -DHAVE_CUFFT=0
-Wimplicit -Wreturn-type -Wformat -Wunused -Wcomment -DOSSD=0
-Wchar-subscripts -Wshadow -Wuninitialized -Wparentheses
-Wstrict-prototypes -ffast-math -Wundef -fomit-frame-pointer -c -o
lxsys.om
lxsys.c:37:10: fatal error: machine/cpufunc.h: No such file or directory
37 | #include <machine/cpufunc.h>
| ^~~~~~~~~~~~~~~~~~~
compilation terminated.
gmake: *** [Makefile:2151: lxsys.om] Error 1
Probably another linuxism. Might need ifdefing same as FreeBSD.
I fixed with this:
#include "/usr/src/sys/arch/evbarm/include/cpufunc.h"
Hmm, I would not assume that is the same thing.
but now:
rpi4-netbsd$ gmake xlinrad64
cc -D_FILE_OFFSET_BITS=64 -DLUSERS_DEF=0 -DWUSERS_DEF=0 lxsys.c
-DHAVE_PARPORT=0 -O2 -DOSNUM=1 -I/usr/include/ -W -Wall -DHAVE_OSS=0
-DCPU=CPU_INTEL -DHAVE_SHM=0 -DHAVE_X11=0 -DIA64=1 -DDARWIN=0
-DSERVER=0 -DHAVE_SVGALIB=0 -DOPENCL_PRESENT=0 -DHAVE_CUFFT=0
-Wimplicit -Wreturn-type -Wformat -Wunused -Wcomment -DOSSD=0
-Wchar-subscripts -Wshadow -Wuninitialized -Wparentheses
-Wstrict-prototypes -ffast-math -Wundef -fomit-frame-pointer -c -o
lxsys.om
In file included from lxsys.c:37:
/usr/src/sys/arch/evbarm/include/cpufunc.h:3:10: fatal error:
arm/cpufunc.h: No such file or directory
3 | #include <arm/cpufunc.h>
| ^~~~~~~~~~~~~~~
compilation terminated.
gmake: *** [Makefile:2151: lxsys.om] Error 1
I tried to fix it but I entered in an endless loop of new compilation
problems. I definitely do not have enough knowledge to make it work. I
am starting thinking that this is a very complicated task. Please let
me know what you think about it, if you think there are chances to
make it work or it is a complete waste of time.
You have actually made a lot of progress, more than I guessed from the
first 10 lines of your message!
Blind progress without been expert in anything. Many things involved and
I am just a NetBSD user newbye. It will be hard, chances of success are
small. I will wait first for the advice of Leif, the author of Linrad
and see what happens.
The big point is that if someone has made it work on FreeBSD, it's
likely to be modifiable to work on NetBSD as well. If you are porting
to the first non-linux, it could be much harder.
Have you contacted upstream? Are they amenable to fixing portability
bugs and taking patches? If so, this seems sensible to work on. If
upstream is either non-responsive or disinterested in portability, then
it's going to be harder and less fun.
After you get this figured out, the next step is to add it to pkgsrc
which can wrap all these accomodations.
Good luck and it's great to have another ham working on NetBSD.
Yes, I see that you are also ham. Great endless hobby!
73, Ramiro, EA4NZ now (EA1ABZ before)
73 de n1dam
Home |
Main Index |
Thread Index |
Old Index