Thanks RJ. I didn't know how to open a bug in Ubuntu, so I opened a question: https://answers.launchpad.net/ubuntu/+question/260343
Glad to know that the issue is addressed with Ubuntu. For Windows it doesn't matter, as distributing executables is the rule, so I can link build portmidi myself and link statically. But this is not the case for Linux. Perhaps changing the name of macro PM_CHECK_ERRORS and honoring it only in DEBUG builds could be a simple good approach to avoid more problems like this one in future. Regards, Cecilio 2015-01-08 16:03 GMT+01:00 RJ Ryan <[email protected]>: > Hi Roger, Cecilio, > > For what it's worth, we have faced this in Mixxx: > https://bugs.launchpad.net/mixxx/+bug/1097286 > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765375 > > Users perceive it as a "crash" when the distro has chosen to build > PortMIDI with PM_CHECK_ERRORS defined. It took a while but we finally got > it fixed in Debian. Other distros may have the issue -- we only really care > about Debian derivatives. For Windows/Mac we build PortMIDI ourselves so it > doesn't affect us. > > We struggle with this question ourselves and we recently added a > "DEBUG_ASSERTS_ARE_FATAL" flag that is opt-in so that even confused users > or distro maintainers who build Mixxx in debug mode don't end up triggering > debug asserts and ruining someone's party. We redefined our debug assert > macro to be > > DEBUG_ASSERT_AND_HANDLE(condition) { > // Graceful error handling code for when debug asserts are not fatal or > in release mode. > } > > To strongly hint that developers should pair every assert with code to > gracefully (i.e. not segfault) handle the assertion. > > Cheers, > RJ > > > On Thu, Jan 8, 2015 at 9:51 AM, cecilio <[email protected]> wrote: > >> Hi, >> Thank you Roger, but the problem is there anyway. >> >> Linking statically is a partial solution as it only solves the issue for >> those who install binary packages. And although you state that "...it is >> for debugging and developing simple apps, it should never be on in a system >> installation." the fact is that in some distros (at least Ubuntu and Linux >> Mint) the library is distributed with PM_CHECK_ERRORS defined. This >> suggests that people building the packages for these distros are not aware >> of the purpose and consequences of defining this macro. >> >> Something should be done. I propose several alternatives: >> >> a) Deactivate this macro if not a debug build (that is, requiring that >> macro DEBUG is also defined, i.e replacing line 48 in portmidi.c by:: >> >> #if defined(DEBUG) && defined (PM_CHECK_ERRORS) >> >> b) Changing the macro name. i.e. PM_CHECK_ERRORS --> >> PM_DEBUG_CHECK_ERRORS to emphasize that it should be only defined in debug >> builds. >> >> c) Improve documentation oriented to distro maintainers >> >> d) The initial one: transform this option into a runtime option. >> >> Best regards, >> Cecilio >> >> >> >> 2015-01-08 13:45 GMT+01:00 Roger Dannenberg <[email protected]>: >> >>> Hi Cecilio, >>> PM_CHECK_ERRORS is for debugging and writing simple apps where you'd >>> rather crash with a sane error message to the console than fail silently. >>> Since it is for debugging and developing simple apps, it should never be on >>> in a system installation. >>> Portmidi is pretty small -- I think you could save a lot of >>> headaches by linking statically. Then you get exactly what you want and >>> eliminate the need to install a dynamic library. >>> -Roger >>> >>> >>> On 1/5/15 5:42 PM, cecilio wrote: >>> >>> Hi Roger, >>> >>> I'm facing a frustrating issue related to portmidi error reporting. It >>> seems that there are two alternatives: >>> >>> 1. print an error message to stdio and abort program execution, or >>> 2. return an error code. >>> >>> In my app I would like to use the second option (handle all errors, so I >>> would expect portmidi returning an error code/message) but the issue is >>> that this is not a portmidi runtime option but a portmidi build time >>> option, controlled by macro PM_CHECK_ERRORS. Therefore, *all* applications >>> are forced to use the reporting option chosen by sysadmins (or by distro >>> package builders, Linux Mint in may case). >>> >>> Moreover I can not distribute an application behaving consistently from >>> one machine to another as a portmidi error (i.e. buffer overflow) would >>> generate a crash in some machines but in others the app. will be able to >>> handle the error, depending on the installed portmidi library. >>> >>> Probably I'm missing something but, if not, I would suggest to change >>> the code to facilitate applications to choose the desired behaviour instead >>> of being something determined by sysadmins when installing the portmidi >>> library or by the distro portmidi package. Perhaps to have a run time >>> option for setting the error reporting behaviour or to throw an exception >>> instead of the 'exit(-1);' instruction, so that an application can opt for >>> catching the exception or ignoring it and crashing. Could this be feasible? >>> >>> Thank you very much, >>> Cecilio Salmeron >>> >>> >>> _______________________________________________ >>> media_api mailing >>> [email protected]http://lists.create.ucsb.edu/mailman/listinfo/media_api >>> >>> >>> _______________________________________________ >>> media_api mailing list >>> [email protected] >>> http://lists.create.ucsb.edu/mailman/listinfo/media_api >>> >>> >> >> _______________________________________________ >> media_api mailing list >> [email protected] >> http://lists.create.ucsb.edu/mailman/listinfo/media_api >> >> >
_______________________________________________ media_api mailing list [email protected] http://lists.create.ucsb.edu/mailman/listinfo/media_api
