On 18 Dec 2007, at 13:12, Maurits Lamers wrote:
As mentioned in a previous message, I tried to compile things with
---static, but that didn't do anything. Providing a symbolic link
to the dylib that is called doesn't do the trick, the error message
stays the same.
Immanuel Litzroth wrote on the list about a way to nudge guile into
using the .dylib extenstion instead of the .so when searching for
libraries.
To me this seems the most promising, especially with the future in
mind.
The best way is to read on the Apple Developer Connection site:
http://developer.apple.com/documentation/DeveloperTools/Conceptual/
DynamicLibraries/
There are special ways to create and call dynamic libraries. They can
be called for in the compilation process or called at runtime. If you
call for it in the compilation process, the dynamic library must be
present when the program runs. If you call it at runtime, then the
functions used (I think) have the same names dlsym, dladdr, dlclose,
and dlerror on both Mac OS X and GNU/Linux OS, only that the former
uses the file name ending ".dylib" and the latter ".so". The source
code should have a "#include <dlfcn.h>" in it"; see this header - can
be opened in Xcode using <cmd>-D. The library formats are different,
so one can't compile it on GNU/Linux OS and use the binary object
code on Mac OS X. When making Guile into a Mac OS dynamic library, in
addition to compile it right, it should have the file name
ending .dylib.
Hans Åberg
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
