Re: modules on osx: dlyd or dlopen, .so, .dylib or .bundle, xcode project????

[Graham Wakefield <lists@...>]

Hi,

Thanks for the detailed response!

1. so I opted for the .so suffix, to maintain Lua(Unix) rather than Apple portability (and an unmodified Lua core).

2. Thank you.  I modified my application build flags to -DLUA_USE_DLOPEN -DLUA_USE_POSIX.

3. Actually I'm not using gluax any more, that was copied from an older project. Right now I'm trying to embed just an unmodified Lua core to ensure library portability.

4. Yes, this was no doubt the real issue.  Thank you very much for your project settings - my library is working finally, though some of my project settings are different since I use the recommended -undefined dynamic_lookup and don't specify a bundle loader (for portability again). I'm not getting the forced lib prefix problem here. Since this is probably quite useful for the archives, I'll describe in detail what I did.  FWIW this is using Xcode 2.4 on OX 10.4.

I started with BSD->Dynamic Library, and here are the customized settings (All Build Configurations):

// or wherever lua includes are, e.g. /usr/local/include

Header Search Paths = $(PROJECT_DIR)/lua

// this makes with -bundle

Mach-O Type = Bundle

// ... doesn't work for -bundle

Compatibility Version = [ ]

Current Library Version = [ ]

// this means we don't need to link against the lua core nor a dynamic library/framework... Lua symbols can be found in the embedding application:

Other Linker Flags = -undefined dynamic_lookup

// this ensures the output is modname.so:

Product Name = modname

Executable Prefix = 

Executable Extension = so

Wrapper Extension = 

// this was advised as necessary, but I'm not sure why:

Perform Single-Obejct Prelink = [x]

// stripping symbols: (strip -x)

Strip Style = Non-Global Symbols

Strip Debug Symbols During Copy = [x]

Generate Debug Symbols = [ ]

// other settings:

Precompiled Headers Cache Path =

Prebinding = [ ]

Zerolink = [ ]

Scan All Source Files for Includes = [x]

Or in other words:

SHARED_PRECOMPS_DIR =

HEADER_SEARCH_PATHS = $(PROJECT_DIR)/lua

SCAN_ALL_SOURCE_FILES_FOR_INCLUDES = YES

MACH_O_TYPE = mh_bundle

PREBINDING = NO

ZERO_LINK = NO

DYLIB_CURRENT_VERSION =

DYLIB_COMPATIBILITY_VERSION =

OTHER_LDFLAGS = -undefined dynamic_lookup

GENERATE_MASTER_OBJECT_FILE = YES

PRODUCT_NAME = testmod

EXECUTABLE_PREFIX =

EXECUTABLE_EXTENSION = so

INSTALL_PATH = /usr/local/lib

STRIP_STYLE = non-global

COPY_PHASE_STRIP = YES

GCC_GENERATE_DEBUGGING_SYMBOLS = NO

The part in your Xcode project about 'custom executable' regards loading the Lua runtime to test (debug) your library.  In my case, I'm embedding Lua into an application so I can use that application as my runtime executable. The Debug configuration is only necessary for debugging; the distributed library should be built with Release.

On Oct 30, 2007, at 1:05 AM, Asko Kauppi wrote:

1. so/dylib/bundle

.so is used by people who emphasize portability. Apple never uses .so suffix.

.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:

http://osdir.com/ml/lang.realbasic.plugins/2007-01/msg00033.html

"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:

Hi all,

Having a headache trying to build an Xcode project for a lua module. I checked the wiki article, and raided the list archives, and found various contradictory answers.  Would like to know if there is a standard (which can also work as an Xcode project).

I checked existing lua modules, and I can find both .so and .dylib for OSX.

Likewise, I can find dyld and dlopen both recommended for OSX (with dyld being the default, but dlopen being recommended by Apple).

I followed the standard on the wiki [1], using -DGLUA_LUA51 -DLUA_USE_MACOSX for the main application embedding Lua, and using

 -bundle -undefined dynamic_lookup for the module library (being sure to not link against the Lua core).

But a bundle project in Xcode creates a whole folder of stuff, rather than a single binary. No matter what I name the bundle (.so, .dylib, .bundle) I get "file is not a bundle" error.  An OSX bundle is a folder - is Lua not respecting this?  If Lua expects a binary, shouldn't it be a dynamic library rather than a bundle? Sorry if I sound confused - I'm inexperienced at dynamic loading. But I suspect other Lua users on OSX may be too, but wanting to write extension library modules for Lua like me.

Is there actually a standard for building modules on OSX?  Does anyone have an Xcode project that conforms to it (or at least works without hacks) that they would be willing to share?

Thanks,

Graham

[1]  http://lua-users.org/wiki/BuildingModules

grrr waaa

www.grahamwakefield.net