Error when compiling: undefined reference to `ipatch_close'

[rafaelbeirigo]

Describe the bug
When compiling, I got the following error:

/usr/bin/ld: CMakeFiles/muse.dir/main.cpp.o: in function `main':
main.cpp:(.text.startup+0x3194): undefined reference to `ipatch_close'
collect2: error: ld returned 1 exit status
make[2]: *** [muse/CMakeFiles/muse.dir/build.make:367: muse/muse4] Error 1
make[1]: *** [CMakeFiles/Makefile2:1856: muse/CMakeFiles/muse.dir/all] Error 2
make: *** [Makefile:152: all] Error 2

To Reproduce
Steps to reproduce the behavior:

1. git clone https://github.com/muse-sequencer/muse.git
2. Follow building instructions in src/README (install packages and run src/compile_muse.sh)

Desktop (please complete the following information):

• OS: Debian 10; multiarch (amd64 + i386)
• libinstpatch: version 1.0.0 installed via apt; version 1.1.6 compiled locally
• Desktop: awesomewm

[terminator356]

Oops. Fixed mistake at 15.05.2023: Link libinstpatch with 'muse' module, not 'core'.
Fixed in git master now.

Sorry for the inconvenience.
Thanks for the report. Let me know if any trouble.
Close the issue if it works.

[rafaelbeirigo]

I tried the following steps:

1. cd muse/src
2. git pull
3. git log confirms HEAD at 0e64901433ea567548a2ca019e411011ed462f3d
4. rm -f build/
5. ./compile_muse.sh
   but got the same error. Am I doing something wrong?

[terminator356]

Hm. Strange.
Executing ./compile_muse.sh should have re-configured and picked up the changes.

If possible maybe try starting over by building a complete fresh clone of the master.

Also just to be sure, locate your system's pkgconfig file 'libinstpatch-1.0.pc', usually located in
folder /usr/lib64/pkgconfig/libinstpatch-1.0.pc, or sometimes in /usr/lib/pkgconfig/libinstpatch-1.0.pc
Please post the contents of that file.

Although, that file should be OK since we call the very same offending `ipatch_close' function
in our MESS fluidsynth plugin, which must have built properly early in the build if muse got
very close to the end of building.

Not sure what could be wrong, we've not had any complaints about that.
Actually it should have worked fine before this fix since module 'muse' is linked with 'core'
which was already linked with libinstpatch.
So something is a bit strange here...
Let me know if any luck building a fresh clone.
Thanks.

[rafaelbeirigo]

If possible maybe try starting over by building a complete fresh clone of the master.

Tried that, but the error persisted.

But while it was compiling I did the second thing:

Also just to be sure, locate your system's pkgconfig file 'libinstpatch-1.0.pc', usually located in
folder /usr/lib64/pkgconfig/libinstpatch-1.0.pc, or sometimes in /usr/lib/pkgconfig/libinstpatch-1.0.pc
Please post the contents of that file.

Funny thing: I have two copies of that file:

• /usr/lib/x86_64-linux-gnu/pkgconfig/libinstpatch-1.0.pc
• /usr/local/lib/pkgconfig/libinstpatch-1.0.pc (for some reason, past me compiled it locally)

The contents are:

/usr/lib/x86_64-linux-gnu/pkgconfig/libinstpatch-1.0.pc:

prefix=/usr
exec_prefix=${prefix}
libdir=${prefix}/lib/x86_64-linux-gnu
includedir=${prefix}/include

Name: libInstPatch
Description: MIDI instrument patch library
Version: 1.0.0
Requires: glib-2.0 gobject-2.0 sndfile
Libs: -L${libdir} -linstpatch-1.0
Cflags: -I${includedir}/libinstpatch-1.0

/usr/local/lib/pkgconfig/libinstpatch-1.0.pc:

prefix=/usr/local
exec_prefix=${prefix}
libdir=/usr/local/lib
includedir=/usr/local/include/libinstpatch-2

Name: libInstPatch
Description: MIDI instrument patch library
Version: 1.1.6
Requires: glib-2.0 gobject-2.0 gthread-2.0 sndfile
Libs: -L${libdir} -linstpatch-1.0
Cflags: -I${includedir}

