Jan Krutisch | 7 Nov 00:47 2009
Picon

Status of 64bit support?

Hi,

I'm currently trying to build a Ruby interface for portmidi. Now, my
problem is that Ruby 1.8.7 on my Snow Leopard MacBookPro is a 64bit
application, so every extension needs to be built in 64 bit.

The changelog of portmidi suggests that there has been some work
trying to make portmidi 64bit compatible, but currently the build
scripts explicitly disable 64 bit output.

To get me up to speed, I simply changed the settings by hand in XCode,
compiled the library and then copied the lib to my interface folder,
which can only be a temporary solution, but at least it worked.

My question is this: Is there anything that desperately needs to be
changed in code in order to make it 64 bit safe?(I must confess that I
don't exactly know what that would mean (I'm a ruby coder by purpose,
you know :) ), and if there's anything I could to do to help,
especially with testing.

On a sidenote, currently the mac build/install seems to be broken, I
needed to do something like

sudo env PF=/local make -f pm_mac/Makefile.osx install

to get it at least to install (it tried to install to /include and /lib before)

Thanks and take care,

Jan
(Continue reading)

Roger Dannenberg | 9 Nov 02:37 2009
Picon

Re: Status of 64bit support?

Jan Krutisch wrote:
Hi, On Sun, Nov 8, 2009 at 6:37 PM, Roger Dannenberg <rbd-ETDLCGt7PQU3uPMLIKxrzw@public.gmane.org> wrote:
Jan,   I went through the code fairly carefully to make it 64-bit compatible, including turning on some compiler warnings for 64-bit code in xcode and actually cross-compiled 64-bit libraries, but I did not do any actual testing. I would be (pleasantly) surprised if everything actually works, so please report any problems (and thanks for reporting initial success).
I actually didn't find any obvious problems, but there are quite a few warnings in the compilation process. Apart from that, it looks quite stable in 64bit and I'll happily report all errors I come across.
I thought I eliminated the warnings under xcode, but it may depend on settings. I'll check again. It may not be practical to eliminate all warnings.
  I'll confess that I have not put much effort into installation. I thought the current xcode project was set up to do installs. I hate to install on my development machine because I always end up linking to an old installed library instead of the current version I'm trying to test. I'll take a look.   The pm_mac/Makefile.osx might work, but it is more-or-less legacy code now that I'm using Cmake. I suppose I should verify that Cmake can build a proper makefile, then remove Makefile.osx, Makefile.linux, etc. from the Portmidi sources.
Hm, I was under the impression that Makefile.osx does use cmake, so there's an easier way to build and install?
It should be possible to generate a makefile on OS X with the cmake files, but I haven't tried it. I'm still dealing with various cmake/configuration issues, but I think things will settle down soon.
Anyway, thanks for your feedback. I'll try to stresstest the lib a bit :)

_______________________________________________
media_api mailing list
media_api@...
http://lists.create.ucsb.edu/mailman/listinfo/media_api
Paul Brossier | 13 Nov 16:02 2009

patches from portmidi debian package


Hi all,

Just to let you know that I have a number of patches in the current
debian package for portmidi:

http://bzr.debian.org/loggerhead/users/piem/portmidi/files/head:/debian/patches/?

The following patches fix compilation warnings:
01_pmlinux.diff
02_pmlinuxalsa.diff
06_pm_test_mm.diff
07_pm_test_sysex.diff
08_pm_test_qtest.diff

03_pm_test_Makefile.diff adds a makefile for the test directory and gets
install in /usr/share/doc/libportmidi-dev/examples :

05_makefile.diff installs .so.0.0.0 libtool like libraries

