no debian package for version 217 available

[morriswinkler]

apt-get install libportmidi-dev

is not working since debian is still using 184

[sstark]

Ubuntu users are suffering the same problem (port midi version 200 in Ubuntu 16.04). But actually the right place to complain would be the corresponding maintainers of those packages, since libportmidi 217 is already 6 (six!) years old.

You can build it yourself, just need to remove all the java cruft from the Makefile.

But yes, this is an unfortunate situation, especially since alternatives for go are scarce. I looked into jack. Next for me will be to do one of the following:

• try to make go port midi bindings work with older versions of portmidi and redistribute
• submit updates to Ubuntu/Debian maintainers (I tried to contact Ubuntu maintainers already, let's see.)
• use go-coremidi on osx and something else on linux (asound?), possible jack for both platforms

In fact jack looks like the best solution if you look what it can do. But it has the exact same problem: Nobody updates jack2 for OSX and Ubuntu 16.04's jack2 package is too old for the go bindings. Back to zero.

(I do not want to rehash the "version numbers for go packages" issue, but sometimes it would be handy in real life, especially for packages close to hardware)

[sstark]

After backporting portmidi 217 to Ubuntu I found it still does not compile when libportmidi is built using the debian/ubuntu packaging system. However, when I compile libportmidi 217 on my own it works. So the ubuntu package is doing something which is not compatible with the LDFLAGS in the go bindings.

Reverting this little change:

46ff27e

will make it compile on Ubuntu even with libportmidi 200. Would be good to know if this also works for Debian.

Dear rakyll, would you consider reverting this as it seems to make life quite hard for Ubuntu users?

[rakyll]

Dear rakyll, would you consider reverting this as it seems to make life quite hard for Ubuntu users?

I don't think it works on darwin with the libporttime, no idea about other linux envs. We can have different LDFLAGS for all linuxes if reverting that change works all across linux.

[sstark]

Problem is when building portmidi manually the current ldflags are right, just with the package portmidi it doesn't work.

My own build:

$ ldd /usr/local/lib/libportmidi.so | grep porttime

The version as packaged by the Ubuntu team (same with original version 200 and backported 217):

$ ldd /usr/lib/libportmidi.so.0.0.0 | grep porttime
    libporttime.so.0 => /usr/lib/libporttime.so.0 (0x00002b9bc8f7a000)

I do not know which one is right.

[sstark]

oh, and the homebrew version on darwin looks like this:

$ otool -L /usr/local/lib/libportmidi.dylib | grep porttime

It looks as if Ubuntu and Debian are doing something special here.

[sstark]

Debian 8.5 is fine with the patch reverted. However, Fedora isn't:

[root@f5d475dbab35 portmidi]# ldd /usr/lib64/libportmidi.so | grep portmidi
[root@f5d475dbab35 portmidi]# cat /etc/fedora-release 
Fedora release 24 (Twenty Four)
[root@f5d475dbab35 portmidi]# 

Would it be possible that Debian messed up the linking of libportmidi and Ubuntu just adopted it blindly? What a pity. To me it looks like fedora, darwin and you are doing it right, while ubuntu and debian don't.

Now what would a proper bug report to Debian look like for that?

[rakyll]

217 removed the dependency to libporttime, their backport needs to be consistent of this requirement or we can always suggest users to build 217 themselves. I don't have motivation to support bindings for multiple libportmidi versions.

[sstark]

Yes, after looking at it for a while I also see this is a problem that needs to be fixed on the Debian/Ubuntu side. Will report to Ubuntu. And I understand you do not want to support different versions. Thanks!

[rakyll]

No idea what other stuff links against libporttime, I am pretty confident that we are not the first library coming across to this issue. But given this is a link time flag and only affecting a few linux distros, i don't know what's the optimal solution without having to duplicate package for Debian/Ubuntu -- a solution I'd prefer not to go with.