Re: What can I do to help? (conclusions)

[Rob Browning]

Andreas Rottmann <address@hidden> writes:

> Yes, that's a clear disadvantage. However, in what environments does
> that requirement exist? If you have a configure option, you can decide
> both ways. There could even be a debian package 'guile' (with a C
> linked executable) and a 'guile-c++' one, linked with g++, replacing
> 'guile' (or the other way round with a c++-linked guile as
> default). Then C++ plugins could depend on guile-c++. However, I get
> too much into debian pkg management now, I guess *waves to Rob*.

I think this might be possible, but if it meant that not only guile,
but every lib and app that was linked against guile would have to be
packaged two ways, then it's probably not feasible.

> It is not possible to load this plugins with some C++ constructs
> (e.g. exceptions, don't know the full list), since guile
> crashes.

Are we talking about guile functions calling c++ functions, or c++
functions calling guile functions here, and are we talking about the
c++ code being accessed via guile loaded (dynamic-link)ed shared
libraries or via direct linking/loadinga?

Also is there a description of the problem available anywhere? i.e. in
the case of exceptions where c code is calling c++ code, is it a
problem if the c++ code throws an exception at all, or only if it
tries to throw one up to the c level.  If the latter, then can the c++
code just be required to have a catch-all "catch" at the top-level in
all of the functions guile will be calling?

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD