# New MSHV hamradio soft



## lu9dce (Jun 11, 2022)

Greetings to all
a few days ago the developer Christo, LZ2HV
amateur radio step your soft for freebsd
in version 13 it works perfectly
from the RC5 he communicated the following to me

But for new version of FreeBSD (13.1 RC5 and RC6) have a problem, I installed and tested, problem is,
Something is wrong with bound rates for com ports, B576000 and B1152000 not decelerated or not right defines in (13.1 RC5 and RC6)
PS. alarm for this problem developers off FreeBSD for new version.

and indeed it gives an error when compiling it

this program (MSHV) is very useful for radio amateurs and it would be nice to have it in the freebsd ports

I leave the link of the source code ... if anyone finds the problem
so you can deliver the code running perfectly to be able to include it in the port without patches



			https://sourceforge.net/projects/mshv/files/MSHV_265_Full_Source_Code.zip/download
		


report this ports error
maybe it's a general bug that influences others
programs... a review would be good... since even the version
from freebsd 13 rc4 worked perfect

thank you sorry for the inconvenience


----------



## sidetone (Jun 11, 2022)

Are you using FreeBSD 13.1-Release? (Not the RC versions). If not, upgrade to this first.

That, or test it on the last RC version that it worked on. Which dependencies or drivers/modules did it use then? Write them down. Then go back to FreeBSD 13.1-Release to see and work around the error message from that.

What are the error or warning messages?


----------



## lu9dce (Jun 11, 2022)

I have no way to test it in version 13
all my work computers are already on 13.1

This is the error that throws in the compilation

---------------

```
g++ -c -pipe -std=gnu++11 -ffast-math -fno-trapping-math -funsafe-math-optimizations -freorder-functions -funroll-all-loops -O2 -Wall -Wextra -pthread -fPIC -D_LINUX_ -DQESP_NO_UDEV -D__linux__ -D_FREEBSDHV_ -DQT_NO_DEBUG -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_WEBSOCKETS_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -I. -I/usr/local/include/qt5 -I/usr/local/include/qt5/QtWidgets -I/usr/local/include/qt5/QtGui -I/usr/local/include/qt5/QtWebSockets -I/usr/local/include/qt5/QtNetwork -I/usr/local/include/qt5/QtCore -Ibuild -I/usr/local/include -I/usr/local/include -I/usr/local/lib/qt5/mkspecs/freebsd-clang -o build/qextserialport_unix.o src/HvRigControl/qexsp_1_2rc/qextserialport_unix.cpp
src/HvRigControl/qexsp_1_2rc/qextserialport_unix.cpp: In member function 'void QextSerialPortPrivate::updatePortSettings()':
src/HvRigControl/qexsp_1_2rc/qextserialport_unix.cpp:320:50: error: 'B576000' was not declared in this scope; did you mean 'B57600'?
  320 |             setBaudRate2Termios(&currentTermios, B576000);
      |                                                  ^~~~~~~
      |                                                  B57600
src/HvRigControl/qexsp_1_2rc/qextserialport_unix.cpp:329:50: error: 'B1152000' was not declared in this scope; did you mean 'B115200'?
  329 |             setBaudRate2Termios(&currentTermios, B1152000);
      |                                                  ^~~~~~~~
      |                                                  B115200
*** Error code 1

Stop.
make: stopped in /tmp/MSHV_265
```


----------



## sidetone (Jun 11, 2022)

First, I was going to say, to try compiling it without `--fast-math`, `-funroll-all-loops` and other compiler optimizations. This can be set in /etc/make.confor in the source code. But, according to the error message, this isn't the problem, so this is fine.

Earlier RC versions of FreeBSD aren't needed. They were described, so I thought maybe there was something about them were they worked on it. It's irrelevant to go back to an unsupported RC version, bc the release is the version to solve it on. I thought that's what you or the developers were using. As long as it was being run, I asked how it ran on them.

It says the problem. Somewhere the bad rare is set to the wrong number. It has an extra zero, which should be B57600 and B115200.


```
rc/HvRigControl/qexsp_1_2rc/qextserialport_unix.cpp:320:50: error: 'B576000' was not declared in this scope; did you mean 'B57600'?
  320 |             setBaudRate2Termios(&currentTermios, B576000);
      |                                                  ^~~~~~~
      |                                                  B57600
src/HvRigControl/qexsp_1_2rc/qextserialport_unix.cpp:329:50: error: 'B1152000' was not declared in this scope; did you mean 'B115200'?
  329 |             setBaudRate2Termios(&currentTermios, B1152000);
      |                                                  ^~~~~~~~
      |                                                  B115200
```

In your description you had also described baud rates with an extra zero at the end.

