summaryrefslogtreecommitdiff
path: root/tests/repository
diff options
context:
space:
mode:
authorChun-wei Fan <fanchunwei@src.gnome.org>2017-04-20 18:47:03 +0800
committerChun-wei Fan <fanchunwei@src.gnome.org>2017-05-03 16:30:59 +0800
commit5d4cd25292b8ed2c7a821ebe19fc5ab5d447db1a (patch)
treed3da013a6c572c9ec4e63583050b440204aed428 /tests/repository
parent6b703b3211ce45389a777a439ccdf8fd64ed2b30 (diff)
downloadgobject-introspection-5d4cd25292b8ed2c7a821ebe19fc5ab5d447db1a.tar.gz
giscanner: Do not use distutils for linking
...the dumper program for all cases. It turned out that using distutils for linking is more troublesome than useful as we need to ensure that the paths specified by -L need to come before the standard library search paths, and distutil's ccompiler.add_library_path() and ccompiler.add_runtime_library_path() does not work for all of its supported compilers (Visual Studio is an example). Instead, we go back to constructing our linker command line manually as we did before (and as we now do in the libtool case), but with some enhancements: -Use '-libpath:' on Visual Studio builds, which corresponds to the -L flag on GCC/CLang. -Extend LIB/PATH (Windows/Visual Studio) or LD_LIBRARY_PATH (other compilers/envs), which is necessary as we resolve the libraries that are passed into g-ir-scanner, at least on Windows. -Don't attempt to link to or resolve m.lib on Visual Studio builds, as the math functions are in the standard CRT .lib/.dll, and there is no such thing as m.lib https://bugzilla.gnome.org/show_bug.cgi?id=781525
Diffstat (limited to 'tests/repository')
0 files changed, 0 insertions, 0 deletions