Hi Vijay. The basic steps you need to create a library are:

gsc -c -o core/b.c core/b.scm gsc -c -o core/a.c core/a.scm gsc -link -o core/ab.c -preload core/a.c core/b.c gsc -obj -o core/a.o core/a.c gsc -obj -o core/b.o core/b.c gsc -cc-options "-D___LIBRARY" -obj -o core/ab.o core/ab.c ar -rc ab.a core/a.o core/b.o core/ab.o

That’s basically what you had, except the important -cc-options "-D___LIBRARY" to cause the file ab.c to not generate a “main” function. Moreover, you were using a “flat” link file and you need an incremental one (so the -flat option should not be used). Why incremental? Because your library is building upon the base Gambit library (you still need access to “display”, “newline”, etc that are part of the Gambit library). If you were creating your own library to replace the Gambit library then you would use the -flat option.

So after that, you can build your app with the following commands:

gsc -link -l core/ab.c myapp.scm gcc -o myapp ab.a `gsc -e '(print (path-expand "~~lib/libgambit.a"))'` myapp_.c myapp.c

The first command creates the link file for your app (myapp_.c). Note that the -l option is used to indicate that the app is linked with your library.

The second command uses gcc to compile the C code of your app (including myapp_.c), and produce an executable file (note the linking with ab.a and libgambit.a).

An alternative to these two commands is to use this single invocation of gsc:

gsc -exe -l core/ab.c -ld-options ab.a myapp.scm

When I tried this I was surprized to see that gsc incorrectly rejects the -l option. This is a bug that was probably introduced when I did a refactoring of that compiler logic. I’ve now fixed the problem and pushed the fix to the Gambit github repo.

Marc

On Mar 8, 2016, at 11:32 AM, Vijay Mathew vijay.the.lisper@gmail.com wrote:

Hi Brad,

Here are the steps to reproduce the error I am getting. This is the structure of the sample project folder:

myapp --> core ----> a.scm ----> b.scm --> myapp.scm

The contents of the scheme files are:

;; core/a.scm
(define (fa)
  "hello from a")

;; core/b.scm
(define (fb)
  "hello from b")

;; myapp.scm
(display (fa))
(newline)
(display (fb))
(newline)

I build an executable like this:

$ gsc -o myapp -exe ./core/*.scm myapp.scm
$ ./myapp 

=> hello from a
=> hello from b

All is fine. Now I try to bundle core as a static library:

$ gsc -c -o ./core/b.c ./core/b.scm
$ gsc -c -o ./core/a.c ./core/a.scm
$ gsc -link -flat -o ./core/ab.c ./core/*.c
$ gsc -obj -o ./core/ab.o ./core/ab.c
$ ar -rc ab.a ./core/ab.o 

I link the library while building the app:

$ gsc -o myapp -ld-options "ab.a" -exe myapp.scm
*** WARNING -- "fa" is not defined,
***            referenced in: ("/Users/me/myapp/app.c")
*** WARNING -- "fb" is not defined,
***            referenced in: ("/Users/me/myapp/app.c")

Now if I run `./myapp` it gives me this error:

$ ./myapp 
*** ERROR IN | app| -- Operator is not a PROCEDURE
(#!unbound)

So what am I doing wrong?

Thanks,

--Vijay

On Tue, Mar 8, 2016 at 1:00 AM, Bradley Lucier lucier@math.purdue.edu wrote: Personally, I don't have enough information yet to offer help.

Perhaps you could show us a transcript of your session with the commands you gave and the errors you observed.

Or perhaps you could try to imitate the commands in the makefiles in lib/ gsi/ and gsc/ to make

find . -name '*.a' ./gsi/libgambitgsi.a ./gsc/libgambitgsc.a ./lib/libgambit.a

after following the build instructions on github:

https://github.com/feeley/gambit

Brad

---

Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list

Yes, the one that was broken and is now fixed!

Marc

On Mar 8, 2016, at 2:18 PM, Bradley Lucier lucier@math.purdue.edu wrote:

...

On Mar 8, 2016, at 1:50 PM, Marc Feeley feeley@iro.umontreal.ca wrote:

So after that, you can build your app with the following commands:

gsc -link -l core/ab.c myapp.scm gcc -o myapp ab.a `gsc -e '(print (path-expand "~~lib/libgambit.a"))'` myapp_.c myapp.c

You probably shouldn't use a bare "gcc" command because it won't have the options Gambit-generated code needs for correctness. Isn't there a gsc command that does the same thing?

Brad

Yes the two commands (gsc followed by gcc) can (after the fix) be replaced by the single invocation of gsc:

gsc -exe -l core/ab.c -ld-options ab.a myapp.scm

Alternatively, you can completely avoid using gcc with the following sequence of commands (that also work without the recent fix):

gsc -link -l core/ab.c myapp.scm gsc -obj myapp.c gsc -obj myapp_.c gsc -exe -ld-options ab.a myapp.o myapp_.o

and yes, that is better than invoking gcc explicitly, because it will pass the correct options to gcc (or whatever C compiler Gambit was configured with).

Marc

On Mar 8, 2016, at 2:24 PM, Bradley Lucier lucier@math.purdue.edu wrote:

I still don't understand. You're still compiling Gambit-generated code with gcc without the correct options.

Are you saying that now that gsc is fixed you don't need the second command, beginning with "gcc ..."?

Brad

...

On Mar 8, 2016, at 2:20 PM, Marc Feeley feeley@iro.umontreal.ca wrote:

Yes, the one that was broken and is now fixed!

Marc

...

On Mar 8, 2016, at 2:18 PM, Bradley Lucier lucier@math.purdue.edu wrote:

...

On Mar 8, 2016, at 1:50 PM, Marc Feeley feeley@iro.umontreal.ca wrote:

So after that, you can build your app with the following commands:

gsc -link -l core/ab.c myapp.scm gcc -o myapp ab.a `gsc -e '(print (path-expand "~~lib/libgambit.a"))'` myapp_.c myapp.c

You probably shouldn't use a bare "gcc" command because it won't have the options Gambit-generated code needs for correctness. Isn't there a gsc command that does the same thing?

Brad