This error may either be in the source code, or it could be a setting on your computer.


----------



## lu9dce (Jun 11, 2022)

yes i saw it and mark it in the error
but this is the code for both windows linux mac
and so it compiled in 13.0

I am not the developer.. I will try to see if I can correct this in the code

Thank you


----------



## lu9dce (Jun 11, 2022)

getting a 0 in the speed of the serial port works fine
the compilation
but at the end of the compilation we find this error

`/usr/local/bin/ld: build/q65_subs.o: undefined reference to symbol 'logf@@FBSD_1
.0'
/usr/local/bin/ld: /lib/libm.so.5: error al añadir símbolos: DSO faltante desde
línea de orden
collect2: error: ld returned 1 exit status
*** Error code 1`


----------



## jbo (Jun 11, 2022)

lu9dce said:


> thank you sorry for the inconvenience


No inconvenience at all! Firstly, because this is a support forum and secondly because having more software options available on FreeBSD is greatly desired!

I quickly compiled this on a stable/13 machine and had no problems with it after fixing the incorrect enum values as mentioned by @sidenote.

If you guys would like, I can make an official port out of this so you can simply `pkg install mshv` and you're done.


----------



## lu9dce (Jun 11, 2022)

ok in 13 it works fine even without fixing anything
the problem is in 13.1


----------



## jbo (Jun 11, 2022)

lu9dce said:


> ok in 13 it works fine even without fixing anything
> the problem is in 13.1


The problem is not the FreeBSD version itself but rather a mistake in the source code of MSHV as elaborated above.

What changes between FreeBSD versions is the underlying compiler. The QMake buildsystem files for FreeBSD are setup to use GCC (clang would be preferred). Most likely a different version of GCC is used between the different FreeBSD versions where "it works" vs. "doesn't work". Different versions of GCC can come with different default options on warning/error handling.

You may check (and post) the output of `gcc --version` on the different machines / FreeBSD versions.
I used gcc 11.3.0.


----------



## lu9dce (Jun 11, 2022)

gcc --version 
gcc (FreeBSD Ports Collection) 11.2.0

with gcc11 the same error

-------
did you manage to compile it in 13.1?


----------



## jbo (Jun 11, 2022)

lu9dce said:


> did you manage to compile it in 13.1?


Yes, as elaborated above by sidetone. It is an error in the source code. No matter whether it happens to compile under certain environments.

Also, as mentioned above, it would be very easy to create a FreeBSD port for this so you can just type `pkg install mshv` to get it installed like with other software you're using on FreeBSD. You'd no longer need to compile this manually on FreeBSD that way.


----------



## Phishfry (Jun 12, 2022)

lu9dce said:


> B1152000
> ^~~~~~~~


Modern compilers are really quite informative about errors. Surprised it caught this typo.
So error checking against libm.so by qextserialport_unix.cpp ?


----------



## lu9dce (Jun 12, 2022)

unfortunately not programming
I understand very well the issue of compiling
and realize some errors or lack of some
bookstore but already more than that escapes from the hands

this software (mshv) was asking the developer to do it for freebsd
until he finally did it... but he did it in version 13
which is perfect... when they started with the RCs in the rc5 I left
to be able to compile it .. so let me know

when I went to 13.1 I could realize that it wasn't working either

but effectively in 13 it works perfectly without modifying anything in the code

I really don't know what could be the problem

running the error showing the compiler compiles to the end which gives another libm.so.5 error

it is more if it is compiled in 13 and the binary is passed to 13.1 it does not work


----------



## lu9dce (Jun 13, 2022)

Bug is in FreeBSD 13.1, I alarm for this problem month ago ?????? (from you side zero reaction) ??????
solution, use this file for Interface control under the compilation
qextserialport_unix.cpp (from attachment)
In other side I compile 2.65 in FreeBSD 13.1
This is a binary file: MSHV_FreeBSD_amd64.zip (from attachment)

Problem is in FreeBSD 13.1 ->>>>>> /usr/include/sys/_termios.h  <<<<--  missing declarations for
---------------------------------------------------------------------------
#define B576000 576000
#define B1152000 1152000U
----------------------------------------------------------------------------


----------



## jbo (Jun 13, 2022)

In my opinion, these declarations are not missing. Those are non-standard baud rates. 57600 and 115200 are standard baud rates and they are also defined in /usr/include/sys/_termios.h. 576000 and 1152000 are not standard baud rates and are therefore also not defined as such.

As mentioned previously, this is most likely a simple case of having a typo in the MSHV source code. If you think otherwise, please provide evidence that 576000 and 1152000 are standard baud rates and/ior that those are missing in FreeBSD 13.1 but present in previous versions.


----------



## lu9dce (Jun 13, 2022)

