[Gambas-user] Form embedding, building devel version
Rob Kendrick
gambas-users at ...790...
Wed Jan 12 18:55:23 CET 2005
Benoit Minisini wrote:
>>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 :-)
Would you accept the patch?
> But I find statically linked executable a very bad idea:
I'm not saying that it should *only* produce static binaries, but that
doing it that way would allow you to do so in the rare cases having a
static binary would be advantagous. What I'm saying is that generating
a real executable that uses the interpreter as a shared library, rather
than via the horror that is the #! system is a better solution, in every
way I can think of.
<snip>
> 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.
Rather than none at all. Also, what if it's not a perticular OSes
policy to have such things in /usr/bin ? What if it's not a Unix at
all? (You have to do something else again completely different, where
generating executables that use the interpreter as a library mean that
it's essentially the same thing you have to do everywhere, making
porting easier.)
> 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, ...
I don't see why this is a problem for anything I have suggested,
considering all the "stub"'s job would be would be to call a function in
the library along with a pointer to the application's code and data.
There's nothing stopping the library setting up signal handlers and
loading .so files at other points.
> Last, incompatible interpreters will be renamed: gbx, gbx2, ..., gbxN. This
> will avoid ambiguities.
Shared libraries already provide this functionality, except in a much
more elegant way that doesn't mean you end up with dozens of symlinks in
/usr/bin/.
--
Rob Kendrick
PGP signed or encrypted mail welcome (Key ID: 3651D17A)
More information about the User
mailing list