Maybe this is a noob question, but is there a way to point one of them out manually to compile?

[terminator356]

Maybe this is a noob question, but is there a way to point one of them out manually to compile?

Maybe, I don't recall. But it would be more desirable to use the later self-built version.
The nice thing about the whole 'local' folders thing is that building and installing software yourself
is safe and easy and co-exists with package-installed versions.
When building most software, such as MusE, things found in 'local' automatically take priority
over package-installed versions.
When your self-built 'local' things are uninstalled, the system goes back to using the package-installed versions
as if nothing ever happened. (That is why it is unwise to let self-built software install into non- 'local' folders.)

Let's check some things:
The ldconfig command can show what libraries actually point to where. It usually needs to be run as root.
Try sudo ldconfig -p | grep libinstpatch. What is the output? Here it says:

libinstpatch-1.0.so.2 (libc6,x86-64) => /lib64/libinstpatch-1.0.so.2
libinstpatch-1.0.so (libc6,x86-64) => /lib64/libinstpatch-1.0.so

Next, locate the MusE 'build' folder and look for this file:
build/muse/CMakeFiles/muse.dir/link.txt
What's inside? We're looking for something like -linstpatch-1.0. Here are a few lines of mine:

/usr/bin/c++  -Werror=format-security -Wextra -Winvalid-pch -fexceptions -Wall -fPIC -O0 -g -g -DQT_DEBUG -Werror 
CMakeFiles/muse.dir/main.cpp.o CMakeFiles/muse.dir/qrc_resources.cpp.o -o muse4  
-Wl,-rpath,/home/me/muse_20220930/lib/muse-4.1/modules libmuse_core.so 
-linstpatch-1.0 -lgobject-2.0 -lgthread-2.0 -lglib-2.0 -lsndfile 

It is possible your build of instpatch is incomplete or something. Hopefully not.
We'll see if MusE is grabbing the older version by mistake and maybe there are problems there.

I verified that the line of CMake code I fixed is working correctly.
And, that is directly evidenced by my output of link.txt, above (the -linstpatch part).

That's all I can remember to type right now :-)
Thanks.

[rafaelbeirigo]

First of all, just wanna say I appreciate all the effort you are putting into helping me. Thank you very much!

Try sudo ldconfig -p | grep libinstpatch. What is the output?

