On 24 Nov 1999 20:35:05 +0100, Lars Gullik Bj°nnes wrote:
>| You can use the EMXEXP tool to export all global functions and all
>| initialized global variables.
>| (And even the uninitialized, but this is often problematic: Please
>| initialize ALL global variables to a completely defined state and
>| assert() violations of this rule. Even better is it *not to export any
>| global variables* and to *export only global functions*. The OS-linker
>| link386 is in fact not tested for the import of global variables from a
>| DLL. IIRC this export of global variables occurs with RTTI and virtual
>| functions as gcc implements them and often leads to multiply defined
>| symbols; but don't believe me here, I may be wrong.).
>|
>| So, while an optional libtool is certainly helpful for creating
>| manually a suitable make process for dynamic linkage by modifying its
>| templates, I don't think it should be enabled by default.
>
>That is why only static libs are created by default.
>You _have_ to use --enable-shared to get dynamic ones.
>I think that we should be able to use libtool always without problems.
>(and if we get problems, static libs for any given arch should be
>quite easy to add)
This is more or less what I want. It might even be better to have a
default setup where libtool isn't involved at all, i.e. only
--enable-shared would call libtool.
>
> Also, I am not going to work on making shared work on other archs
>than ix86/Linux (and that already work). We will slowly move to have
>better module/library api's and dependencies but do not expect much.
As long as static linkage works...
Well, in the old dll version I had to export some uninitialized
globals, what I did not like. Nevertheless, cleaning up this structure
would be great for all LyX platforms, I think, not only Linux. And I
like very much the old idea of SMiyata: Put the whole LyX kernel, with
the exception of main(), into shared modules. This would give us
several instances (windows) of LyX without additional overhead and with
crash protection in separate processes.
Now what is involved from the OS/2 point of view (recent experiences
with 104):
* ditch completely fork() syscall: This is easy to implement for the
syscalls class, did this already, I don't see a problem to port it to
the new branch. This is certainly not a top priority, but as it is not
so much work, I think I can do it easily.
* ditch figinset.C: I could not make it work on my box, probably a
problem of gs403, which I must use here. You use some forked workhorse
process clones; this is not always guaranteed to work with emx a.out
and is guaranteed not to work in a DLL. So: Reimplement this in a
thread safe re-entrant way (protect variables and other resources
against mutual competition, etc.), but do not call (i.e. select) the X
server in the work horse at all; unfortunately, the emx select() call
is not thread safe :-/. I experienced crashes when using the
_beginthread() work-horse. This is too difficult for me to implement,
I'm afraid. Putting thew module into the exe is not an alternative:
There are too many shared ressources, so this won't help.
What about instead using a widely used and widely portable library,
like 'IMLIB'??! Who knows more?
>
>btw. did you try --enable-shared on OS/2? How severly did it bomb?
SMiyata recently reported his experiences here, he knows much better
the OS intrinsics than I do. (Only used it with a much simpler thing
than LyX and this was difficult enough. BTW: I just released 104/2,
need a little pause; a friend even said I became a LyX maniac and this
list with all the C++-stuff would spoil me completely ;-)
Greets,
Arnd
(who has been severely hit by this incurable LyX virus infection)
