diff options
author | Chun-wei Fan <fanchunwei@src.gnome.org> | 2017-04-20 18:47:03 +0800 |
---|---|---|
committer | Chun-wei Fan <fanchunwei@src.gnome.org> | 2017-05-03 16:30:59 +0800 |
commit | 5d4cd25292b8ed2c7a821ebe19fc5ab5d447db1a (patch) | |
tree | d3da013a6c572c9ec4e63583050b440204aed428 /tests/Makefile.am | |
parent | 6b703b3211ce45389a777a439ccdf8fd64ed2b30 (diff) | |
download | gobject-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/Makefile.am')
0 files changed, 0 insertions, 0 deletions