media-sound/sequencer64-0.96.8 fails to build

[Lucretia]

libtool: compile:  x86_64-pc-linux-gnu-g++ -DLOCALEDIR=\"/usr/share/locale\" -DHAVE_CONFIG_H -I. -I../../include -I../include -I../../include -I../../seq_alsamidi/include -I../../seq_portmidi/include -I../../seq_rtmidi/include -I/usr/include/lash-1.0 "-DSEQ64_GIT_VERSION=\" \"" -march=native -O2 -pipe -Wall -Wextra -pedantic -Wno-parentheses -D_REENTRANT -DAPI_VERSION=0.96 -O3 -DDEBUG -D_DEBUG -fno-inline -std=c++14 -Wno-deprecated-copy -Wno-variadic-macros -Wno-deprecated-declarations -c perform.cpp  -fPIC -DPIC -o .libs/perform.o
In file included from palette.cpp:36:
../include/palette.hpp:151:14: error: ‘string’ in namespace ‘std’ does not name a type
  151 |         std::string ppt_color_name;
      |              ^~~~~~
../include/palette.hpp:40:1: note: ‘std::string’ is defined in header ‘<string>’; did you forget to ‘#include <string>’?
   39 | #include <map>                          /* std::map container class         */
  +++ |+#include <string>
   40 | 
../include/palette.hpp:176:61: error: ‘string’ in namespace ‘std’ does not name a type
  176 |         PaletteColor index, const COLOR & color, const std::string & name
      |                                                             ^~~~~~
../include/palette.hpp:176:56: note: ‘std::string’ is defined in header ‘<string>’; did you forget to ‘#include <string>’?
  176 |         PaletteColor index, const COLOR & color, const std::string & name
      |                                                        ^~~
../include/palette.hpp:179:16: error: ‘string’ in namespace ‘std’ does not name a type
  179 |     const std::string & get_color_name (PaletteColor index) const;
      |                ^~~~~~
../include/palette.hpp:179:11: note: ‘std::string’ is defined in header ‘<string>’; did you forget to ‘#include <string>’?
  179 |     const std::string & get_color_name (PaletteColor index) const;
      |           ^~~
../include/palette.hpp:242:57: error: ‘string’ in namespace ‘std’ does not name a type
  242 |     PaletteColor index, const COLOR & color, const std::string & colorname
      |                                                         ^~~~~~
../include/palette.hpp:242:52: note: ‘std::string’ is defined in header ‘<string>’; did you forget to ‘#include <string>’?
  242 |     PaletteColor index, const COLOR & color, const std::string & colorname
      |                                                    ^~~
../include/palette.hpp:284:12: error: ‘string’ in namespace ‘std’ does not name a type
  284 | const std::string &
      |            ^~~~~~
../include/palette.hpp:284:7: note: ‘std::string’ is defined in header ‘<string>’; did you forget to ‘#include <string>’?
  284 | const std::string &
      |       ^~~
make[2]: *** [Makefile:731: palette.lo] Error 1

A simple fix as highlghted above.

[Lucretia]

0001-Fix-compile-error-missing-string.patch.gz

[simonvanderveldt]

@Lucretia Was this not actually a bug? Or did you close it by accident?

Until two dags ago all versions of sequencer64 emerged without issues, our CI runs an emerge of all package versions in this overlay every day. We've been without completed CI runs for the last two days because of the removal of the non/NTK repo(s), so if you're talking about sequencer64-9999 then it could be that there were new commits that broke it. CI should be running without issues again today, so we'll hopefully have current feedback about emerging sequencer64 (and all other packages) again later today.

[Lucretia]

No, I closed it as I supplied the patch.

[simonvanderveldt]

@Lucretia if the problem isn't fixed we should keep this issue open. Which version of sequencer64 is this about? sequencer64-9999?

[Lucretia]

0.96.8

[simonvanderveldt]

CI just finished and all versions of sequencer64 emerged without issues. Which USE flags are you using for sequencer64? And do you have a non-standard options in your make.conf or other config files?

[Lucretia]

[U] media-sound/sequencer64 [1]
     Available versions:  (~)0.96.7^m (~)0.96.8^m (~)9999^m {cli jack lash qt5}
     Installed versions:  0.96.8^m(00:08:45 04/02/21)(cli jack lash qt5)
     Homepage:            https://github.com/ahlstromcj/sequencer64
     Description:         Reboot of seq24, a minimal loop based midi sequencer

[1] "audio-overlay" /var/lib/layman/audio-overlay

[simonvanderveldt]

I can't replicate the build failure, built it with all USE flag combinations, all of them pass, same on CI. Is there anything non-standard about your config? Maybe different GCC version or something like that?

[Lucretia]

debug.tar.gz

[Lucretia]

Did you look at these files yet?

[cbirchinger]

I had similar issues and went forward and created a an ebuild for seq66, which seems to be the successor of sequencer64

# Copyright 1999-2024 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2

EAPI=8

inherit desktop qmake-utils

DESCRIPTION="MIDI sequencer/live-looper with a hardware-sampler grid interface"
HOMEPAGE="https://github.com/ahlstromcj/seq66"
SRC_URI="https://github.com/ahlstromcj/${PN}/archive/refs/tags/${PV}.tar.gz -> ${P}.tar.gz"
KEYWORDS="amd64"
LICENSE="GPL-2"
SLOT="0"
RESTRICT="mirror"

IUSE="cli jack qt5"

RDEPEND="
        media-libs/alsa-lib
        media-libs/liblo
        jack? ( virtual/jack )
        qt5? (
                dev-qt/qtcore:5
                dev-qt/qtgui:5
                dev-qt/qtwidgets:5
        )"
DEPEND="${RDEPEND}"

REQUIRED_USE="|| ( qt5 cli )"

src_prepare()
{
        sed -e "s|^seq66docdir=.*|seq66docdir=\"\${datadir}/doc/${PF}\"|" \
                -i configure.ac || die

        default
        ./bootstrap
}

src_configure()
{
        local frontends

        if use qt5; then
                export PATH="$(qt5_get_bindir):${PATH}"
        fi

        if use cli && use qt5; then
                frontends='--enable-both'
        else
                frontends="$(use_enable cli) $(use_enable qt5 qt)"
        fi

        local -a myeconfargs=(
                --disable-portmidi
                --enable-rtmidi
                $(use_enable jack)
                $(use_enable jack jack-session)
                $(use_enable jack jack-metadata)
                $frontends
        )
        econf "${myeconfargs[@]}"
}

src_install()
{
        emake DESTDIR="${D}" install
        find "${ED}" -name '*.la' -delete || die
}

It passes QA (like /usr/share/doc location and .la files), maybe the frontends= use_enable part could be done more elegant. It's probably better to EOL the sequencer64 in favour of seq66 though. Quote from the README "Seq66 A major refactoring of Sequencer64/Kepler34/Seq24 with modern C++ and new features".