And 09_makefile_linking.diff adds -lpthread to -lasound (see
http://bugs.debian.org/556070)

It would be nice if these patches could be merged in trunk. It would
also be nice to have release tarballs in the tar.gz format, since zip
files need to be repackaged for a debian source package.

The package doesn't use cmake yet, though I guess it should. I got this
error when running 'cmake . && make', and didn't look further:

Linking C shared library /Release/libpmjni.so
/usr/bin/ld: fatal error: /Release/libpmjni.so: open: No such file or
directory

Best, Paul
Roger Dannenberg | 13 Nov 18:49 2009
Picon

Re: patches from portmidi debian package

Thanks, Paul, I'll take a look. -Roger
Maurizio De Cecco | 14 Nov 19:20 2009

Problem launching pmdefaults on MacOSX

I downloaded the latest version of pmdefaults (184, i think) and
runned it on a Mac Pro (early 2009) with Leopard, and i get an error at
startup, saying that it cannot link the libpmjni.dylib library because
the architecture of the universal library do not match the current one.

What the deal ? I have configured the system to use Java 1.6.
Should i build it from the sources ?

By the way, how the portmidi defaults are stored ?

Thanks,
Maurizio De Cecco

--

-- 
Music:    http://www.myspace.com/mauriziodececco
Blog:     http://maurizio.dececco.name/
Software: http://www.jmax-phoenix.org/
Roger Dannenberg | 15 Nov 00:05 2009
Picon

Re: Problem launching pmdefaults on MacOSX

Are you running on a 32-bit or 64-bit system? I think libpmjni.dylib is 
only compiled for 32-bit architectures. If this is the problem, maybe 
the fix is easy, but the 64-bit version is not included anywhere because 
I have not tested (preliminary reports are good though).

I should have documented which Java version I used on the Mac -- I see 
in the project.pbxproj file that the Java version is set to 1.5, so 
maybe that's the problem.

PortMidi defaults are stored using the Java preferences class -- it does 
different things on different platforms, and so the different 
implementations of PortMidi use different strategies to retrieve the 
preference data. On the mac, preferences are in binary files and there 
are system calls to locate the preferences folder. The file is 
com.apple.java.util.prefs.plist.

Given the 64-bit and Java version questions, I'd say rebuild from 
sources and let us know what happens.

-Roger

Maurizio De Cecco wrote:
> I downloaded the latest version of pmdefaults (184, i think) and
> runned it on a Mac Pro (early 2009) with Leopard, and i get an error at
> startup, saying that it cannot link the libpmjni.dylib library because
> the architecture of the universal library do not match the current one.
>
> What the deal ? I have configured the system to use Java 1.6.
> Should i build it from the sources ?
>
> By the way, how the portmidi defaults are stored ?
>
> Thanks,
> Maurizio De Cecco
>
>
>   
Albert Santoni | 17 Nov 23:38 2009

No install target on OS X

Hello,

After running cmake . and make, "make install" complains there is no
install target on OS X 10.5. Am I missing something or did the switch
to cmake break the install target?

I didn't realize PortMidi switched build systems and I had just made a
patch that solved a problem in your Makefile with the install_name
being incorrect on OS X, then I upgraded and found out you totally
switched to cmake. I take it the documentation in
pm_mac/README_MAC.txt is out of date?

make -f pm_mac/Makefile.osx install   doesn't work anymore... the
$(PG) variable isn't defined anywhere so it assumes we have a blank
path prefix....

Help?

Thanks,
Albert

Mixxx Developer
http://www.mixxx.org
Roger Dannenberg | 18 Nov 00:57 2009
Picon

Re: No install target on OS X

Yes, I think the install target (which I thought Cmake automated) is 
broken. Previously, the install path was $(PF) which was set to 
/usr/local. I think you can set that in the makefile or from the command 
line (or just look at the simple commands in Makefile.osx to see how 
install was working before). I'm still trying to iron out problems with 
Cmake and the build system, so I appreciate your input (esp. 
README_MAC.txt -- I thought I made a pass through that, but I'll look 
again.) -Roger

Albert Santoni wrote:
> Hello,
>
> After running cmake . and make, "make install" complains there is no
> install target on OS X 10.5. Am I missing something or did the switch
> to cmake break the install target?
>
> I didn't realize PortMidi switched build systems and I had just made a
> patch that solved a problem in your Makefile with the install_name
> being incorrect on OS X, then I upgraded and found out you totally
> switched to cmake. I take it the documentation in
> pm_mac/README_MAC.txt is out of date?
>
> make -f pm_mac/Makefile.osx install   doesn't work anymore... the
> $(PG) variable isn't defined anywhere so it assumes we have a blank
> path prefix....
>
> Help?
>
> Thanks,
> Albert
>
> Mixxx Developer
> http://www.mixxx.org
> _______________________________________________
> media_api mailing list
> media_api@...
> http://lists.create.ucsb.edu/mailman/listinfo/media_api
>
>   
Albert Santoni | 19 Nov 08:53 2009

Re: No install target on OS X

Hi Roger,

Attached is a patch that resolves my issues and makes PortMidi install
on OS X. It also sets the INSTALL_NAME_DIR flag, which is required for
OS X dylibs to behave nicely in some situations [1]. However, cmake
doesn't appear to be stitching that path into the dylib correct, it
instead just makes the library's id "libportaudio.dylib". This looks
like a bug in cmake to me, but in any event, it seems like it's still
enough to fix my problems with Mixxx even though it's not 100%
correct.

I changed that Linux install stuff to apply to OS X as well, I'm not
quite sure why it wasn't that way before. Unless you want to build
PortMidi as an OS X "framework", I would recommend keeping the install
procedure the same as for Linux because that seems to be the de facto
standard.

I also had to change the paths to portmidi.h and porttime.h, which
hopefully doesn't break the install target on other platforms. When
building on OS X, cmake treats those paths as relative to the pm_dylib
directory.

Please let me know if you have any comments or if you commit it
because I need to pass along build instructions for PortMidi to
Mixxx's OS X packager soon. We're in the final phases of unifying
Mixxx's MIDI code into a single PortMidi-based backend for all
platforms which we plan on including in our next release. If you're
not familiar with our project, Mixxx is open source cross-platform DJ
software and gets quite a few downloads, so hopefully we'll be able to
increase the amount of testing PortMidi receives.

Thanks,
Albert

[1] http://qin.laya.com/tech_coding_help/dylib_linking.html

On Tue, Nov 17, 2009 at 3:57 PM, Roger Dannenberg <rbd@...> wrote:
> Yes, I think the install target (which I thought Cmake automated) is broken.
> Previously, the install path was $(PF) which was set to /usr/local. I think
> you can set that in the makefile or from the command line (or just look at
> the simple commands in Makefile.osx to see how install was working before).
> I'm still trying to iron out problems with Cmake and the build system, so I
> appreciate your input (esp. README_MAC.txt -- I thought I made a pass
> through that, but I'll look again.) -Roger
>
> Albert Santoni wrote:
>>
>> Hello,
>>
>> After running cmake . and make, "make install" complains there is no
>> install target on OS X 10.5. Am I missing something or did the switch
>> to cmake break the install target?
>>
>> I didn't realize PortMidi switched build systems and I had just made a
>> patch that solved a problem in your Makefile with the install_name
>> being incorrect on OS X, then I upgraded and found out you totally
>> switched to cmake. I take it the documentation in
>> pm_mac/README_MAC.txt is out of date?
>>
>> make -f pm_mac/Makefile.osx install   doesn't work anymore... the
>> $(PG) variable isn't defined anywhere so it assumes we have a blank
>> path prefix....
>>
>> Help?
>>
>> Thanks,
>> Albert
>>
>> Mixxx Developer
>> http://www.mixxx.org
>> _______________________________________________
>> media_api mailing list
>> media_api@...
>> http://lists.create.ucsb.edu/mailman/listinfo/media_api
>>
>>
>
>
Attachment (osx_cmake_install_albert.diff): application/octet-stream, 1240 bytes
_______________________________________________
media_api mailing list
media_api@...
http://lists.create.ucsb.edu/mailman/listinfo/media_api
Roger Dannenberg | 19 Nov 17:31 2009
Picon

Re: No install target on OS X

Albert,
    Thanks much for your input. I've been working on the win32 and 
python side for a bit now, but I'll switch back to OS X and do some 
testing and integration with your code.
    So far, I've been developing with xcode and I think it's important 
to have a usable xcode project for PortMidi. One of the disappointments 
of Cmake is that it wires itself into xcode projects so that you really 
cannot use xcode without also installing and using Cmake. For example, 
Cmake inserts absolute paths into xcode, making it impossible to move 
the project to another directory or machine.
    (I just mention this because your email talked about relative paths.)

    Thanks,
    Roger

Gmane