error: no viable overloaded '='

[yurivict]

Build fails:

In file included from src/cfg/mutegroupsfile.cpp:38:
In file included from include/cfg/settings.hpp:43:
In file included from include/cfg/rcsettings.hpp:42:
In file included from include/ctrl/keycontainer.hpp:40:
/usr/include/c++/v1/map:781:17: error: no viable overloaded '='
        __ref() = __v.__get_value();
        ~~~~~~~ ^ ~~~~~~~~~~~~~~~~~
/usr/include/c++/v1/__tree:1672:39: note: in instantiation of member function 'std::__value_type<int, seq66::mutegroup>::operator=' requested here
            __cache.__get()->__value_ = *__first;
                                      ^
/usr/include/c++/v1/__tree:1629:9: note: in instantiation of function template specialization 'std::__tree<std::__value_type<int, seq66::mutegroup>, std::__map_value_compare<int, std::__value_type<int, seq66::mutegroup>, std::less<int>, true>, std::allocator<std::__value_type<int, seq66::mutegroup>>>::__assign_multi<std::__tree_const_iterator<std::__value_type<int, seq66::mutegroup>, std::__tree_node<std::__value_type<int, seq66::mutegroup>, void *> *, long>>' requested here
        __assign_multi(__t.begin(), __t.end());
        ^
/usr/include/c++/v1/map:1088:21: note: in instantiation of member function 'std::__tree<std::__value_type<int, seq66::mutegroup>, std::__map_value_compare<int, std::__value_type<int, seq66::mutegroup>, std::less<int>, true>, std::allocator<std::__value_type<int, seq66::mutegroup>>>::operator=' requested here
            __tree_ = __m.__tree_;
                    ^
include/play/mutegroups.hpp:335:58: note: in instantiation of member function 'std::map<int, seq66::mutegroup>::operator=' requested here
    mutegroups & operator = (const mutegroups &) = default;
                                                         ^