Here it gives (I wasn't sure if the order mattered so I resisted my OCD craving to order it by folder):

libinstpatch-1.0.so.2 (libc6,x86-64) => /usr/local/lib/libinstpatch-1.0.so.2
libinstpatch-1.0.so.0 (libc6,x86-64) => /lib/x86_64-linux-gnu/libinstpatch-1.0.so.0
libinstpatch-1.0.so (libc6,x86-64) => /usr/local/lib/libinstpatch-1.0.so
libinstpatch-1.0.so (libc6,x86-64) => /lib/x86_64-linux-gnu/libinstpatch-1.0.so

Next, locate the MusE 'build' folder and look for this file: build/muse/CMakeFiles/muse.dir/link.txt What's inside? We're looking for something like -linstpatch-1.0.

Just in case, I'm pasting the contents of the whole file (line breaks added for convenience)

muse/src/build/muse/CMakeFiles/muse.dir/link.txt:

/usr/bin/c++ -Werror=format-security -Wextra -Winvalid-pch -fexceptions -Wall
-fPIC -O2 -DNDEBUG -O3 -DNDEBUG -fomit-frame-pointer -ffast-math
-fno-finite-math-only CMakeFiles/muse.dir/main.cpp.o
CMakeFiles/muse.dir/qrc_resources.cpp.o -o muse4
-Wl,-rpath,/usr/local/lib/muse-4.1/modules midiedit/libmuse_midiedit.a libmuse_core.a
-linstpatch-1.0
-lgobject-2.0 -lgthread-2.0 -lglib-2.0 -lsndfile midiedit/libmuse_midiedit.a libmuse_core.a ctrl/libmuse_ctrl.a
function_dialogs/libmuse_widgets_functiondialogs.a ../al/libmuse_al.a
arranger/libmuse_arranger.a cliplist/libmuse_cliplist.a driver/libmuse_driver.a
-lasound -ljack -ljack -lrtaudio -lasound -ljack -ljack -lrtaudio -lpulse-simple
-lpulse instruments/libmuse_instruments.a libmuse_latency_compensator_module.so
liste/libmuse_liste.a marker/libmuse_marker.a master/libmuse_master.a
mixer/libmuse_mixer.a mplugins/libmuse_mplugins.a
../libs/string/libmuse_string.a
../libs/plugin/libmuse_plugin_cache_writer_module.so
../libs/plugin/libmuse_plugin_rdf_module.so
../libs/plugin/libmuse_plugin_cache_reader_module.so
../libs/plugin/libmuse_plugin_list_module.so
../libs/plugin/libmuse_plugin_scan_module.so -llrdf -lpthread
../synti/libsynti/libmuse_synti.a ../libs/wave/libmuse_wave_module.a
../audio_convert/libaudio_converter_plugin.a
../libs/time_stretch/libmuse_time_stretch_module.a waveedit/libmuse_waveedit.a
libmuse_wavepreview_module.so components/libmuse_components.a libmuse_icons.a
-lsamplerate remote/libmuse_remote.a widgets/libmuse_widgets.a
/usr/lib/x86_64-linux-gnu/libpython3.7m.so -ldl -latomic -llo -lpthread
../libs/midnam/libmuse_midnam_module.so
../libs/midi_controller/libmuse_midi_controller_module.so
../libs/mpevent/libmuse_mpevent_module.so
../libs/evdata/libmuse_evdata_module.so ../libs/memory/libmuse_memory_module.so
../libs/sysex_helper/libmuse_sysex_helper_module.so
../libs/xml/libmuse_xml_module.so /usr/lib/x86_64-linux-gnu/libQt5UiTools.a
/usr/lib/x86_64-linux-gnu/libQt5Xml.so.5.11.3
/usr/lib/x86_64-linux-gnu/libQt5Svg.so.5.11.3
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.11.3
/usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.11.3
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5.11.3 -lsndfile

Based on what you said earlier, I thought it could be a good idea to declutter here, so I uninstalled the local version of libinstpatch. Then recompiling a fresh repo clone, and it complained about ipatch_close (); in the files

muse/src/muse/main.cpp
muse/src/synti/fluidsynth/fluidsynti.cpp

I tried a quick and dirty commenting, and it compiled successfully, and I could run it! (Awesome splash screen btw)

Should I close the issue, then?

Again, thanks for all the help!

[terminator356]

I tried a quick and dirty commenting, and it compiled successfully, and I could run it! (Awesome splash screen btw)
Should I close the issue, then?

Ooh, no. I don't recommend leaving like that. ipatch_close would be nicer :-)

I just found the problem. [Sigh] ipatch_close was introduced in version 1.1.0
Your system installed version is 1.0.0

This is MusE's fault.
If you hang in there I'll fix that, likely tomorrow :-)
(Remove your comment markers, to restore the lines, before you pull.)

However... that means your build chain was somehow finding the old version even though
you had version 1.1.6 installed ! Kinda messed up. Something sure was not correct there.

Therefore I highly recommend re-building and installing the latest libinstpatch.
It should work. And it's better (bug fixes, features etc.)

If you wait until after I fix the 1.0.0 error, you'll be my guinea pig to ensure 1.0.0 works ;-)
Then you can move on the 1.1.6 and what should end up a proper installation if all goes well.

Thanks for the reports. Should be solved soon...

[terminator356]

Well, it passed 12:00AM here, so that's tomorrow ;-)
Should be fixed in git master now.

You should be able to restore the two commented lines (to exact original state), then pull, then build.
Test and verify that it runs with your instpatch 1.0.0
.
Then re-build and install libinstpatch 1.1.6 if desired (recommended).
Good luck. Hope it works out.

You're getting the very latest dozens of major fixes and features over the last few months.
It is almost release-ready. You should be able to enjoy it relatively trouble-free.
Let us know if any issues.

[rafaelbeirigo]

If you wait until after I fix the 1.0.0 error, you'll be my guinea pig to ensure 1.0.0 works ;-)

Sure, happy to help :) These are the steps I took to run the test:

