From: Ryan S. <rya...@us...> - 2008-08-01 07:37:25
|
On Jul 30, 2008, at 09:04, Albert Graef wrote: > Ryan Schmidt wrote: > >> And the reason looks to be that pure is linking with libpure without >> specifying the directory it's located in: > > Well, that probably means that you have to hardcode the install path > into the binaries, so maybe adding something like -install_name > /mp/lib/libpure-0.4.dylib to the link line for libpure-0.4.dylib > helps. That could help, but I'm not clear on what to add where to test this. > Does MacPorts have any recommendendations concerning the linking of > shared libs? I don't think so... it's outside the scope of what MacPorts does. MacPorts takes software which can be compiled and run on Mac OS X and packages it for easy installation. MacPorts does not "port" software in the sense of rewriting software in order to make it compile on Mac OS X. >> Finally, "libpure-0.5.dylib" is a peculiar name; I would have >> expected something more like "libpure.0.5.dylib". > > Peculiar, but not unheard of. :) You're right... I see I have libraries installed with names like libglib-2.0.dylib, libapr-1.0.3.2.dylib... I guess you're in good company. :) I retract my objection. > The reason is that I want to make sure > that the interpreter always picks up the libpure which *exactly* > matches > the version number of the interpreter. This allows different > versions of > the interpreter to be installed on the same system. Using some > major/minor/age versioning scheme will make sense as soon as the > runtime > library begins to stabilize, but we're not there yet. |