VCL delivers an object file salmain.o[bj] that contains a default
implementation of the main function of a "VCL based" application.
Basically, it just calls SVMain, but on some platforms does some extra
work before that, so there are four places where it is defined:
- vcl/aqua/source/app/salmain.cxx:1.22 is the Mac OS X version (and does
some RLIMIT_NOFILE fiddling before calling SVMain).
- vcl/os2/source/app/salmain.cxx:1.5 appears to be the OS/2 version (and
just calls SVMain, but has lots of commented out garbage in it; I know
nothing about this file).
- vcl/unx/source/plugadapt/salmain.cxx:1.10 is the general Unix version
(at least used by unxlngi6, unxsoli4, unxsols4; it does exactly the same
as the Mac OS X version).
- vcl/win/source/app/salmain.cxx:1.9 is the Windows version (and just
calls SVMain).
Next, some platforms build "static" versions of obj/salmain.obj (i.e.,
non-PIC code suitable for linking into an executable) while other
platforms build "dynamic" versions of slo/salmain.o (i.e., PIC code
suitable for linking into a shared library). In either case, the
resulting object file is delivered to solver's lib/salmain.o[bj].
- wntmsci10 builds static obj/salmain.obj.
- unxlgni6, unxmacxi, unxmacxp, unxsoli4, unxsols4 build dynamic
slo/salmain.o (unxmacxi/p also build static obj/salmain.obj, which is
effectively ignored).
There are virtually no places where salmain.o[bj] is explicitly linked
against (only vcl/test/makefile.mk:1.8 and vcl/workben/makefile.mk:1.21
do that). Rather, each platform specific .mk file in solenv/inc defines
STDOBJVCL to be either $(L)/salmain.o or $(L)$/salmain.obj, and
solenv/inc/tg_app.mk:1.68 ties the knot by adding STDOBJVCL to every
APPnOBJS where TARGETTYPE==GUI (and APPnNOSAL is not set).
Some issue (<http://www.openoffice.org/issues/show_bug.cgi?id=81275>)
made me want to add some code to all Unix-like variants of salmain.cxx.
That code is hidden in a function that is present on every platform,
but implemented in a platform-specific way. Hence, it looked natural to
consolidate the various definitions of salmain.cxx into a single one,
first calling that new function (into which also the RLIMIT_NOFILE
fiddling could easily be moved) and then calling SVMain.
However, that gets complicated by the fact that some platforms want to
build a static obj/salmain.obj while some want to build a dynamic
slo/salmain.o---where the latter looks like an error to me.
So, is there any reason that some platforms build a dynamic salmain?
Would not it better if all platforms just build a static version?
-Stephan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