• Uninstalled MusE
• Cloned a fresh new copy of the repo
• Ran compile_muse.sh
• Installed MusE
• Ran MusE

Passed with flying colors!

Then you can move on the 1.1.6 and what should end up a proper installation if all goes well.

After that, to test the new version of libinstpatch I took the steps:

• Uninstalled MusE
• Cloned a fresh new copy of MusE's repo
• Cloned a fresh new copy of libinstpatch's repo
• Compiled and installed libinstpatch
• Repeated the previous tests:

$ sudo ldconfig -p | grep libinstpatch
        libinstpatch-1.0.so.2 (libc6,x86-64) => /usr/local/lib/libinstpatch-1.0.so.2
        libinstpatch-1.0.so.0 (libc6,x86-64) => /lib/x86_64-linux-gnu/libinstpatch-1.0.so.0
        libinstpatch-1.0.so (libc6,x86-64) => /usr/local/lib/libinstpatch-1.0.so
        libinstpatch-1.0.so (libc6,x86-64) => /lib/x86_64-linux-gnu/libinstpatch-1.0.so

/usr/lib/x86_64-linux-gnu/pkgconfig/libinstpatch-1.0.pc:

prefix=/usr
exec_prefix=${prefix}
libdir=${prefix}/lib/x86_64-linux-gnu
includedir=${prefix}/include

Name: libInstPatch
Description: MIDI instrument patch library
Version: 1.0.0
Requires: glib-2.0 gobject-2.0 sndfile
Libs: -L${libdir} -linstpatch-1.0
Cflags: -I${includedir}/libinstpatch-1.0

/usr/local/lib/pkgconfig/libinstpatch-1.0.pc:

prefix=/usr/local
exec_prefix=${prefix}
libdir=/usr/local/lib
includedir=/usr/local/include/libinstpatch-2

Name: libInstPatch
Description: MIDI instrument patch library
Version: 1.1.6
Requires: glib-2.0 gobject-2.0 gthread-2.0 sndfile
Libs: -L${libdir} -linstpatch-1.0
Cflags: -I${includedir}

• Ran compile_muse.sh

Here I got the error:

/usr/bin/ld: CMakeFiles/muse.dir/main.cpp.o: in function `main':
main.cpp:(.text.startup+0x3194): undefined reference to `ipatch_close'
collect2: error: ld returned 1 exit status
make[2]: *** [muse/CMakeFiles/muse.dir/build.make:367: muse/muse4] Error 1
make[1]: *** [CMakeFiles/Makefile2:1856: muse/CMakeFiles/muse.dir/all] Error 2
make: *** [Makefile:152: all] Error 2

/usr/local/src/muse/src/build/muse/CMakeFiles/muse.dir/link.txt:

