 |
lua-l archive |
|
|
||
|
1. so/dylib/bundle .dylib is used for regular dynamic libraries (s.a. liblua.dylib). .bundle is used for runtime-loadable dynamic libraries (plugins); these do differ in OS X from dylib's, unlike on some other platforms (Linux, Win32). Stock Lua LUA_CPATH for OS X only looks for .so suffixes, but the fink distribution allows both .so and .bundle. For modules brought into fink, I recommend .bundle, but it really does not matter. 2. dyld/dlopen The dyld/dlopen issue is a separate one, and one where standpoints have changed over time. This explains contradictory statements to be found on the net (check their years!). Current understanding is, OS X Lua is best compiled using LUA_USE_DLOPEN and LUA_USE_POSIX. The LUA_DL_DYLD mode could be eliminated from the codebase. The fink Lua >= Lua 5.1.2-3 uses LUA_USE_DLOPEN. ( I think websites should change color, getting old. Fading colors and crappy corners would show one, it's an old information you're reading. Too bad they don't.. ;P ) 3. gluax You seem to be using gluax.[ch] for the module making (-DGLUA_LUA51). You don't need -DLUA_USE_MACOSX in this case; it's for building Lua itself. Here's a sample on how my Lua Lanes builds on OS X: ** Lua 5.1 native module (out/macosx-powerpc/lua51-lanes.bundle): Darwinpowerpc ** cc -I/sw/include -L/sw/lib -llua -lm -bundle -Wall -O2 -o out/macosx-powerpc/lua51-lanes.bundle -DGLUA_LUA51 gluax.c gluax_static.c lanes.c 4. Bundles vs. bundles This might be your _real_ issue. :) Apple unfortunately recycles the 'bundle' word for both dynamic library plugins, and "application bundles", which the XCode wizard most likely intends to build. Scrap that, just ignore. This would also explain the "file is not a bundle". ;) Since it's an executable application. I would simply take "Dynamic Library > BSD Dynamic Library" (the simplest) and then make sure "-bundle" is among the compiler flags. In fact, here are the _modified_ parts of a plugin XCode project (Lanes): SDK path /Developer/SDKs/MacOSX10.4u.sdk Precompiled headers cache path <empty> Header search ../../gluax /sw/include Library search /sw/lib Scan all sources for includes [x] Mach-O type bundle (means: library bundle, THIS is the important one) Prebinding [ ] Bundle loader /sw/bin/lua (the app to use for running your module) Current library version <empty> Compatibility version <empty> Other linker flags -framework Cocoa (if you do any OS X native stuff, in Objective-C) Perform single object prelink [x] Prelink libraries <empty> Product name lua51-lanes (anything goes..) Executable prefix <empty> (but still forces 'lib' there....!) Executable extension bundle Preprocessor macros GLUA_LUA51 _GNU_SOURCE=1 _THREAD_SAFE The XCode project notes seems to list some issues worth noting (I've already forgotten them!): << To use this XCode project, set "active build configuration" to Debug. You may need to add "custom executable" to the "Executables" tree of the project, with: - path /sw/bin/lua - custom directory /Users/xxx/.../SDL/ - arguments "test.lua" - environment LUA_CPATH xcode/build/Debug/lib?.bundle --- How to NOT have the "lib" prefix for bundles? Tried everything, still XCode places it there. :(( /usr/bin/g++-4.0 -o /Users/abisoft/Slug/public/2007/SDL/xcode/build/Debug/liblua51-sdl.bundle ... Have to change the LUA_CPATH instead, so we can debug with this. --- AK 25.6.2007 (solved): After changing dylib->bundle there were some issues, same as: "Perform single-object prelink" needs to be ticked. << So, in addition I've got a "Lua 5.1" entry under the "Executables" GUI tree (gosh, should really send this project file to you; maybe I will) Please ask for more details if necessary. -asko Graham Wakefield kirjoitti 30.10.2007 kello 8:53:
|