Hello, Christopher Arndt wrote: > Hi, > > Atsushi Eno schrieb: >> I was trying to autotoolize portmidi and I have portmidi.dll and >> porttime.dll for my C# binding, though with some manual changes. >> http://github.com/atsushieno/portmidi-sharp/tree/e5070610f932a5ad2f9c0e00056e166a750f161e/portmidi-patches >> >> The win32 patch contains a build script and autogen.sh to build >> required things. Though I haven't verified if it really works out >> of the box. > > thanks for the hint and the patches. After I set up all the MinGW/msys > stuff on my Windows VM (which includes compiling autoconf, automake and > libtool), I managed to build the library with your patches. The > "autogen.sh" script didn't work for me out of the box though. I had to > uncomment the line that created the NEWS, README, etc. files and I also > added the "--prefix=/mingw" option to configure.
Glad to know that it somewhat helped you :) About patch incompleteness, it is sort of expected - I'll have to find out how it's broken and fix it. Though I haven't spent time on it so far. > Also, it was not possible to configure & build in a separate build > directory. I had to build in the portmidi source directory for > everything to work. > > I described the whole process here: > > http://chrisarndt.de/projects/portmidizero/ Cool, thanks for sharing the info. > After the "make" step I had separate "libportmidi-0.dll" and > "libporttime-0.dll" files in pm_win/.libs. A few questions about this > result: > > - Is this the intended end result? No and yes - it is not what I wanted, but it is what it actually happens. I manually rename them to portmidi.dll and porttime.dll. > - If yes, why does the lib name have the "-0" appended? Is this > necessary or is this just a convention to allow for several versions of > the lib to be installed? It is some strangeness inside gcc/cygwin build. I might be some kind of known issue, but I'm not aware. (I'm no expert there either) > - Why are there separate dlls for portmidi and porttime? Would it be > possible to roll them into one like it is done on OS X? The things is, I > want to use the dll with the Python ctypes module (the standard foreign > function interface module for Python) and when I load libportmidi-0.dll, > the system tries to find and load libporttime-0.dll as well and so the > latter has to be in a place where the windows library loading mechanism > will find it. It is possible to build unified dll, but those libraries are built separately on Mac and Linux (it seems that Debian already has the shared version of the build, with their local patch). If it is built unified only on Windows, then it may bring incompatibility in dynamic invocation. > Thus is would not be possible to put it alongside the libportmidi-0.dll > in the Python package. The same problem would affect other languages > trying to load this lib dynamically, described in this debian portmidi > package bug: > > https://bugs.launchpad.net/debian/+source/portmidi/+bug/93728 Oh, heh, looks like there already is someone who tries to do the same attempt as I do. Actually I have experienced similar issue (I even posted a wrong patch to this list) that will result in the same as this Debian bug. It was just about missing -lporttime on linking libportmidi.so and it is not a real problem in having separate those libs as separate. I'm using portmidi libs with Mono and it works on Linux, Mac and Windows. >> I kind of want to make those per-platform patches merged and make >> it build everything (so far it only builds libraries) but haven't >> spent time on it yet. > > Apart from the above described problems, your autotools patches work > very well, so I'm all for including them into the portmidi distribution > or maybe an "autotoolized" branch for beta testing should be created first. The problem is that those patches for each platform need to be unified. Hence even in a separate branch it is not possible to just apply them (unless you create three separate branches). While I have autotoolized them, I am by no means autotools magician :/ and I may have to spend extra time to do it. If someone can do it I'd greately appreciate :) Atsushi Eno _______________________________________________ media_api mailing list media_api@create.ucsb.edu http://lists.create.ucsb.edu/mailman/listinfo/media_api
