New MSHV hamradio soft

lu9dce

lu9dce

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


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
 
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?
 
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

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

Code: 
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.
 
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
 
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
 
lu9dce said:
thank you sorry for the inconvenience
Click to expand...
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 said:
ok in 13 it works fine even without fixing anything
the problem is in 13.1
Click to expand...
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.
 
gcc --version
gcc (FreeBSD Ports Collection) 11.2.0

with gcc11 the same error

-------
did you manage to compile it in 13.1?
 
lu9dce said:
did you manage to compile it in 13.1?
Click to expand...
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.
 
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
 
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
----------------------------------------------------------------------------
 
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.
 
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
 
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.
 
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
1655125898657.png
 
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
 
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
Click to expand...
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
Click to expand...
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:
  1. 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.
  2. The notion that this changed between 13.1-RC5 and 13.1-RELEASE
  3. 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.
 
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
 
You must log in or register to reply here.
Back
Top