[Gambas-user] Form embedding, building devel version

[Benoit Minisini]

On Wednesday 12 January 2005 17:22, Rob Kendrick wrote:
> Rob Kendrick wrote:
> > Benoit Minisini wrote:
> >> Because Gambas IS an interpreter. But if you like, you can write a
> >> compiler for Gambas of course :-)
> >
> > You seem to have already done so: gbc.  And such a thing isn't actually
> > necessary for such a scheme anyway.
>
> This thread appears to have died with insuffcient discussion for me to
> understand the issues at hand.
>
> Why is the fact that Gambas is an interpreter stopping it from producing
> ELF binaries?  My request is as follows:
>
>    1. Make the interpreter available as a library as well as an
>       executable
>    2. Provide a small "stub" object file built during Gambas's build,
>       that uses the library version of the interpreter to execute
>       the application that is stored in some static structure in the
>       executable
>    3. Allow building of application via dumping all the bits needed
>       to run it out to a very simple ELF file that just contains the
>       data as a static structure, and linking that to the stub and
>       the interpreter library to generate an executable.
>
> This has the advantages that you have the option of statically linking
> your application if you so wish, so you don't require any other
> libraries or runtimes to run your application somewhere, as well as
> independance from system to system about where the gambas interpreter is
> stored.  It also provides version support between different incompatible
> interpreters that may (or may not) appear over time via the soname
> functionality.  And all this with only having to have ld installed, not
> the whole gcc suite.  (Which is usually packaged seperately anyway.)
>
> I'm not suggesting that this sort of mechinism should *replace* the
> current, but it might be a handy option to have.

Do it if you like :-)

But I find statically linked executable a very bad idea:

1) They are very hard to produce: gambas component requiring library A and B, 
that require libraries A1, A2, A3, and so on until glibc and ld.so.

2) They consume a lot of disk space.

3) They are not updated if there is a security update or important bug fix of 
one of the libraries.

4) They don't work if a statically linked library like glibc depends on the 
system architecture (/etc/resolv.conf for example) and this architecture 
change.

Making an executable or a script makes no difference for the user. The Gambas 
archives just require ONE symbolic link in /usr/bin. It is not a nightmare.

Embedding gambas in an executable is not so evident: the gambas interpreter 
needs a total control of a process: it needs its own signal handlers, it 
needs to control when dynamic libraries are loaded and freed, ...

Last, incompatible interpreters will be renamed: gbx, gbx2, ..., gbxN. This 
will avoid ambiguities.

Regards,

-- 
Benoit Minisini
mailto:gambas at ...1...