Yes I understand
but they were defined in the 13
and they were removed in 13.1
which could generate an error in another software
that works on serial ports
I already reported it as a bug
since 13 and 13.1 share soft


----------



## sidetone (Jun 13, 2022)

Which source code has the extra zero in it? It needs to be grepped through, in both FreeBSD 13.1 and in the program sourcecode.

It's possible that other Operating systems compensated for an extra zero, and corrected it. In FreeBSD, it asked, "did you mean?" While the other OS's may have took their own action on that, and removed that zero. This needs to be checked first.

There could be an error in a combination of the OS and program, that it added an extra zero. I think it's the above though, that other OS's auto-corrected an error in the sourcecode, which should be fixed rather than autocorrected.


----------



## zirias@ (Jun 13, 2022)

lu9dce said:


> but they were defined in the 13


No: https://cgit.freebsd.org/src/tree/sys/sys/_termios.h?h=releng/13.0

This is almost certainly a typo in upstream source. Just remove the extra `0` there.


----------



## jbo (Jun 13, 2022)

lu9dce said:


> Yes I understand
> but they were defined in the 13


I cannot find those definitions in the 13.0 source code: https://cgit.freebsd.org/src/tree/sys/sys/_termios.h?h=releng/13.0
Can you please show/tell us where you found those definitions in 13.0 ?


----------



## lu9dce (Jun 13, 2022)

they did not remove .. they added more
So I don't know where the error is
at 13 as I said before he was walking now no
It will be that before auto corrected the error of 0
and now it reports

freebsd 13          ---------------------------------------------------------------------------- 13.1


----------



## lu9dce (Jun 13, 2022)

well I appreciate the help
sorry it's hard for me
I don't know English and I'm using a translator
I am from Argentina

for my part there is nothing else we will see if the developer
modifies it

thank you .. sorry I get nervous .. between work
and translate everything .. my head will be like a linux user hehe


----------



## zirias@ (Jun 13, 2022)

lu9dce said:


> It will be that before auto corrected the error of 0


That's not how compilers work.

Something must have changed in the upstream source you're trying to compile.


----------



## jbo (Jun 13, 2022)

lu9dce said:


> well I appreciate the help
> sorry it's hard for me
> I don't know English and I'm using a translator
> I am from Argentina


Really not a problem! A lot of us don't speak English natively - we never judge on that.



lu9dce said:


> thank you .. sorry I get nervous .. between work
> and translate everything .. my head will be like a linux user hehe


Still no problem - don't worry 
We're here to chill & relax - so just take your time.

I think there are three main aspects to all of this:

576000 and 1152000 not being standard baud rates (https://en.wikipedia.org/wiki/Serial_port#Speed). However, other non-standard baudrates seem to be defined in FreeBSD's /usr/include/sys/_termios.h anyway.
The notion that this changed between 13.1-RC5 and 13.1-RELEASE
The fact that Linux does seem to define them: https://github.com/torvalds/linux/blob/master/drivers/tty/tty_baudrate.c#L39
When it comes to item #2 I do think that this is a different effect that you're observing such as a different version of upstream, a different upstream configuration or simply a different compiler version/default compilation flags which might not have error'd on this before.

Of course, I can be wrong on all of this.


----------



## lu9dce (Jun 13, 2022)

this is what the mshv developer shows me


----------



## lu9dce (Jun 13, 2022)

if visible like this it works fine

#if __BSD_VISIBLE
#define B7200   7200
#define B14400  14400
#define B28800  28800
#define B57600  57600
#define B76800  76800
#define B115200 115200
#define B230400 230400
#define B460800 460800
#define B500000 500000
#define B576000 576000
#define B921600 921600
#define B1000000        1000000U
#define B1152000        1152000U
#define B1500000        1500000U
#define B2000000        2000000U
#define B2500000        2500000U
#define B3000000        3000000U
#define B3500000        3500000U
#define B4000000        4000000U
#define EXTA    19200
#define EXTB    38400
#endif


----------



## zirias@ (Jun 13, 2022)

It would make *much* more sense to patch the upstream source, e.g. like this:

```
#ifdef __FreeBSD__
#  ifndef B576000
#    define B576000 576000
#  endif
#  ifndef B1152000
#    define B1152000 1152000U
#  endif
#endif
```

Or, if you're writing a port, something in its Makefile like `CFLAGS+=  -DB576000=576000 -DB1152000=152000U` would be even simpler...

That is, unless you can show which "standard" has these speeds and why it should be defined in this header...

On FreeBSD, you don't really need any of these defines, as speeds are just given as actual numbers. This is different from e.g. Linux which uses some "flags enum" style or similar (which might not be the greatest idea in terms of flexibility and extensibility...)


----------

