VOGONS


First post, by Serious Callers Only

User metadata
Rank Member
Rank
Member

I'm not a experienced dev, but i'm having a little problem.

I have two launchpad recipes that auto build the munt library into exult and dosbox into two ppa's that are my version of svn for me and maybe some other ubuntu users.

The libraries are built as system libraries. For reasons to do with launchpad, they get build separately by two recipes and dumped on the different ppa in order for exult and dosbox to autobuild. Previously this didn't matter because it's the same library, so if one got updated and both dosbox and exult were installed, the library would be the same as they're both using git code.

Just recently @sergm committed a change on its dosbox patch which i use wholesale by importing it automatically to the quilt patch system through the recipe.
"- DOSBox pathes now use mt32emu API type 3"

This is my debian/rules for compiling the libmt32emu for both dosbox and exult:
http://bazaar.launchpad.net/~i30817/+junk/mt3 … 37/debian/rules

override_dh_auto_configure:
dh_auto_configure -- \
-Dlibmt32emu_SHARED:BOOL=0 \
-Dlibmt32emu_C_INTERFACE:BOOL=0 \
-DCMAKE_BUILD_TYPE:STRING=RelWithDebInfo

As you can see, it uses
-Dlibmt32emu_C_INTERFACE:BOOL=0

which was ok before because both the dosbox patch (made by sergm) and the exult patch (made by me copying most of a older patch) were using the C interface. Now though, the dosbox ppa is using sergm new patch, which is using new api, and the build is failing with:

In file included from midi_mt32.h:7:0,
from midi.cpp:94:
/usr/include/mt32emu/mt32emu.h:47:2: error: #error Incompatible setting MT32EMU_API_TYPE=3
#error Incompatible setting MT32EMU_API_TYPE=3
^
In file included from midi_mt32.h:7:0,
from midi.cpp:94:
/usr/include/mt32emu/mt32emu.h:70:39: fatal error: c_interface/cpp_interface.h: No such file or directory
#include "c_interface/cpp_interface.h"
^

It's possible that i might build the lib in the
http://bazaar.launchpad.net/~i30817/+junk/mt3 … 37/debian/rules

with both interfaces active at the same time so i don't have to try to modernize the exult patch in order to use the same library version (or god forbid, actually have to freeze the exult version by making a new recipe just for it).

I'm looking for some information of what do i need to change in the debian/rules of the library in order to fix this without breaking the exult patch, assuming the library required by both reduces to the same file and without making it a static library build.

I just need to add
-Dlibmt32emu_CPP_INTERFACE:BOOL=0 \

to the debian/rules in addition to the c interface file right? (that bool=0 is something i find strange as usual. Outside of the bash world, 0 means failure).

Reply 1 of 7, by Serious Callers Only

User metadata
Rank Member
Rank
Member

Sorry for such a long post about such a little question but i'm trying to avoid breaking the build because if a source artifact gets published in launchpad system i have to wait a day to publish a new source even if it doesn't build because i made the mistake of basing the ppa lib soname on '{debupstream}+git{revno}+date{time}' (because it was monotonically increasing and upstream lib releases would replace it if they ever happened and i stopped updating. However since the only thing that changes regularly is the date, it prevents me from building twice on the same day on their servers).

Reply 2 of 7, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

From my pov, you rather have disabled both cmake variables libmt32emu_C_INTERFACE and libmt32emu_SHARED in this way. I also see no need to specify them explicitly since both are enabled by default when you build the library stand-alone (i.e. you should get a shared object with enabled all the available APIs).

Effectively, the error "#error Incompatible setting MT32EMU_API_TYPE=3" means here that the library build you are trying to use does not export all the functions provided by the C-compatible interface (either this is mode MT32EMU_EXPORTS_TYPE == 0 or MT32EMU_EXPORTS_TYPE == 2).

So, if not simply removed those variables, I'd set them as
-Dlibmt32emu_SHARED:BOOL=1 -Dlibmt32emu_C_INTERFACE:BOOL=1

Reply 3 of 7, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

At least, I get a static lib without C-compatible interface by running:

cmake -G "MSYS Makefiles" ../munt -Dlibmt32emu_SHARED:BOOL=0 -Dlibmt32emu_C_INTERFACE:BOOL=0
make

and a shared lib with all the available APIs after

cmake -G "MSYS Makefiles" ../munt -Dlibmt32emu_SHARED:BOOL=1 -Dlibmt32emu_C_INTERFACE:BOOL=1
make

Reply 4 of 7, by Serious Callers Only

User metadata
Rank Member
Rank
Member

Strange, i'm sure i was using the C api with the make file with Dlibmt32emu_C_INTERFACE:BOOL=0 before (and more importantly, SHARED:BOOL=0). I'll try cmake support for '=ON' instead of '=1' just to be clear.

Reply 6 of 7, by Serious Callers Only

User metadata
Rank Member
Rank
Member

Welp, you're right, it looks like i'm building the lib statically and with the c++ interface all along. The external install is required for building not runtime. I do have a runtime library that is only there to coordinate rom installation (first use of it asks for roms and places in the location the additional quilt patches overwrite the respective settings to look, last use deletes the roms, optional to apt-get purge).

What was actually missing was the C interface it seems. I have to wait until tomorrow to check if dosbox builds again on the ppa since i already queued a build like a moron for the libmt32emu even with the soname SNAFU above.

Last edited by Serious Callers Only on 2017-03-11, 13:07. Edited 2 times in total.

Reply 7 of 7, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

To reduce confusion, we now use config.h file. It contains exact build configuration that was used, so when a client application tries to link with libmt32emu installation, it may figure which version it is and which API is provided by the build. By default though, we keep all the API available (i.e. config.h should contain MT32EMU_EXPORTS_TYPE == 3).