[gambit-list] Building Gambit for recent iOS
mikel evins
mevins at me.com
Wed Dec 22 11:29:55 EST 2010
On Dec 22, 2010, at 8:08 AM, Marc Feeley wrote:
>
> On 2010-12-22, at 2:00 AM, mikel evins wrote:
>
>>
>> On Dec 22, 2010, at 12:08 AM, mikel evins wrote:
>>
>>>
>>> Now I'm bogged down in trying to figure out the right sequence of operations and the right flags to use to build libraries from Scheme sources.
>>
>> My question is pretty vague (I didn't want to burden the list with voluminous error messages illustrating the various things I tried).
>>
>> Here's a more specific question:
>>
>> When I do the following sequence of things:
>>
>> gsc -:~~bin=${GAMBIT_HOME}/bin,~~lib=${GAMBIT_HOME}/lib,~~include=${GAMBIT_HOME}/include -f -link -flat -o src/libdelectus.c ${SCM_SRC_FILES} > /dev/null
>>
>> gsc -:~~bin=${GAMBIT_HOME}/bin,~~lib=${GAMBIT_HOME}/lib,~~include=${GAMBIT_HOME}/include -obj ${C_SRC_FILES} src/libdelectus.c
>>
>> gcc ${GCC_FLAGS} -bundle ${C_OBJ_FILES} src/libdelectus.o -o src/libdelectus.dylib -lgambc
>>
>>
>> I see the following error message:
>>
>> ld: duplicate symbol b_::___G(void)in /usr/local/gambit/MacOSX/lib/libgambc.a(_gambc.o) and src/libdelectus.o
>>
>> What am I doing wrong?
>
> You should be using an incremental link file, not a flat link file (in other words drop the -flat option). Here's what worked for me:
>
> GSC="gsc -:=${GAMBIT_HOME}"
> SCM_SRC_FILES="src/a.scm src/b.scm"
> C_SRC_FILES="src/a.c src/b.c src/c.c"
> C_OBJ_FILES="src/a.o src/b.o src/c.o"
> GCC_FLAGS=""
>
> ${GSC} -f -link -o src/libdelectus.c ${SCM_SRC_FILES}
>
> ${GSC} -obj ${C_SRC_FILES} src/libdelectus.c
>
> gcc ${GCC_FLAGS} -bundle ${C_OBJ_FILES} src/libdelectus.o -o src/libdelectus.dylib -L${GAMBIT_HOME}/lib -lgambc
>
> If you generate a flat link file, the link file will contain a C definition for all the global variables that are defined and referenced in the Scheme source code (for example "cons"). So if at the static linking you specify "-lgambc" then you will get a duplicate symbol because src/libdelectus.o and the Gambit library both define "cons", etc
>
> You could use a flat link file if you add to the Gambit link command all the sources of the Gambit library. But that is cumbersome and not needed here.
>
> In the process of testing your code I discovered a problem with the Gambit runtime on Mac OS X. Apparently the variable "environ" is not defined in the "bundle" C runtime library. So you'll get the following C linking error:
>
> Undefined symbols:
> "_environ", referenced from:
>
> The solution is to rebuild Gambit after modifying lib/os.h so that
>
> #ifdef USE_environ
> ___BEGIN_C_LINKAGE
> extern char **environ;
> ___END_C_LINKAGE
> #endif
>
> becomes
>
> #ifdef USE_environ
> #if 1
> #include <crt_externs.h>
> #define environ (*_NSGetEnviron())
> #else
> ___BEGIN_C_LINKAGE
> extern char **environ;
> ___END_C_LINKAGE
> #endif
> #endif
>
> I'll commit a more permanent fix soon.
This advice solved the problem of building the dylib; using it in an XCode project is still not working, though.
I found that if I included code like that from tests/client.c in the main.m source file of an XCode project, defining SCHEME_LIBRARY_LINKER as advised ("the name of the Scheme library prefixed with "____20_" and suffixed with "__"") resulted in a link error, with the linker complaining that no such symbol was found. In the same test, I used c-define to define a procedure, and its symbol was also not found.
I tried using the default "" arg to c-define, and also tried using "extern" for the scope; no dice.
I included a .h that declared the function in question, following the example in server.h, and I added the dylib to the XCode project as a "linked library", following the usual practice as per Apple's docs. It looks like XCode doesn't see any symbols in the dylib when linking a project.
--me
The definition is in the source of the library file that I generated using the
More information about the Gambit-list
mailing list