/usr/bin/c++ -Werror=format-security -Wextra -Winvalid-pch -fexceptions -Wall
-fPIC -O2 -DNDEBUG -O3 -DNDEBUG -fomit-frame-pointer -ffast-math
-fno-finite-math-only CMakeFiles/muse.dir/main.cpp.o
CMakeFiles/muse.dir/qrc_resources.cpp.o -o muse4
-Wl,-rpath,/usr/local/lib/muse-4.1/modules midiedit/libmuse_midiedit.a libmuse_core.a
-linstpatch-1.0
-lgobject-2.0 -lgthread-2.0 -lglib-2.0 -lsndfile
midiedit/libmuse_midiedit.a libmuse_core.a ctrl/libmuse_ctrl.a
function_dialogs/libmuse_widgets_functiondialogs.a ../al/libmuse_al.a
arranger/libmuse_arranger.a cliplist/libmuse_cliplist.a driver/libmuse_driver.a
-lasound -ljack -ljack -lrtaudio -lasound -ljack -ljack -lrtaudio -lpulse-simple
-lpulse instruments/libmuse_instruments.a libmuse_latency_compensator_module.so
liste/libmuse_liste.a marker/libmuse_marker.a master/libmuse_master.a
mixer/libmuse_mixer.a mplugins/libmuse_mplugins.a
../libs/string/libmuse_string.a
../libs/plugin/libmuse_plugin_cache_writer_module.so
../libs/plugin/libmuse_plugin_rdf_module.so
../libs/plugin/libmuse_plugin_cache_reader_module.so
../libs/plugin/libmuse_plugin_list_module.so
../libs/plugin/libmuse_plugin_scan_module.so -llrdf -lpthread
../synti/libsynti/libmuse_synti.a ../libs/wave/libmuse_wave_module.a
../audio_convert/libaudio_converter_plugin.a
../libs/time_stretch/libmuse_time_stretch_module.a waveedit/libmuse_waveedit.a
libmuse_wavepreview_module.so components/libmuse_components.a libmuse_icons.a
-lsamplerate remote/libmuse_remote.a widgets/libmuse_widgets.a
/usr/lib/x86_64-linux-gnu/libpython3.7m.so -ldl -latomic -llo -lpthread
../libs/midnam/libmuse_midnam_module.so
../libs/midi_controller/libmuse_midi_controller_module.so
../libs/mpevent/libmuse_mpevent_module.so
../libs/evdata/libmuse_evdata_module.so ../libs/memory/libmuse_memory_module.so
../libs/sysex_helper/libmuse_sysex_helper_module.so
../libs/xml/libmuse_xml_module.so /usr/lib/x86_64-linux-gnu/libQt5UiTools.a
/usr/lib/x86_64-linux-gnu/libQt5Xml.so.5.11.3
/usr/lib/x86_64-linux-gnu/libQt5Svg.so.5.11.3
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.11.3
/usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.11.3
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5.11.3 -lsndfile

I'm not sure if this is relevant, but my machine has Debian with multiarch. Could this be messing things up?

[terminator356]

Hm, that's strange. Your build chain seems to be picking up the old version.

Just to verify, could you do me a wee favour?
Run the config/compile script again and post the top part of the console output where it says something like:

/home/me/Source/muse_20220930_build_master_add_mute_and_solo_ctrls> /usr/bin/cmake 
-DCMAKE_EXPORT_COMPILE_COMMANDS=ON -DCMAKE_INSTALL_PREFIX=/home
/me/muse_20220930_debug_master_add_mute_and_solo_ctrls -DCMAKE_BUILD_TYPE=Debug /home/me/Source
/muse_20220930_master_add_mute_and_solo_ctrls/src
 vst header path: /home/me/Source/muse_20220930_master_add_mute_and_solo_ctrls/src/vestige
Unix (probably linux) found
Native VST support enabled
Zita resampler disabled
-- Checking for module 'libinstpatch'
--   Package 'libinstpatch', required by 'virtual:world', not found
-- Checking for module 'libinstpatch-1.0'
--   Found libinstpatch-1.0, version 1.1.6

Our cmake scripts handle libinstpatch differently.
They first check for a newer version then check for an older version.
I am curious what yours says.
Maybe my script is not correct? Something seems backwards in that script. Or not...
Thanks.

For reference here is the script section:

if ( ENABLE_INSTPATCH )
  # Check recent version:
  PKG_CHECK_MODULES(INSTPATCH libinstpatch)
  if (INSTPATCH_FOUND)
        include_directories(${INSTPATCH_INCLUDE_DIRS})
        set(HAVE_INSTPATCH ON)
  else (INSTPATCH_FOUND)
       # Check older version:
        PKG_CHECK_MODULES(INSTPATCH libinstpatch-1.0)
        if (INSTPATCH_FOUND)
              include_directories(${INSTPATCH_INCLUDE_DIRS})
              set(HAVE_INSTPATCH ON)
        endif (INSTPATCH_FOUND)
  endif (INSTPATCH_FOUND)
else ( ENABLE_INSTPATCH )
      message("Inst(rument) Patch support disabled")
