Otherwise those external projects will fail, because with only VS2013 installed
there is no ToolsVersion 4.0 (which is set inside the VC projects files).
http://msdn.microsoft.com/en-us/library/bb383985.aspx
Change-Id: I144ba1ef95372226ebadb082e3a78155cca316fd
instdir/LibreOfficeDev.app/Contents/MacOS/libCbc.3.dylib -> libCbc.3.8.8.dylib
(which does not exist)
See also: 9f339a89453808b917177a3ee675a76385758902
Change-Id: I398d649c2e918b496c9b92364189da4796682653
Reviewed-on: https://gerrit.libreoffice.org/10614
Reviewed-by: David Tardon <dtardon@redhat.com>
Tested-by: David Tardon <dtardon@redhat.com>
Add a patch to mangle the project files a bit so that they work better
on a machine with only VS2013 installed. At least in my case. But why
we still need to *also* have those /p:PlatformToolset=v120
/p:VisualStudioVersion=12.0 in the ExternalProject_coinmp.mk I don't
know.
Change-Id: Ieebd729c3ba89cf22231fb943f3739d6be5c7acd
Fix UNAME_PROCESSOR detection in Mac OS X.
Add a filter expression before to apply a platform-specific patch.
Change-Id: I9fc4cf790f16255f4e807e070dbae0e5a1f28781
Reviewed-on: https://gerrit.libreoffice.org/10227
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
(No idea whether it works, of course.)
Patch the config.sub files to recognize arm-linux-androideabi.
Don't build any binary programs as that fails for Android becuase we don't
pass in the right C++ library to use anyway. (And those programs aren't really
useful to us anyway, on any platform, I guess?)
Change-Id: I70c7a527db41081a51548ce6983b6a9ae8a08bc7
VS2012 did change return value of fileno function, this results in a
crash when run in GUI mode (but not when launching from a shell), as
python tries to access the nonexisting stdin/stdout/stderr
Also explicitly target Windows XP
Change-Id: Ic783713b55453f3c38b2e766a664b7f4678711de
...which can lead to problems when e.g. building against a local trunk GCC
(requiring LD_LIBRARY_PATH) that was configured to build only C/C++ compilers,
so CoinMP's configuration would try to blend that with the system's gfortran.
Change-Id: I9f237df0887e06e50b9e76f3a09cfebb6f22dc20
Several people named Chris report failures in the solver unit test, and
apparently the CoinMP libraries have loads of unresolved symbols
because they don't have NEEDED entries, i.e. were not linked properly;
let's see if this fixes it.
Change-Id: Id406e14b0805a458d608c23cb7c65d873b5ba2f0
Reviewed-on: https://gerrit.libreoffice.org/8850
Reviewed-by: Chris Laplante <mostthingsweb@gmail.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
