pkgsrc-Users archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: compiling linrad under NetBSD
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.
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.
> 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.
> 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.
> ./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.
>
> 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.
> 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!
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.
73 de n1dam
Home |
Main Index |
Thread Index |
Old Index