How do you build wxLua on Mac OS X (10.6.8) so that it uses LuaJIT2 instead of the standard Lua interpreter?
I have tried:
./configure --with-lua-prefix=/Users/finnw/LuaJIT-2.0.0-beta9
where /Users/finnw/LuaJIT-2.0.0-beta9 is the directory in which I built LuaJIT.
I have also tried copying src/libluajit.a to lib/liblua5.1.a and src/libluajit.so to lib/liblua5.1.so and various other combinations such as changing the extension from .so to .dylib
But still I always get Lua not LuaJIT (as can be verified by loading a script that requires the ffi module.)
How can I force it to link against LuaJIT2? And why does the configure --with-lua-prefix option not do what it claims to do?
The following works on Debian:
$ ./configure --with-lua-prefix=/path/to/luajit --enable-systemlua
which points at /path/to/luajit/include/lua5.1/*.h and /path/to/luajit/lib/liblua5.1.a.
--enable-systemlua ensures that it tries to find Lua at the prefix you specify, and will make configure fail rather than fall back on the Lua bundled with wxLua.
You'll also need to replace the two instances of luaI_openlib in wxlbind.cpp and wxlstate.cpp with luaL_openlib, as this is deprecated in 5.1 and not present in LuaJIT2.
Related
I downloaded the clang compiler directly from the prebuilt binary tar provided on the llvm website here. The tar file contains a standard directory hierarchy with bin, include, lib etc. Now I want to configure macports to use this compiler in such a way that when a subsequent port requires clang then this compiler's binary is used. Note that I do not want macports to download and install a separate copy of clang. Is it possible to do so?
DETAILS: The reason why I want to keep the clang installation in a separate place is because I often use scientific code, or other code, like chromium, and I use anaconda. I also have xcode installed and that provides its own version of compilers. Adding macports' compilers to the system makes my system almost unmanageable because it is often very difficult to ensure that the right runtime library and compilation time library are being used.
MacPorts does not support this, and there is also no unsupported way to get this done that I am aware of.
However, C++ software installed through MacPorts should always end up using the libc++ runtime (if you're on a system where it is the default). MacPorts is aware of the C++ runtime its ports use and tries to make sure all its ports use the runtime set as the cxx_stdlib in macports.conf (which defaults to your system's default).
I'm working on windows 7 64bit system using clozure cl (version 1.8-r15286m) with quicklisp installed.
I need some freetype2 bindings for common lisp. (map characters to glyphs + kerning info)
I've tried to install "cl-freetype2" using
(ql:quickload "cl-freetype")
from 32bit clozure cl, and I've run into several problems.
"grovel.lisp" (located in quicklisp/software/cffi_0.11.1/grovel/grovel.lisp) assumes that I have gcc installed at "c:/msys/1.0/bin/gcc.exe" (I have mingw-gcc in path, but not there). Fixed by replacing "c:/msys/1.0/bin/gcc.exe" with "gcc" in "grovel.lisp".
When trying to compile cffi bindings for freetype2, same file does not include drive letters when passing include directories to compiler (i.e. instead of -i"d:/somedir" it passes -i"/somedir" to gcc`).
"grovel.lisp" tries to include unix include directories.
I cannot fix #2 myself.
I found this discussions, tried both listed patches, and neither of them worked. (first one breaks cffi, because ccl can't find neither "namestring-prefix" function nor "pathname-prefix" function), second one does not fix the problem.
What can I do in this situation?
I'd prefer to avoid fixing "groveller" myself, I simply need some bindings for freetype2.
Basically, I need to be able to
Load truetype font.
Map unicode char to glyph.
Get kerning information for pair of glyphs.
Load glyph bitmap.
Any ideas?
Figured it out.
Installing cl-freetype2 via quicklisp requires fully functional installation of MinGW.
Ensure that mingw-gmp is installed. (mingw-get install gmp)
Ensure that mingw/bin directory is within system path (right click on "My Computer"->Properties->Advanced->Environment Variables). Is Set. Should be something like "D:/development/MinGW/bin " (assuming MinGW is installed in "d:/development").
Locate "grovel.lisp" within your ccl installation, and replace ""c:/msys/1.0/bin/gcc.exe" with "gcc". You don't have to do that if gcc is installed at this location.
Launch mingw shell.
download unpack and install latest Freetype2 tarball using ".configure && make && make install", similarly to unix enviornment.
Locate freetype-6.dll copy it into freetype.dll and move freetype.dll into location within system path.
(Assuming that MinGW is installed in "d:/development/MinGW"), create CPATH user environment variable with following context: D:\development\MinGW\msys\1.0\local\include\freetype2;D:\development\MinGW\msys\1.0\local\include. That is - if you didn't specify "/usr" prefix during freetype2 compilation.
From within mingw shell, launch wx86cl and try (ql:quickload "cl-freetype2"). It should work properly.
If it still doesn't work, in all your root drives create directory junctions to directory in which mingw is installed. (i.e. "c:/development" linking to "d:/development", etc).
I must admit that this was much hassle, so I still think that it'll be a better idea to make a small dll that provides minimal set of functions I need while using freetype internally, then load this dll using cffi. This should be much easier.
I am trying to use a toolbox which makes use of the Matlab's eigs() function. When I run this in Octave (3.6.4, installed via Homebrew on Mac OS X), the following is returned:
error: eigs: not available in this version of Octave
I have found a lot op potential solutions, about getting the ARPACK(-ng) program to work with Octave. I have tried more methods then I can remember, but none seemed to work.
Does anybody know the current status of Octave using the eigs() function? Is this possible, preferably by using packages in Homebrew?
Thanks.
I think you're referring to the fact that as of 3.6, Octave no longer comes with eigs, and depends on an external arpack library. From the Octave release notes:
Summary of important user-visible changes for version 3.6:
---------------------------------------------------------
...
** The ARPACK library is no longer distributed with Octave.
If you need the eigs or svds functions you must provide an
external ARPACK through a package manager or by compiling it
yourself. If a pre-compiled package does not exist for your system,
you can find the current ARPACK sources at
http://forge.scilab.org/index.php/p/arpack-ng
So you'll need an arpack library installed before installing Octave, somewhere visible to Octave. For homebrew, that means under /usr/local/.
Octave's configure file has arpack detection logic, and looks like it will detect arpack during the build process by default, and build against it if present. So Homebrew's octave should pick it up if you have it installed, even without special support for it in the formula.
There's no arpack formula in the current homebrew-science version, but there is an open pull request to add one: https://github.com/Homebrew/homebrew-science/pull/112. Go over there and comment to show support and maybe it'll get merged in soon. Once that's in, do brew install libarpack; brew install octave and your Octave may well pick up eigs. If it doesn't, then put in an issue against homebrew-science to add arpack support.
So, we all know that Mountain Lion doesn't ship with X11 anymore and users needing X11 are directed to download Xquartz. Xquartz installs to /opt, but it also symlinks X11 and X11R6 to /usr. But when building software that requires linking to X11 include files, I've discovered that I must pass an environment variable adding /usr/X11/include (or /opt/X11/include) to the library search path to get ./configure to find the X11 libraries. My question is why?
I've done some research on Google (many results pointing back to Stack Overflow), and I've read Apple's documentation, and these sources all indicate that there is no equivalent in OS X to the /etc/ld.so.conf file found in many (if not all) Linux distributions. Apple even states that DYLD_LIBRARY_PATH is empty by default. However, under Lion (with Apple's last 'official' X11 installed), the same ./configure scripts would find the X11 libraries without adding anything to the library search path.
So, why can't ./configure scripts find X11 libraries in Mountain Lion without explicit modification of the library search path?
Asked more than a year ago... but as I came here with a similar problem...
Note that in the mentioned ruby question, there was no library search path being modified.
That solution just set an environment variable that is picked up by many Makefiles as the flags for the C++ compiler. That example defined the build time -I ncludepath, i.e. where to search for .h eaders -- not libraries (which would have been a -L option to your compiler/linker). Both would have been build time options.
Whether LD_LIBRARY_PATH or DYLD_LIBRARY_PATH -- both are environment variables that are considered by the dynamic linker at runtime. (For more, see http://en.wikipedia.org/wiki/Dynamic_linker )
I have no pre-10.8 machine at hand, but guess that there might have been a symlink
/usr/include/X11 -> /opt/X11/include/X11 -- otherwise I have no Idea atm how
it could have worked before, assuming same sources...
This is another potential solution for such problems (just fixed my realvnc build):
$ autoconf
$ ./configure
So your question for "why?" could be eventually answered with: Because your sources contained a 'pre-built' configure script that was based on older autotools that did not include
/opt/X11/include as a potential location to search for X11 includes or simply did not get some of the above mentioned compile time flags right on your current system.
I have autoconf installed through homebrew -- ahh, great stuff, cheers.
I have a unix command line app (with big nasty makefile) that I'm trying to run on a mac. I am compiling it on a 10.6 system, with all of the appropriate libraries of course. The deployment environment is a 10.5 system, with no extra libraries.
I compiled without -dynamic, and it appears to have static libraries, correctly. When I run it on the 10.6 system, it works. However, when I run it on the 10.5 system, I get:
dyld: unknown required load command 0x80000022
I got this same error when I compiled things for the 10.6 system using the 10.5 xcode, so it looks like a version mis-match type problem. However, I used gcc-4.0, and
$CFLAGS = -isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5
so it SHOULD be set up for 10.5... any ideas?
thanks
Editing an ancient question:
I have the exact same problem on a different computer. This time I am at 10.5.8, fully update, the same executable works on 10.6 still.
Has anyone had any luck with this in the months since I asked this?
The reason for the dyld 0×80000022 error can be that, you are linking on OS X 10.6, and OS X 10.6 will use a load command (LC_DYLD_INFO_ONLY = 0×80000022) that OS X 10.5 does not understand.
To fix this, make sure you are using a deployment target by setting the environment variable just before your link command:
export MACOSX_DEPLOYMENT_TARGET=10.5
(or setenv MACOSX_DEPLOYMENT_TARGET=10.5)
You can always check if your executable uses the right load command like this:
otool -l executable
It will either show LC_DYLD_INFO_ONLY (without deployment target) commands or LC_DYLD_INFO (with deployment target).
I have been searching for the same issue, as I develop on 10.6 but must have a version that works on 10.5. In addition to the compiler flags above, you should add:
-no_compact_linkedit
It is described here:
http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPages/man1/ld.1.html
where it says:
Normally when targeting Mac OS X 10.6, the linker will generate compact information in the __LINKEDIT segment. This option causes the linker to instead produce traditional relocation information.
I got there from a discussion on the xcode-users mailing list about "unknown required load command 0x80000022".
i was able to solve this by passing -mmacosx-version-min=10.5 to the linker, e.g. --extra-ldflags="-mmacosx-version-min=10.5" passed to configure for ffmpeg which i was building shared. more info: http://lists.apple.com/archives/xcode-users/2009/Oct/msg00530.html
Depending on how many libraries you use, it may be difficult to get all of them linked statically. What does "otool -L your_binary' tell you?
In order to get a self-contained package for an application of my own, I made a custom MacPorts install in a non-standard directory, so that I could dynlink with the libraries from that directory and only be constrained in asking people to install the whole thing in the same place on their computers. Not great, not the Mac spirit at all, but it's an Unix app and you need to be familiar with Unix to use it anyway.
Good luck
Pascal
It turns out that there is a dynamic library load function (0x22) that got added at 10.5.6. The system I was running on was 10.5.5. I upgraded to 10.5.8, and everything runs!
Ok, SECOND solution, and NOT very satisfying, is to find a 10.5.8 computer, install the developer packages and re-compile... same for powerPC... sad but it will work...