/usr/include/c++/v1/__utility/pair.h:310:11: note: candidate function not viable: no known conversion from 'const value_type' (aka 'const pair<const int, seq66::mutegroup>') to 'const __conditional_t<is_copy_assignable<first_type>::value && is_copy_assignable<second_type>::value, pair<int &, mutegroup &>, __nat>' (aka 'const std::__nat') for 1st argument
    pair& operator=(__conditional_t<
          ^
/usr/include/c++/v1/__utility/pair.h:323:11: note: candidate function not viable: no known conversion from 'const value_type' (aka 'const pair<const int, seq66::mutegroup>') to '__conditional_t<is_move_assignable<first_type>::value && is_move_assignable<second_type>::value, pair<int &, mutegroup &>, __nat>' (aka 'std::__nat') for 1st argument
    pair& operator=(__conditional_t<
          ^
/usr/include/c++/v1/__utility/pair.h:383:11: note: candidate template ignored: requirement '_CheckTLC<const pair<const int, mutegroup> &>::__enable_assign()' was not satisfied [with _Tuple = const value_type &]
    pair& operator=(_Tuple&& __p) {
          ^
/usr/include/c++/v1/__utility/pair.h:63:29: note: candidate function (the implicit copy assignment operator) not viable: no known conversion from 'const pair<const key_type, mapped_type>' to 'const pair<int &, seq66::mutegroup &>' for 1st argument
struct _LIBCPP_TEMPLATE_VIS pair
                            ^

Version: 0.99.11
clang-16
FreeBSD 13.2

[ahlstromcj]

As we used to quip at work: "It builds on my machiiiiiiiiine." :-) Not quite sure what's going on there, the operator = for the mutegroup/mutegroups are set to "default". I'll have to dig deeper. Might have to install and build using clang, which might take a little while to figure out in Seq66's autoconf system.

If you have QtCreator installed, you can create a shadow directory and in it run "qbuild rtmidi", but I suspect the same error will occur. qbuild is in contrib/scripts in the project tree and I use it sometimes.

[ahlstromcj]

Okay, got a clang build going, and am looking at the errors (there are a few!) that clang found. This is clang-10, though. The latest version I have on this Ubuntu box is clang-12. Will ultimately check it out on the Arch box.

[ahlstromcj]

Got the build working on Ubuntu with clang-12, fixed all warnings and errors, added Clang instructions to INSTALL, and check it all into the "portfix" branch. Then I pull it to my Arch laptop, which uses clang-16. I run "CC=clang CXX=clang++ ./configure". That fails with an error "Failed to find matching components of a complete Qt installation." Digging deeper is seems that ax_qt_main.o generated for testing Qt yields "file not recognized: file format not recognized". So more digging to do, just wanted to let you know where I was at.

[ahlstromcj]

Actually, my fixes for other errors found when using clang-12 might fix your original problem. If you can do this:

$ ./bootstrap --full-clean
$ git checkout portfix
$ . . . (anything else?)

And try your build again, let me know if that worked. In the meantime I still want to get clang-16 to configure successfully on my Arch box.

[yurivict]

There is still an error and many warnings: https://people.freebsd.org/~yuri/seq66-portfix.log

[ahlstromcj]

I think I got rid of the errors and warnings (pretty obvious fixes). I noticed that the build was configured for "portmidi". In Seq66v2 (a lonnnng ways off) I hope to consolidate everything under a refactored "rtmidi" framework, including Mac OSX. Question: does FreeBSD have a framework to compile Mac apps, i.e. does it support the CoreMIDI/CoreAudio framework? Just a question for the future. Thanks again for your help and input!

[ahlstromcj]

Finally got qseq66 (haven't tried qpseq66) to build on clang-16. Had to disable the paranoid checks for Qt from an m4 macro, and had to remove a linker option. Once I get confidence, I will add checks for clang to make these changes automatic. Also thinking of provisioning a FreeBSD VM with qemu. On your setup, were clang and Qt normal installs? Or did you have to rebuild Qt?

[yurivict]

Question: does FreeBSD have a framework to compile Mac apps, i.e. does it support the CoreMIDI/CoreAudio framework?

No, on FreeBSD we have multiple audio backends available: OSS, Jack, PulseAudio, SoundIO, ALSA, etc.

[yurivict]

On your setup, were clang and Qt normal installs? Or did you have to rebuild Qt?

Qt is built and installed from the port/package. No special rebuild is needed.

[ahlstromcj]

Qt is built and installed from the port/package. No special rebuild is needed.

Is clang the "native" compiler for FreeBSD? Or GCC? -- Thanks!

[yurivict]

Is clang the "native" compiler for FreeBSD? Or GCC? -- Thanks!

clang is the native compiler.

[ahlstromcj]

I finally got a reasonable FreeBSD virtual machine running via Qemu, and am now working through getting a clone of the portfix branch to configure. Can you summarize the steps you took to get to where "make" could be run? Thanks!

[yurivict]

You should be able to build the project in a normal way by running ./configure && gmake.

[ahlstromcj]

You should be able to build the project in a normal way by running ./configure && gmake.

I get errors about headers for liblo and libasound, for starters. I installed liblo, and it looks like alsa is installed. In Debian/Ubuntu, I have to install the -dev version of these packages; they seem to be included automatically on Arch Linux when the library itself is installed. Also, isn't gmake a GNU thing? Ah, puzzles to solve.

[ahlstromcj]

Still working through build issues on FreeBSD; the VM is slow as hell. Anyway, my current puzzle to solve is the pthreads mutex support on FreeBSD, it is quite a bit different from Linux. The build breaks at the recmutex module.

You can see some of the carp I've had to deal with in the latest INSTALL file in the portfix branch. But at least I'm (slowly) moving forward.

[ahlstromcj]

So I got past the recmutex and the build now fails in seq_qt5 at the first qt file with "QBrush: file not found". And, indeed, even with the qt5-gui package installed, there's no such file, not even qbrush.h, anywhere in /usr. The only thing found is a html file in the doc area. Mayhaps my FreeBSD vm is too new? Sigh.

[yurivict]

qbrush.h is installed by QtGui (either from Qt5 or Qt6):

[yuri@yv /usr/ports/audio/seq66]$ pkg which /usr/local/include/qt5/QtGui/qbrush.h
/usr/local/include/qt5/QtGui/qbrush.h was installed by package qt5-gui-5.15.11p135
[yuri@yv /usr/ports/audio/seq66]$ pkg which /usr/local/include/qt6/QtGui/qbrush.h
/usr/local/include/qt6/QtGui/qbrush.h was installed by package qt6-base-6.6.1

[ahlstromcj]

The qt5-gui package *is* installed, but there is no qt5/QtGui directory. For the heck of it I installed qtcreator, which installed Qt6, and that version does have qt6/QtGui (and the QBrush file). So I think this is a bug, and will report it as such. For now, I'm building the command-line version of Seq66 to flush out other errors (many due to testing for LINUX instead of UNIX in macros).

[yurivict]

pkg -l qt5-gui shows all files installed by this package.
If the directory is listed but is actually missing - pkg upgrade -f qt5-gui should reinstall this package and restore all files.

[ahlstromcj]

The command is actually "pkg info -l qt5-gui". Anyway, the pkg upgrade command worked! Many thanks, I can move forward again. Heh, can't resist including this output from fortune: Connection reset by some moron with a backhoe

[ahlstromcj]

Well dang! The Qt m4 macro is setting all the QT variables except for QT_CXXFLAGS and QT_LIBS. Will keep on trudgin'.

[ahlstromcj]

I also had to reinstall the Qt Core and Widgets packages. I finally gave up on digging into what configure was doing (or not doing) to get QT_CXXFLAGS and QT_LIBS defined. Instead, I used the qmake method mentioned in INSTALL. I installed bash so I could use the qbuild script in contrib/scripts, and that worked. I have a preliminary dash/sh script called qbuild.sh, but haven't tested it in FreeBSD yet.

Now I have a runtime error running the qseq66 application from the shadow directory for the build:
Failed to load platform plugin "xcb"... even though it was found. Brain-tired, so watch Liverpool vs Arsenal now and I'll get back to this later. If you have any ideas in the meantime that would be cool.

[ahlstromcj]

The bugzilla bug number for having for force package upgrades is 275893. There is a long discussion of the xcb bug at 214340, which is closed. My guess is a dependency of libxcb on FreeBSD is not getting installed, so that the plugin can be found, but not be loaded.

[ahlstromcj]

Oh, forgot to mention that I wrote a new shell script, contrib/scripts/qbuild.sh to be portable between shells. It runs qmake and then make. It has options for various things, see qbuild.sh --help.

[yurivict]

No, this xcb problem is an old, closed bug. I am not aware of any current xcb-related problem.

Can you share your current branch that you are working on?

[ahlstromcj]

Can you share your current branch that you are working on?

I'm thinking I'm missing a dependency of libxcb. Have not taken the time yet to check all the shared libraries that "ldd" notes in libxcb. The current branch is "portfix". It includes a new script in contrib/scripts, called qbuild.sh. I copy it to my personal ~/bin and run it in a Qt shadow directory. It's an alternative to automake, which has been driving me crazy in FreeBSD. Good ol' M4.

[ahlstromcj]

Have been working on other issues.... Have you gotten the code to build? And run? I will eventually try to solve the libxcb-related error.

[ahlstromcj]

So I ditched the VM and instead installed the release of FreeBSD before version 14 on a spare SSD in a USB box. Took awhile to get stuff installed. But I got the code to build using qbuild.sh (qmake), and it actually runs! I still have to figure out some issues with ALSA and JACK detection and also give the automake build another run-through. Much more pleasant to work on a native build!

[ahlstromcj]

Check the master branch. I got the code to build (read the FreeBSD section of INSTALL) and play to qsynth using qjacktrl to start JACK (with qseq66 --jack). Also read contrib/notes/freebsd.text. Still can't see the USB MIDI devices, though, either in ALSA or JACK. Any insight you have would be appreciated. Thanks!