Let's not mess around dlopening it and leaving gaps
in the support whereby we currently require it to
exist either linked or "dlopenable+display supports it"
with dlopenable + display doesn't support it leaves
a crashing gap where there are no appropiate checks
for that case.
This commit also update the internal includes to latest mozilla ones
including the .c{,pp} file updates.
The ldap check is also simplified from 2 check into plain one.
As an aside we can always use the configuration and data files belonging to the
system version now in --with-system-libexttextcat mode, so need for the --data
option.
I don't see the need to explicitly prefix PATH with /usr/bin in the
generated 'bootstrap' file. Surely /usr/bin is in PATH anyway for any
sane setup, and if there are other directories in front of it in PATH,
that is then on purpose.
This reverts commit bf0ea5c4ee.
Those variables are used in bin/distro-install-*.
Unable to find any issue with both distro-install and dev-install so
reverting.
If something really does break it needs fixing. Reverting this is not
an option.
Make sure the MINGW_FOO environment variables get set and propagated
to the build environment also in the MinGW cross-compilation case. The
OOo code used to do that for MinGW natively on Windows (under
Cygwin). (Which we don't intend to support.)
Now, whether the *use* of these variables in the various makefiles etc
is relevant any more remains to be seen. I suspect all that might well
be unnecessary, as we after all are capable of cross-build the code
using MinGW just fine currently with none of these MINGW_FOO being
set.
One place where at least MINGW_GCCDLL and MINGW_GXXDLL is needed,
though, is in scp2. We presumably do want to include these DLLs (the
shared libgcc and libstdc++) in the installation set, to the extent
the scp2 stuff can be used still in a MinGW cross-build context.
Its alternative values as used by OOo is irrelevant to us as we don't
intend to support building using MinGW on Windows itself. To us, MinGW
always means cross-compilation. For us it is enough to look at
$(OS)$(COM), and WNTGCC always implies cross-compilation.
(OOo on the other hand attempts to support use of the Cygwin gcc with
the -mno-cygwin option (which is practically considered an obsolete
option), the normal MinGW compiler (but still from Cygwin), but not
cros-compilation.)