endif ( ENABLE_INSTPATCH )

[rafaelbeirigo]

Sure, here is the output:

CheckAtomic module not found! Using local copy instead.
 vst header path: /usr/local/src/muse/src/vestige
Unix (probably linux) found
-- Checking for module 'lash-1.0>=0.2'
--   No package 'lash-1.0' found
Native VST support enabled
-- Checking for module 'serd-0>=0.30.0'
--   Requested 'serd-0 >= 0.30.0' but version of Serd is 0.28.0
-- Checking for module 'lv2>=1.18.0'
--   Requested 'lv2 >= 1.18.0' but version of LV2 is 1.14.0
Zita resampler disabled
-- Checking for module 'libinstpatch'
--   No package 'libinstpatch' found
-- Checking for module 'libinstpatch-1.0'
--   Found libinstpatch-1.0, version 1.1.6
Existing CMAKE_CXX_FLAGS: 
Existing CMAKE_CXX_FLAGS_RELEASE: -O3 -DNDEBUG
Existing CMAKE_CXX_FLAGS_RELWITHDEBINFO: -O2 -g -DNDEBUG
Existing CMAKE_CXX_FLAGS_DEBUG: -g
Final CMAKE_CXX_FLAGS:  -Werror=format-security -Wextra -Winvalid-pch -fexceptions -Wall -fPIC
Final CMAKE_CXX_FLAGS_RELEASE: -O2 -DNDEBUG -O3 -DNDEBUG -fomit-frame-pointer -ffast-math -fno-finite-math-only
Final CMAKE_CXX_FLAGS_RELWITHDEBINFO: -O2 -g -DNDEBUG -O2 -g -DNDEBUG -fomit-frame-pointer -ffast-math -fno-finite-math-only
Final CMAKE_CXX_FLAGS_DEBUG: -O0 -g -g -DQT_DEBUG -Werror
Warning: HAVE_CXX_ATOMICS_WITHOUT_LIB or HAVE_CXX_ATOMICS64_WITHOUT_LIB are false. Linking core with required libatomic.


** WARNING: lash (>= 0.2) was enabled, but development files were not found. 
** HINT: Don't have LASH? Try installing the LADISH LASH compatibility package instead.
** WARNING: LV2 support was chosen, but development files were not found or too old:
   Requires lv2 >= 1.18.0, lilv-0 >= 0.24.0, sord-0 >= 0.16.0, serd-0 >= 0.30.0


The following components will be built:
-----------------------------------------------
   ALSA support
   RTAudio support
   Lrdf support
   OSC (Liblo) support
   Python support
   DSSI support
   Native VST support
   Fluidsynth support
   RubberBand support
   Instpatch support

The following components WILL NOT be built:
-----------------------------------------------
   Lash support
   LV2 support

 Internal modules will be built statically into the final binary.
 Build type: release

-- Configuring done
-- Generating done
-- Build files have been written to: /usr/local/src/muse/src/build

Sorry, I'm not familiar with the syntax of that script!

I admire your tenacity, though!

[terminator356]

Weird. It found the correct version but for some reason your build chain seems to be choosing to link with
the old library, which does not have the ipatch_close.

I will try to reproduce this by installing 1.0.0
Not sure what else to try...

[rafaelbeirigo]

Thank you very much for your help!

In practice, the problem was circumvented, and I could achieve my goal of running the program.

I personally would bet this problem is be due to the specifics of my system, probably because of being multiarch. I just updated OP to make this explicit. Moreover, I guess this is not representative of your user pool.

Therefore, I would like to tell you that you don't have to fix this development because of this issue in particular. I can imagine how busy you are, and can't help but think that you could employ your time better elsewhere.

How do you feel about closing this issue as "not planned"?

[terminator356]

OK I'll close it. Feel free to reopen if any other trouble, or if the problem is resolved.
It's too bad we could not get the latest instpatch version to cooperate.
I suspect that once an updated package comes down the line for you, it may compile correctly then.
Perhaps when building more software, this issue might come up again and hopefully an answer could be found.