I haven't had any success building Gambit for recent versions of Apple's iOS SDK. I've tried monkeying with the makefiles by hand, and tweaking the configure scripts that James Long and a couple of other people have created, but no joy, so far. I've succeeded in this sort of effort before on my own, and presumably can again, but I thought before pouring many hours down the drain I'd ask whether anyone else has already done it and is willing to share their configuration, or the steps they followed to get it. I'm using the iOS 4.2 SDK, and attempting to build Gambit 4.6.0. --me
On 2010-12-11, at 6:29 PM, mikel evins wrote:
I haven't had any success building Gambit for recent versions of Apple's iOS SDK. I've tried monkeying with the makefiles by hand, and tweaking the configure scripts that James Long and a couple of other people have created, but no joy, so far.
I've succeeded in this sort of effort before on my own, and presumably can again, but I thought before pouring many hours down the drain I'd ask whether anyone else has already done it and is willing to share their configuration, or the steps they followed to get it.
I'm using the iOS 4.2 SDK, and attempting to build Gambit 4.6.0.
--me
_______________________________________________ Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
Let me know if this doesn't help. Marc Begin forwarded message:
From: Marc Feeley <feeley@iro.umontreal.ca> Date: November 4, 2010 3:21:59 PM EDT To: Francois Magnan <magnan@categoricaldesign.com> Cc: Gambit-iphone@iro.umontreal.ca Subject: Re: [Gambit-iphone] Compiling Gambit for iOS4
On 2010-11-04, at 2:10 PM, Francois Magnan wrote:
Hi,
I tried to compile Gambit 4.6.0 for the iPhone with iOS4.1 and after many different tries I was unsuccessful. I tried to follow James Long instructions, I tried to apply Alex Quieroz patch, I tried with earlier versions of Gambit. It always fails for me.
I pasted parts of a sample compile session below. It seems that configure doesn't work as expected since make runs it again. If somebody on this list could compile the latest Gambit for Simulator and iOS and make it available somewhere it would be greatly appreciated. I offer myself to host those files if needed.
Thank you, Francois Magnan
I'm in the process of making an iPhone sample application to include with the Gambit distribution. I'm hoping to finish that soon. In the meantime I can give you a script I have used successfully to build the Gambit runtime for the iPhone, both the actual device and the simulator. Just run the shell script. It downloads Gambit, builds it for Mac OS X, iPhone device, and iPhone simulator.
Marc
_______________________________________________ Gambit-iphone mailing list Gambit-iphone@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-iphone
On Dec 12, 2010, at 6:44 AM, Marc Feeley wrote:
On 2010-12-11, at 6:29 PM, mikel evins wrote:
I haven't had any success building Gambit for recent versions of Apple's iOS SDK. I've tried monkeying with the makefiles by hand, and tweaking the configure scripts that James Long and a couple of other people have created, but no joy, so far.
I've succeeded in this sort of effort before on my own, and presumably can again, but I thought before pouring many hours down the drain I'd ask whether anyone else has already done it and is willing to share their configuration, or the steps they followed to get it.
I'm using the iOS 4.2 SDK, and attempting to build Gambit 4.6.0.
--me
_______________________________________________ Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
Let me know if this doesn't help.
THanks; I'll give it a try at once.
On Dec 12, 2010, at 1:58 PM, mikel evins wrote:
On Dec 12, 2010, at 6:44 AM, Marc Feeley wrote:
I'm using the iOS 4.2 SDK, and attempting to build Gambit 4.6.0.
--me
Let me know if this doesn't help.
THanks; I'll give it a try at once.
I had to change the references in the script from iOS SDK 4.1 to 4.2; after that, all three builds succeeded, and a quick check of the csc script showed that it runs as expected. Thanks very much! Barring unforeseen complications, I'm off to the races again. --me
On Dec 12, 2010, at 7:44 AM, Marc Feeley wrote:
On 2010-12-11, at 6:29 PM, mikel evins wrote:
I haven't had any success building Gambit for recent versions of Apple's iOS SDK. I've tried monkeying with the makefiles by hand, and tweaking the configure scripts that James Long and a couple of other people have created, but no joy, so far.
I've succeeded in this sort of effort before on my own, and presumably can again, but I thought before pouring many hours down the drain I'd ask whether anyone else has already done it and is willing to share their configuration, or the steps they followed to get it.
I'm using the iOS 4.2 SDK, and attempting to build Gambit 4.6.0.
--me
_______________________________________________ Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
Let me know if this doesn't help.
It certainly did help, and I got Gambit built for Mac OS X, and for iOS 4.2, both for the simulator and the device. 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. I want to use the same sources to build a shared library for Mac OS X, and a static library for iOS. So far, my extrapolations from the examples given in the Gambit manual yield only copious error messages. I'm sure the problem is that I simply haven't figured out the right magic set of flags for these targets, and that eventually I'll stumble onto them. But if you happen to know them off the top of your head and feel like typing them into a reply, I'd be grateful for the time saved. --me
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? --me
A little more information, as I attempt to unravel the reasons for build failures with Gambit on Mac OS X and iOS: I figured I'd eliminate as many variables as possible by reproducing verbatim the examples in the Gambit 4.6.0 manual (pp 14-17). I created the source files used in the examples (m1.c, m2.scm, m3.scm), and compiled and linked using the example commands from those pages. Building the executable worked just fine (once I added -L/usr/local/gambit/MacOSX/lib so that gsc could find libgambc). I was not so lucky when I tried the "Building a loadable library" example on page 16: cairagor:gambit_fun mikel$ gcc -L/usr/local/gambit/MacOSX/lib -bundle m1.o m2.o m3.o foo.o1.o -o foo.o1 -lgambc ld: duplicate symbol ____G_cons in /usr/local/gambit/MacOSX/lib/libgambc.a(_gambc.o) and foo.o1.o Perhaps the latest Apple GCC needs additional args? Or perhaps Gambit or its configuration has changed so that additional flags are needed? --me
AFAIK there's people who have successfully compiled Gambit on both platforms you mention, and documented it quite well in on the ML. I don't know exactly though. When you dug out the answer to your question, would you be interested to publish your results here? I suppose your question is how to sucessfully do (compile-file) i.e. gcc gambit-made C files, and gsc -exe / link object files to an executable, all this done outside of the xcode programming environment. To search on the ML, add " site: https://mercure.iro.umontreal.ca/pipermail/gambit-list/" to your search engine query. Kind regards 2010/12/22 mikel evins <mevins@me.com>
A little more information, as I attempt to unravel the reasons for build failures with Gambit on Mac OS X and iOS:
I figured I'd eliminate as many variables as possible by reproducing verbatim the examples in the Gambit 4.6.0 manual (pp 14-17).
I created the source files used in the examples (m1.c, m2.scm, m3.scm), and compiled and linked using the example commands from those pages. Building the executable worked just fine (once I added -L/usr/local/gambit/MacOSX/lib so that gsc could find libgambc).
I was not so lucky when I tried the "Building a loadable library" example on page 16:
cairagor:gambit_fun mikel$ gcc -L/usr/local/gambit/MacOSX/lib -bundle m1.o m2.o m3.o foo.o1.o -o foo.o1 -lgambc ld: duplicate symbol ____G_cons in /usr/local/gambit/MacOSX/lib/libgambc.a(_gambc.o) and foo.o1.o
Perhaps the latest Apple GCC needs additional args? Or perhaps Gambit or its configuration has changed so that additional flags are needed?
--me
_______________________________________________ Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
On Dec 22, 2010, at 4:48 AM, Mikael wrote:
AFAIK there's people who have successfully compiled Gambit on both platforms you mention, and documented it quite well in on the ML. I don't know exactly though.
Quite so. I'm one of them.
When you dug out the answer to your question, would you be interested to publish your results here?
I suppose your question is how to sucessfully do (compile-file) i.e. gcc gambit-made C files, and gsc -exe / link object files to an executable, all this done outside of the xcode programming environment.
No, that's not my question. My question is why, when I follow the example given in the Gambit manual letter-for-letter, the build fails with a "duplicate symbol" error. Do other people who follow that example exactly on recent versions of Mac OS X with recent versions of Apple dev tools see the same error? If so, then presumably something in a recent Gambit or Apple release has introduced a build problem. If not, then presumably some quirk of my local configuration is causing a link problem. The only obvious idiosyncrasy of my build environment is that instead of building and installing Gambit in the normal way, I built it from recent Gambit sources using a config script that Marc provided for the purpose of simultaneously building Gambit for three environments: Mac OS X, the iOS Simulator, and iOS devices. Consequently, I have three parallel installs of Gambit, and I must, of course, pass suitable -I and -L flags when building, so that Gambit finds the right files. None of this makes it obvious to me why following the instructions on page 16 of the manual (while of course adding the appropriate -L to find the right gambit library) would result in a "duplicate symbol" error, but it's certainly possible that I overlooked something. --me
Aha, I get your question. This is not my field of expertise. Generally I'd try to debug it from an as basic approach as possible. Look at the error message you got - cairagor:gambit_fun mikel$ gcc -L/usr/local/gambit/MacOSX/lib -bundle m1.o
m2.o m3.o foo.o1.o -o foo.o1 -lgambc ld: duplicate symbol ____G_cons in /usr/local/gambit/MacOSX/lib/libgambc.a(_gambc.o) and foo.o1.o
the compiler complains cons is duplicate. That's a runtime library function, afaik. Perhaps gcc somehow tries to link more than one variant/version of the runtime library object file (*gambc*.o/.a) at the same time? What files do you have in /usr/local/gambit/MacOSX/lib? What are all the symbols defined/exported by the involved object files? Brgds 2010/12/22 mikel evins <mevins@me.com>
On Dec 22, 2010, at 4:48 AM, Mikael wrote:
AFAIK there's people who have successfully compiled Gambit on both platforms you mention, and documented it quite well in on the ML. I don't know exactly though.
Quite so. I'm one of them.
When you dug out the answer to your question, would you be interested to publish your results here?
I suppose your question is how to sucessfully do (compile-file) i.e. gcc gambit-made C files, and gsc -exe / link object files to an executable, all this done outside of the xcode programming environment.
No, that's not my question.
My question is why, when I follow the example given in the Gambit manual letter-for-letter, the build fails with a "duplicate symbol" error. Do other people who follow that example exactly on recent versions of Mac OS X with recent versions of Apple dev tools see the same error? If so, then presumably something in a recent Gambit or Apple release has introduced a build problem. If not, then presumably some quirk of my local configuration is causing a link problem.
The only obvious idiosyncrasy of my build environment is that instead of building and installing Gambit in the normal way, I built it from recent Gambit sources using a config script that Marc provided for the purpose of simultaneously building Gambit for three environments: Mac OS X, the iOS Simulator, and iOS devices. Consequently, I have three parallel installs of Gambit, and I must, of course, pass suitable -I and -L flags when building, so that Gambit finds the right files.
None of this makes it obvious to me why following the instructions on page 16 of the manual (while of course adding the appropriate -L to find the right gambit library) would result in a "duplicate symbol" error, but it's certainly possible that I overlooked something.
--me
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. Marc
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.
Thanks; I did, in fact, run into that problem with the "_environ" symbol, when trying non-flat links. I'll try your suggestions soon. For context, Delectus is a Cocoa app whose core logic (and, in fact about 90% of the code by line-count) is written in Gambit. I'm running into these issues as I reorganize the code to make the core logic independent of Mac OS X, so that it can be used across OS X, iOS, Windows, and some web apps. Naturally, I prefer it if I can keep the core engine in Gambit across all those platforms. Thanks for the timely help. --me
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
On 2010-12-22, at 11:29 AM, mikel evins wrote:
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.
I believe that on Mac OS X you have to add the C linker flags -flat_namespace -undefined suppress if you want to preserve the symbols. Also, the bit about suffixing the library name with "__" is only if your link file (without the extension) ends with "_". In your case you force it to "libdelectus" (because of the -o src/libdelectus.c) so don't add a "__". Marc
On Dec 22, 2010, at 10:37 AM, Marc Feeley wrote:
I believe that on Mac OS X you have to add the C linker flags
-flat_namespace -undefined suppress
if you want to preserve the symbols.
In which build phase? I tried a couple of permutations without success. (Thanks again for the hand-holding.) --me
On Dec 22, 2010, at 10:37 AM, Marc Feeley wrote:
I believe that on Mac OS X you have to add the C linker flags
-flat_namespace -undefined suppress
if you want to preserve the symbols.
I've tried introducing those flags in various places, but no luck so far. The linker always complains that the init function and any symbols I try to export are not found. I have the sense that I am overlooking some very obvious linker behavior. I'll try again later after I've had some sleep. --me
On Dec 22, 2010, at 11:29 AM, mikel evins wrote:
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.
Hopefully Marc's advice about C linker flags will solve this, but I'd like to ask, on behalf of myself and the many lurking here, that once you get this working you put up a blog post or a message here detailing all that's necessary to get a working gambit iOS 4.2 project under Xcode. I'm sure there are many in the scheme/lisp community who would welcome the opportunity to develop iOS apps using gambit - I know that some people at Clozure have already expressed interest for example. good luck and best wishes, Ralph Raffael Cavallaro raffaelcavallaro@me.com
On Dec 22, 2010, at 10:45 AM, Raffael Cavallaro wrote:
On Dec 22, 2010, at 11:29 AM, mikel evins wrote:
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.
Hopefully Marc's advice about C linker flags will solve this, but I'd like to ask, on behalf of myself and the many lurking here, that once you get this working you put up a blog post or a message here detailing all that's necessary to get a working gambit iOS 4.2 project under Xcode. I'm sure there are many in the scheme/lisp community who would welcome the opportunity to develop iOS apps using gambit - I know that some people at Clozure have already expressed interest for example.
I probably should, for my own future benefit, as much as anyone else's. It's a bit daunting tracing down all the little bits, particularly since I want to build the same sources for four different platforms. --me
On Dec 22, 2010, at 10:45 AM, Raffael Cavallaro wrote:
I'd like to ask, on behalf of myself and the many lurking here, that once you get this working you put up a blog post or a message here detailing all that's necessary to get a working gambit iOS 4.2 project under Xcode. I'm sure there are many in the scheme/lisp community who would welcome the opportunity to develop iOS apps using gambit - I know that some people at Clozure have already expressed interest for example.
In respect of your request, and also just to provide context for my own future reference, as well as for anyone else who's interested in this subject, let me just summarize where I'm at in this process. I have a version of Delectus 1.0 that builds with no trouble at all under the latest Apple dev tools and the stock Gambit 4.6.0. That version of Delectus is about 4,000 lines of Scheme code and about 1,000 lines of Objective-C code. The difference between the working version of Delectus and what I've been trying to accomplish in these conversations is that the working version is a full Cocoa app written mainly in Scheme, including its main program, and compiled using gsc, bypassing XCode entirely. What I'm trying to do now is build the non-GUI portion of Delectus (which I'll call the "delectus engine") as a library that I can link is a normal fashion in an ordinary XCode application. If I have a working Delectus build, why would I try to build it a different way? One reason is that I and my colleagues have some plans in mind for the delectus engine on platforms other than Mac OS X. To make those plans easier to achieve, it would be nice to build the delectus engine as a library. That would make it convenient to package the engine so that it can be used in various contexts while presenting an identical API and using an identical file format for the data it manages. A special case is iOS. We have plans to use it for an iPad app. It would be most convenient if we could present the delectus engine as a static library (the only kind supported by XCode for iOS development). It may be that I can build an iOS app in the same way that I have been building a Mac OS app: with a Scheme main, running Apple's dev tools from the command line driven by a Makefile, but there are some additional considerations. iOS apps for the app store need several additional resources, including code-signing resources that are normally built and attached automatically by XCode. For simplicity's sake, I'd rather just build apps the normal way that Apple expects, rather than trying to figure out how to build and attach all the needed resources without XCode's help. Moreover, I'd like to offer Delectus through the new Mac App Store, and the process for submitting apps to the Mac App Store is much the same as submitting them through the iOS App Store. For these reasons, it makes more sense to me to figure out how to build the delectus engine as a library and link to it in regular XCode projects, than to continue my past practice of building apps without XCode, by using a makefile to drive gsc. Unfortunately, I am so far unable to get an XCode project to link successfully to a library built by gsc. Using what Marc's given me so far I can build such a library, and I can add it to an XCode project and tell XCode to link to it, but when I add code that tries to call entry points exposed by c-define, or when I try to call the SCHEME_LIBRARY_LINKER routine as given in the tests/client.c example, XCode's linker complains that those symbols are not found. I'll keep poking at it. Running "make test8" in the modified Gambit I'm using seems to complete without incident (at least, no error output is produced). Looking at the code and the makefiles, it looks like that's what should happen if everything works right. I may try something like harvesting that code and trying to turn it into a simple XCode project, to see what, if anything, goes wrong. --me
On Dec 22, 2010, at 10:45 AM, Raffael Cavallaro wrote:
I'd like to ask, on behalf of myself and the many lurking here, that once you get this working you put up a blog post or a message here detailing all that's necessary to get a working gambit iOS 4.2 project under Xcode.
I'm not there yet, but I am much farther along. Here's what works: I have an XCode project that includes a static library built from Scheme sources using gsc and gcc. It launches, displays the default InterfaceBuilder window, then poses a modal dialog: The string in this case was constructed thusly: char* greeting = hello(" Cocoa"); NSString* msg = [NSString stringWithCString:greeting]; The function "hello" is provided by the static library, and is defined thus: (c-define (hello str) (char-string) char-string "hello" "extern" (catch-all-errors (lambda () (string-append "Hello, " str)))) This is most certainly a trivial application, but I'm very excited, because it works as intended, and because the structure of the application matches my requirements. Specifically, the non-GUI part of the app is written in Gambit Scheme and packaged as a static library that I can simply drop into a project and use without any special attention to the fact that it's written in Scheme. (Actually, that's not quite true; the main program does have to jump through a few hoops to ensure that the Scheme environment is set up properly at run time. The hoops in question are exemplified in the Gambit sources, in tests/client.c.) It's important that I can build subsystems as static libraries like this, because that makes it possible to package them in a way that I can use in iOS apps. It's not time to celebrate yet; I haven't actually built an iOS version of the library yet. I'm much more optimistic that this will be easy to do, though, now that I've built one for Mac OS X that just works. I'm also encouraged that it was a very small amount of code and a short Makefile to create this simple test project. For the project I'm working on, we want to be able to build an engine in library form that we can reuse unchanged on four platforms: Mac OS X, iOS, Windows, and in Linux-based web servers. As my next step, I'll see if I can't set up a template project that can be used to build libraries for all those targets, and then I'll make that template available to those who want it. --me
On Dec 25, 2010, at 5:40 AM, mikel evins wrote:
As my next step, I'll see if I can't set up a template project that can be used to build libraries for all those targets, and then I'll make that template available to those who want it.
This would be very helpful - thanks for all your hard work! warmest regards, Ralph Raffael Cavallaro raffaelcavallaro@me.com
Here's a weird one: Using the version of Gambit 4.6.0 that I built using Marc's script (which simultaneously builds Gambit for Mac OS X, iOS, and the iOS simulator), this works just peachy fine: Makefile: GAMBIT_HOME=/usr/local/gambit/MacOSX GSC=${GAMBIT_HOME}/bin/gsc GSC_INC=${GAMBIT_HOME}/include GSC_LIB=${GAMBIT_HOME}/lib compile_scheme: ${GSC} -:~~bin=${GSC_BIN},~~lib=${GSC_LIB},~~include=${GSC_INC} -f -link HelloGambit.scm However, if I change the first line to: GAMBIT_HOME=/usr/local/gambit/iPhoneSimulator ...gsc can no longer find the source file I'm compiling: cairagor:libHelloGambit mikel$ make /usr/local/gambit/iPhoneSimulator/bin/gsc -:~~bin=,~~lib=/usr/local/gambit/iPhoneSimulator/lib,~~include=/usr/local/gambit/iPhoneSimulator/include -f -link HelloGambit.scm *** ERROR -- Can't find file "/Users/mikel/Projects/libHelloGambit/src/simios/libHelloGambit/HelloGambit.scm" make: *** [compile_scheme] Error 70 Yes, I did check carefully to ensure that the file does, in fact, exist at the path "/Users/mikel/Projects/libHelloGambit/src/simios/libHelloGambit/HelloGambit.scm" --me
Aha; not so weird, after all. The Gambit built by Marc's script is built to run on the named target--in the case of the IPhoneSimulator version, it's intended to run on the IPhoneSimulator (duh!). So what I needed to do was use the MacOSX version of Gambit to compile the Scheme sources against the IPhoneSimulator versions of the libraries, includes, and so forth.
On 2010-12-27, at 7:48 AM, mikel evins wrote:
Aha; not so weird, after all. The Gambit built by Marc's script is built to run on the named target--in the case of the IPhoneSimulator version, it's intended to run on the IPhoneSimulator (duh!).
So what I needed to do was use the MacOSX version of Gambit to compile the Scheme sources against the IPhoneSimulator versions of the libraries, includes, and so forth.
Exactly. This works because the Gambit-C compiler, when used in its fundamental Scheme-to-C mode, implements a transformation from Scheme to C which is independent of the host environment. The C language is used as a universal target language. You could run the Gambit-C compiler on Windows to produce C files for an iOS device, a Microblaze soft processor on a Xilinx FPGA, etc. or the other way around. However, for the iPhone executable of the Gambit-C compiler, a major problem is that you have no read/write file system to store the result of the compilation. It should be possible to circumvent this "problem" by linking with the compiler new versions of the open-input-file and open-output-file procedures so that they use the network to contact a file server of some sort (or use string ports). You could maybe run TCC on the iPhone itself to have a completely self-hosted Gambit-C system... Probably not very practical, but an amusing project anyway! I wonder how this jives with Apple's license! Marc
I've made a simple project available for git cloning at: https://bywicket.codebasehq.com/gnomeworks/libhellogambit/tree/master libHelloGambit is a small collection of minimal projects that build static libraries from Scheme source code using Gambit Scheme, and that provide equally minimal example applications that link against those libraries. Only two examples are provided in Release 1: one that builds and runs on Mac OS X, and one that builds and runs on the iOS simulator. I'll add more as work progresses on my actual project. Below is the README, also available from the git repo. If you have any trouble with the repo (sometimes I misremember how to properly make things public at codebasehq), drop me a line and I'll fix it. --me ------ README ------ libHelloGambit Released into the Public Domain by mikel evins December 27th, 2010 Release 1 ABOUT libHelloGambit is a minimal project that demonstrates simply how to build a static library from Scheme sources, using the Gambit Scheme compiler, so that the library can be linked against ordinary applications on several target platforms. The working platforms in Release 1 are Mac OS X 10.6, using Apple's XCode 3.2.5, and the Apple iOS Simulator using the same development tools. I hope that it's clear from examining the included files how to adapt them for use with additional platforms that Gambit supports; in case it isn't, I plan to make additional releases of the project adding working examples for the iOS device SDK, Windows, and Linux. PREPARATIONS For Mac OS X and iOS builds, you'll need Apple's Mac OS X and iOS SDKs, available from http://developer.apple.com. In order to build the examples provided with libHelloGambit, you must first obtain the source distribution of Gambit Scheme from: http://dynamo.iro.umontreal.ca/~gambit/wiki/index.php/Main_Page You will need to build these sources using a script ("build-gambit-iPhone") that I obtained from Gambit's creator, Marc Feeley (feeley@iro.umontreal.ca). If Marc gives his permission, a future releases of libHelloGambit will include that script (or whatever replaces it). That build creates three versions of Gambit: one each for Mac OS X, the iOS Simulator, and the iOS Device target. The examples in libHelloGambit assume that these builds of Gambit have been installed in /usr/local/gambit/iPhoneOS /usr/local/gambit/iPhoneSimulator /usr/local/gambit/MacOSX You can put them anywhere you like, but if you do, then the Makefiles and XCode project files in libHelloGambit will need to be adjusted to reflect the different pathnames. BUILDING AND RUNNING Once the appropriate versions of Gambit have been built and the Makefiles and project files have been suitably adjusted, you can build libHelloGambit from the shell by cding into the appropriate source directory and running "make". FOr example, to build the Mac OS X version of libHelloGambit, cd into <libHelloGambit>/src/macosx/libHelloGambit and run "make". The build produces a static library named libHelloGambit.a, which is used by the XCode project in <libHelloGambit>/src/macosx/Hello to build a working Cocoa application. The Cocoa application (and the similar iOS application in the simios directory) is very simple, as is the library itself: the library exposes a single entry point, named "hello". The "hello" function accepts a C string, and passes it to a Scheme procedure that uses it to construct a simple greeting. Scheme then returns the constructed greeting string back across the FFI to C, and the test application then poses a modal dialog that dispays the greeting. The operation of the "hello" function itself is not important; what's important is that starting up the test "Hello" application exercises the Scheme-based library in full, by calling its single exposed entry point, implemented in Scheme code, with C data as input, and then retrieving the output that was constructed by Scheme and passed back across the FFI boundary, for use in the C application. The point of all this is to demonstrate simply how to construct a static library from Gambit Scheme sources that can be simply used in a native application built using the host platform's normal development tools. I undertook this project because I'm working on a project that needs a common subsystem that works identically across several platforms, but which also requires a first-rate native UI on each of those platforms. Using the approach demonstrated in libHelloGambit, I can build the common data engine in Gambit Scheme (which has tremendous advantages in terms of performance, expressiveness, serialization support, and incremental development), while relying on the native development tools of each platform to deliver the UI that the platform's users expect. I hope libHelloGambit can help other Scheme programmers more easily achieve their goals on various platforms.
On 2010-12-27, at 8:58 AM, mikel evins wrote:
I've made a simple project available for git cloning at:
https://bywicket.codebasehq.com/gnomeworks/libhellogambit/tree/master
libHelloGambit is a small collection of minimal projects that build static libraries from Scheme source code using Gambit Scheme, and that provide equally minimal example applications that link against those libraries.
Only two examples are provided in Release 1: one that builds and runs on Mac OS X, and one that builds and runs on the iOS simulator. I'll add more as work progresses on my actual project.
Below is the README, also available from the git repo.
If you have any trouble with the repo (sometimes I misremember how to properly make things public at codebasehq), drop me a line and I'll fix it.
--me
Really cool! By the way you can redistribute the build-gambit-iPhone script. But use the slightly improved one attached (renamed build-gambit-iOS). Here's a suggestion. Give all the shell commands verbatim that you did to build the application. I know you describe it in the text, but for visual people like me, it is nice to glance at the command sequence to "get it" quickly. Marc
The application I'm working on marshals a large number of strings across the FFI boundary. Large enough, in fact, that I've periodically considered introducing some interning strategy to ensure that a given character sequence is marshaled across the FFI at most once. If you have any ideas that might make such a scheme easier to implement, I'd be interested in hearing them. --me
On Wed, Dec 29, 2010 at 11:31:28AM -0600, mikel evins wrote:
The application I'm working on marshals a large number of strings across the FFI boundary. Large enough, in fact, that I've periodically considered introducing some interning strategy to ensure that a given character sequence is marshaled across the FFI at most once.
If you have any ideas that might make such a scheme easier to implement, I'd be interested in hearing them.
My first though, in reading this, is that you want to intern the longest repeated substring on each side. A trie structure can compute this sort of information, and your marshall protocol might be something you could express as updates to a trie synced on both sides, rather than marshalling strings. If that is interesting enough where you'd like more detail, just ask and I'll keep talking. If it isn't applicable to your idea, hopefully someone else will come up with something better! -Alan -- .i ko djuno fi le do sevzi
On Dec 29, 2010, at 12:36 PM, Alan Post wrote:
On Wed, Dec 29, 2010 at 11:31:28AM -0600, mikel evins wrote:
The application I'm working on marshals a large number of strings across the FFI boundary. Large enough, in fact, that I've periodically considered introducing some interning strategy to ensure that a given character sequence is marshaled across the FFI at most once.
If you have any ideas that might make such a scheme easier to implement, I'd be interested in hearing them.
My first though, in reading this, is that you want to intern the longest repeated substring on each side. A trie structure can compute this sort of information, and your marshall protocol might be something you could express as updates to a trie synced on both sides, rather than marshalling strings.
If that is interesting enough where you'd like more detail, just ask and I'll keep talking. If it isn't applicable to your idea, hopefully someone else will come up with something better!
Actually, no need; I know how tries work. That's not a bad idea; I'll give it some thought. --me
Hi Mikel: I do have Gambit 4.6.0 (actually, the git version) running under iOS 4.2 on both my iPad and iPhone4 (on device and simulator - so I keep two separate Gambit compiled libraries that XCode links in depending on which target I'm using). I also compiled the Bullet Physics 2.76 library as separate static libs with a Gambit wrapper that also all works fine with my 4 targets (iPhone, iPad, osx and linux - all using the same scheme code). I've been meaning to setup a simple Gambit Bullet iOS sample in github for awhile now with my Bullet and Gambit build scripts. I should be able to get to that next mid week and send off a email to the list when its up. Cheers, Adam On Sat, Dec 11, 2010 at 6:29 PM, mikel evins <mevins@me.com> wrote:
I haven't had any success building Gambit for recent versions of Apple's iOS SDK. I've tried monkeying with the makefiles by hand, and tweaking the configure scripts that James Long and a couple of other people have created, but no joy, so far.
I've succeeded in this sort of effort before on my own, and presumably can again, but I thought before pouring many hours down the drain I'd ask whether anyone else has already done it and is willing to share their configuration, or the steps they followed to get it.
I'm using the iOS 4.2 SDK, and attempting to build Gambit 4.6.0.
--me
_______________________________________________ Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
participants (7)
-
Adam King -
Alan Post -
Marc Feeley -
Marc Feeley
-
Mikael -
mikel evins -
Raffael Cavallaro