Drop the TARGETPLATFORM=BUILD indication of stuff that is to be built
for the build platform but pointless to build for the host platform. I
will handle the split of stuff built for the build or host platforms
differently. Note that some libraries need to be built for both
platforms.
Add explicit rules to do nothing for the cross-compilation case, but
likely even that will be unnecessary in the case of complete modules
like soltools (?). I will just mark modules that are for the build
platform only with an own flag in BUILD_TYPE.
* origin/feature/gnumake2.1: (202 commits)
Revert "starmath need to have _DLL_ defined, even on MacOS"
tweak library name on MacOS
starmath need to have _DLL_ defined, even on MacOS
add helper to set-up the libraries env, to run executable during build
the startmath module in Module_ooo must use the name of the directory
add starmath libraries to Repository.mk
make linkoo scan the solver too, for Norbert's gnumake work
-Wunitialized is not compatible with -DDEBUG
rename gb_HIRESTIME to gb_LOWRESTIME. Assume highres precision by default
add missing library for sc. Massage the delivered libraries name.
support USE_GMAKE=1 envvar to build with gmake the modules that can be.
add sc in the list of gmake-Modules
support for an alternate gbuild.lst to support gmake build
add a few comment to balance quotes, to make the editor less confused
add all the sub-directory of the RESLOCATION to search for resource
add calc related library to the Repository
tweak MacOs platform specific include to build on Macos
fixing variable exports for windows compiler (thanks ause)
fixing variable exports for windows compiler (thanks ause)
also accept debug=t
...
Conflicts:
Makefile.in
Module_ooo.mk
Repository.mk
RepositoryFixes.mk
configure.in
solenv/bin/build.pl
solenv/bin/modules/RepositoryHelper.pm
solenv/bin/packmodule
solenv/doc/gbuild/doxygen.cfg
solenv/doc/gbuild/solenv/gbuild/types.mk
solenv/gbuild/AllLangResTarget.mk
solenv/gbuild/BuildDirs.mk
solenv/gbuild/ComponentTarget.mk
solenv/gbuild/Deliver.mk
solenv/gbuild/Executable.mk
solenv/gbuild/Helper.mk
solenv/gbuild/Library.mk
solenv/gbuild/LinkTarget.mk
solenv/gbuild/Module.mk
solenv/gbuild/Output.mk
solenv/gbuild/Package.mk
solenv/gbuild/PrecompiledHeaders.mk
solenv/gbuild/SdiTarget.mk
solenv/gbuild/StaticLibrary.mk
solenv/gbuild/TargetLocations.mk
solenv/gbuild/gbuild.mk
solenv/gbuild/platform/linux.mk
solenv/gbuild/platform/macosx.mk
solenv/gbuild/platform/solaris.mk
solenv/gbuild/platform/windows.mk
solenv/gbuild/processdelivered.awk
solenv/gbuild/processdeps.awk
solenv/inc/unxgcc.mk
soltools/mkdepend/def.h
soltools/mkdepend/include.c
The __real@ ones are storage of (shared?) floating-point
constants. The __TI3? ones are related to throwing exceptions, TI
perhaps means type information. Trying to export them causes
unresolved externals problems, and most likely it would be insane to
export them from a LO DLL anyway. I came across the problem with some
framework DLLs.
Why this issue has popped up now, after the big stlport/boost/etc
change, I have no idea. One would think we have had floating-point
constants all the time in the code, and we throw exceptions all over
the place. Oh well.
