Don't run dlltool --output-exp to create a separate object file with
just export data (.edata section). In the case where at least one
function in the objects being linked has been explicitly marked for
export, GNU ld will not look for export information in the object
files anyway. At least the GetVersion() function seems to be marked
for export explicitly. Just pass the .def file when linking.
GNU ld since 2.17 supports @cmdfile syntax, just like MSVC tools, so
no need to create a separate shell command file and source that. (Why
that even would work better than just running the ld command with a
long command line directly, I don't know.)
Actually I don't know why even bother with the @cmdfile, after all we
mainly intend WNTGCC to be used when cross-compiling, and there are no
short command-line length restrictions on modern OSes from which one
might want to cross-compile. But oh well.
Pass the necessary -L switches, i.e. SOLARLIB, when linking with GNU
ld. (For MSVC, the ILIB environment variable is used.)
Produce the import library when linking, no need to have a separate
rule to produce an import library for WNTGCC.
Re-unroll tg_shl.mk into _tg_shl.mk with the recently unbroken
mkunroll tool.
Re-introduce the old --with-mingw option but now called
--with-mingw-cross-compiler. Its purpose is now specifically to give
the cross-compiler used when building the ODK, if Java is enabled, and
if building the unowinreg.dll. It has now nothing to do with
cross-compiling LibreOffice itself.
Correspondingly, the WITH_MINGW variable now has meaning only when
building LibreOffice for Windows: If using MinGW, whether natively on
Windows itself (which we as such don't intend to support, I hope), or
cross-compiling, it is set to "yes".
Automate and simplify the search for the MinGW cross-compiler when
intending to build unowinreg.dll on Unix.
Look for the usual tool-chain tools ar, nm, objdump, pkg-config,
ranlib, strip, and for Windows alto dlltool and windres using
AC_CHECK_TOOL so that the proper cross tools are found when
needed. Propagate to environment. As such these are not used except in
the MinGW mk files so far.
Other minor cleanups.
AC_SUBST also EXEEXT_FOR_BUILD and use that in Makefile.in.
As winemv.set.sh is now called WindowsMSVCEnv.Set.sh, with capital E
and S like all the others, we can simplify the glob pattern for the
Set.sh file.
Don't attempt to download and/or run unpackers for dependencies
relevant only when using MSVC if using MinGW.
Misc other Windows host vs. build fixes.
Still a long way from working, of course.
The configure script now runs to finish on Linux with --host=mingw32.
It is no longer an error if Windows SDK or DirectX SDK are not found
by the logic in the configure script. It might well be that the user
has included relevant -I and -L flags in CC or CXX that makes the
compilations work anyway, or something. We should not try to be too
clever and try to predict how the compiler or linker work in the
configure script.
We now define the FOO_FOR_BUILD environment variables in set_soenv.in
even when not cross-compiling (identically as the plain FOO ones in
that case, obviously). This should make some makefiles and stuff that
build tools to run on the build host a bit simpler.
I don't understand why, but need to use double-quotes around the
CXX_X64 etc values assigned in set_wnt64.mk, to guard against their
pathname containing spaces or other special characters, like parens in
the case of "/cygdrive/c/Program Files (x64)". I hope this helps those
who have MSVC installed in its default path.
Also drop use of the unnecessary WRAPCMD.
As set_soenv.in used to always put BUILD_SOSL="true" in the
environment, we can delete the block completely that was to be
executed only if BUILD_SOSL was undefined.
At least odbcconfig is a GUI executable.
Apparently MSVC is clever enough to guess that a program with a main()
is intended to be linked as a CUI ("console") executable, and
correspondingly a program with a WinMain() as a GUI ("Windows")
executable. And our code seems to follow that convention.
Note that all this indeed is just convention; the OS of course has no
idea whether an executable's source code had a main function called
main() or WinMain(), if either at all. That is just a convention for C
and C++ programs. Whether an executable is for the console or
"Windows" subsystem is determined by a single flag in the executable
header, and this can even be changed with editbin. Nothing prevents a
console executable from opening windows and have a GUI, and nothing
forces a GUI executable to actually have a GUI.
Don't confuse the 64-bit Explorer extension with a 64-bit LibreOffice,
which is unfinished and highly experimental work. OOo has been
building and distributing a 64-bit Explorer extension since long, and
we should too. They used some secret Hamburg sauce when building it,
though, but hopefully now it works here, too.
this solution is not perfect because Cwd::realpath($ENV{DESTDIR})
need not be part of Cwd::realpath($ENV{DESTDIR} . $arg). Let's
solve this when it really cause troubles.
The problem was that ooinstall just passed -destdir to
make_installer.pl, but before that, it tried to create the root
directory, where it did not respect DESTDIR.
Signed-off-by: Petr Mladek <pmladek@suse.cz>
langlist.mk was used by gnumake modules
postset.mk was used by dmake modules
unsupported languages were removed from langlist.mk
postset.mk now includes langlist.mk to avoid duplication
This is 7e585ded0f1cce41fd3dec6146526d07783d2d38 again,
removed in 981e63a40a5918135f3547c849394a36f8012af9, probably by mistake.
With the linking it's possible that soffice.bin becomes the wrapper
script that ends up calling itself recursively.
This is 7e585ded0f1cce41fd3dec6146526d07783d2d38 again,
removed in 981e63a40a5918135f3547c849394a36f8012af9, probably by mistake.
With the linking it's possible that soffice.bin becomes the wrapper
script that ends up calling itself recursively.
install to %libdir% intead of %prefix% as it is usual for other projects;
use the usual DESTDIR instead of OODESTDIR
Note that the default installation path is /usr/local/lib/libreoffice;
it can be redefined by --prefix, --libdir, --with-install-dirname
configure options
Some of these changes contributed by Petr Mladek <pmladek@suse.cz>
As far as I know we have no intention to use that stuff. Do we ever
have any idea what it means? But sure, if it turns out that we do want
to, this commit will have to be reverted.
That is, resource files containing localizable data that are included
from other resource files. They have filenames like foo_tmpl.hrc
(sometimes foo_tmpl.src) and are included as foo.hrc . They were handled
by listing them in LOCALIZE_ME variable in the old build system.
"Vendor" with the value of OOO_VENDOR, and "BuildVersion" with the
value of BUILD_VER_STRING. These get their values from the
--with-vendor and --with-build-version switches of the configure
script.
From the build-identification.diff patch, has been part of distro
OOo/LO builds for long.
some cppunit test need to link directly with the object of the module
they are meant to test, due to the fact that the API they use/test
are not necessarily exported in the public interface of the
module's dynamic library.
This patch add the mean to export the list of objects used in the link of
specific target library, and a mean to import these into the link of
a cppunit.
Only unxgcc.mk has been modified so far to support the later
This is not intended to be use to import objects accross module boundaries
- remove -pthread from PTHREAD_CFLAGS
- add pthread to gb_STDLIBS
- redefine gb_LinkTarget__command_dynamiclink so that we can
substitute -lpthread with -pthread in the list of libraries
that we link to
- remove -pthread from PTHREAD_CFLAGS
- add pthread to gb_STDLIBS
- redefine gb_LinkTarget__command_dynamiclink so that we can
substitute -lpthread with -pthread in the list of libraries
that we link to
Wen building a multi-language installer the subroutine
create_unique_directorynames() is called for each language. The same
directory names will be traversed each time. It needs to check the
uniqueness of them only the first time, otherwise it will think every
directory name is repeated.
The check is new, from OOo, but they don't build multi-language
installers so they have not noticed this problem.
The solution is a bit hacky but works.
