summaryrefslogtreecommitdiff
path: root/giscanner/shlibs.py
Commit message (Collapse)AuthorAgeFilesLines
* giscanner: add a --use-ldd-wrapper optionAlexander Kanavin2019-12-131-1/+3
| | | | | | | This is useful in cross-compile environments where system's ldd command does not work on binaries built for a different architecture Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
* Evaluate the filters when checking library types in resolve_shlibsAlistair Buxton2019-09-271-2/+2
| | | | | | | | | | In Python 3, filter() returns a filter object for lazy evaluation. This object is truthy, so casting it to bool will return True even if it would contain no objects. This thwarts the test at the beginning of _resolve_non_libtool. To fix this, immediately evaluate the filters with list(). Fixes #314.
* shlibs: fall back to basename on macOS for relative paths. Fixes #222Christoph Reiter2019-03-251-7/+18
| | | | | | | | | | | | | | | | | | | On macOS we ideally want to write the final absolute path of the library into the gir and typelib. Up until now we inferred the install path from the .la file in case we used libtool and through otool in case we weren't using libtool hoping that the install_name was matching the install path. meson currently sets the install_name of libraries to "@rpath/foo.dylib" and adds rpaths to the executables in the build dir. Only during install does it change the install_name to the absolute target path in all places. Since we get called during build time we only get the @rpath from otool, which then makes things fail at runtime since the executables don't have the matching rpath set. To make this somewhat work just fall back to the basename for relative paths, so we dlopen "foo.dylib" and depend on things being in /usr/local/lib or DYLD_FALLBACK_LIBRARY_PATH including the lib path (see man dlopen)
* Clean shebangs out of non-executable scripts and drop exec perm from ↵Dominique Leuenberger2019-01-091-1/+0
| | | | xmlwriter.py
* Drop all Python 2 compat codeChristoph Reiter2018-12-081-5/+0
| | | | We only support 3.4+ now.
* scanner: Skip ldd for library by filenameOlivier Crête2018-11-051-1/+4
|
* shlibs: Don't depend on Python 3Christoph Reiter2018-07-111-1/+3
|
* Avoid accidental library name matches when parsing ldd output.Tomasz Miąsko2018-07-111-33/+40
| | | | | | | | | | * Use a single pattern that matches against potentially complete paths. * Extract filename only afterwards on platforms where it is necessary. * Match patterns against complete words in ldd output instead of searching for them inside the lines - this avoids unintentional matches without complexity of negative lookbehinds and negative lookaheads. Fixes issue #208.
* Allow overriding of the host os nameNicola Fontana2018-01-251-2/+2
| | | | | | | | Added the GI_HOST_OS environment variable to eventually specify the host OS explicitely. It fall backs to os.name to retain backward compatibility. https://bugzilla.gnome.org/show_bug.cgi?id=761985
* giscanner: Fix shared library name finding on *BSDTing-Wei Lan2018-01-091-0/+5
| | | | | | | | ldd commands on *BSD always print the name of the input file regardless of the number of arguments, so we have to ignore this line to avoid matching it with _ldd_library_pattern. https://bugzilla.gnome.org/show_bug.cgi?id=791991
* giscanner: Decode command output for Python 3 compatibilitySimon Feltman2015-09-291-0/+1
| | | | | | | Decode the output of various subprocess calls assuming ascii encoding. https://bugzilla.gnome.org/show_bug.cgi?id=679438
* giscanner: Use unicode literals in all Python filesSimon Feltman2015-09-291-0/+1
| | | | | | | | | | | | Add unicode_literals future import which turns any string literal into a unicode string. Return unicode strings from the Python C extension module. Force writing of annotations (g-ir-annotation-tool) to output utf8 encoded data to stdout. This is an initial pass at following the "unicode sandwich" model of programming (http://nedbatchelder.com/text/unipain.html) needed for supporting Python 3. https://bugzilla.gnome.org/show_bug.cgi?id=679438
* giscanner: Use print as a function for Python 3 compatibilitySimon Feltman2015-09-291-0/+1
| | | | | | | Use future import "print_function" and update relevant uses of print as a function call. See: PEP 3105 https://bugzilla.gnome.org/show_bug.cgi?id=679438
* giscanner: Enable "true division" for all Python filesSimon Feltman2015-09-291-0/+1
| | | | | | | | | | Import Python 3 compatible "true division" from the future (PEP 238). This changes the Python 2 classic division which uses floor division on integers to true division. Verfied we don't actually use the division operator anywhere in the code base so this a safety for supporting both Python 2 and 3. https://bugzilla.gnome.org/show_bug.cgi?id=679438
* giscanner: Use absolute_import for all Python filesSimon Feltman2015-09-291-0/+2
| | | | | | Use absolute_import to ensure Python 3 compatibility of the code base. https://bugzilla.gnome.org/show_bug.cgi?id=679438
* giscanner: Use items() instead of iteritems()Simon Feltman2015-09-291-1/+1
| | | | | | | Replace usage of iteritems() and itervalues() with items() and values() respectively. https://bugzilla.gnome.org/show_bug.cgi?id=679438
* scanner: remove unused importsDieter Verfaillie2015-06-291-1/+1
|
* giscanner: Add New CCompiler ModuleChun-wei Fan2014-08-051-86/+3
| | | | | | | | | | | | | | | This adds a CCompiler module for the giscanner Python scripts so that items related to the run of the preprocessor, compiler and linker can be done in this module, and this marks the beginning of the move of building the introspection files using Python's distutils. This patch first moves _add_[internal|external]_link_flags() to ccompiler.py as get_[internal|external]_link_flags and also moves the Windows shlibs resolution (deducing the DLLs the introspection files should link to from the libraries passed in) in shlibs.py to resolve_windows_libs() in ccompiler.py https://bugzilla.gnome.org/show_bug.cgi?id=728313
* PEP8 fixes in shlib.pySimon Feltman2014-02-261-7/+7
| | | | | | | Conform shlibs.py to the PEP8 standard. New additions were causing make check to fail: Fixed E211 whitespace before '(' Fixed E501 line too long (104 > 99 characters)
* scanner: Make shlib Resolution Work Also With Visual C++Chun-wei Fan2014-02-251-18/+52
| | | | | | | | | | | | | | | | | | | Commit f3fcdf97 introduced shlib resolution for Windows, but it only works with MinGW and would therefore break builds of introspection files for Visual C++. Improve on the situation by adding capabilities to do the same with Visual C++, as the introspection dumper program is still compiled and linked with the Microsoft tool set (only the proprocessor to process the various headers is using GCC/MinGW). This makes use of the dumpbin utility that is shipped with Visual C++, which will query a .lib file, which leads to the DLL that the .lib file will link to. The 'gcc -print-search-dirs' can be replaced on Visual C++ builds by querying the LIB environment variable, as this is what the Visual C++ compiler/linker really looks at during compilation and linkage. https://bugzilla.gnome.org/show_bug.cgi?id=724890
* scanner: Fix shlib resolution on W32Руслан Ижбулатов2014-02-221-3/+52
| | | | | | | | | GI just adds '.dll' to library name and calls it a day. There's a comment about how this function might work, i've used it to implement something better. This requires a compiler that supports -print-search-dirs argument (i.e. gcc) and a dlltool. https://bugzilla.gnome.org/show_bug.cgi?id=724890
* scanner: Improve compatibility with OS XClemens Lang2014-02-101-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While gobject-introspection works on OS X, a few circumstances are handled a little different there. For one, libraries are linked using absolute paths. The current gobject-introspection code however strips any path components and just uses the filename in the .gir file – while this doesn't cause failure, the generated typlibs will only work in presence of a correctly set DYLD_LIBRARY_PATH or DYLD_FALLBACK_LIBRARY_PATH environment variable. Setting DYLD_LIBRARY_PATH on OS X often is a bad idea due to the side-effects: Doing so causes the directory parts of libraries referenced using an absolute path to be ignored if there is a equally named file in the directory listed in $DYLD_LIBRARY_PATH, possibly overriding referenced system libraries with incompatible versions. Setting DYLD_FALLBACK_LIBRARY_PATH is the better solution for this problem; however because this variable has an implicit default value it's not simple to do so correctly. The best solution to the problem is referencing libraries from .girs using absolute paths, just as all other binaries on OS X. The attached patches against 2.38.0 implement that. Another quirk one needs to be aware of on OS X is that Apple ships a program called libtool, which is not GNU libtool and incompatible with it. GNU libtool, if present, is usually called glibtool on OS X. The patches also fix this. https://bugzilla.gnome.org/show_bug.cgi?id=709583
* tests: Update misc/pep8.py to 1.4.5Dieter Verfaillie2013-05-071-0/+4
| | | | | | | | | | | | | | | | | Version in our tree is a wee bit outdated. For example, later work will introduce an utf8 encoded python source file which our old pep8.py does not yet understand (yeah, it really was *that* ancient)... Updated from: https://raw.github.com/jcrocholl/pep8/1.4.5/pep8.py Takes 552c1f1525e37a30376790151c1ba437776682c5, f941537d1c0a40f0906490ed160db6c79af572d3, 5a4afe2a77d0ff7d9fea13dd93c3304a6ca993de and a17f157e19bd6792c00321c8020dca5e5a281f45 into account... https://bugzilla.gnome.org/show_bug.cgi?id=699535
* Unbreak giscanner on OpenBSD.Jasper Lievisse Adriaanse2013-03-281-1/+1
| | | | | | | Commit 9a1e0c63c13f3567e75553d2d07dd914d5b81287 broke this as os.name doesn't return 'OpenBSD', but 'posix' https://bugzilla.gnome.org/show_bug.cgi?id=696765
* giscanner: remove duplicate "os" import...Dieter Verfaillie2012-11-281-2/+1
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=688897
* giscanner/dumper.py: Use os.name instead of os.uname()[0]Chun-wei Fan2012-10-271-1/+1
| | | | | | | os.uname is not available universally, so use something that exists universally. https://bugzilla.gnome.org/show_bug.cgi?id=681820
* OpenBSD uses it's own libtool implementation which breaks giscanner in certainJasper Lievisse Adriaanse2011-11-181-0/+14
| | | | | | situations. So adjust resolve_non_libtool() in this case. https://bugzilla.gnome.org/show_bug.cgi?id=664282
* Windows port: fix _resolve_non_libtoolDieter Verfaillie2011-10-201-25/+32
| | | | | | By simply appending '.dll' to the library names. https://bugzilla.gnome.org/show_bug.cgi?id=620566
* [shlib] Use ldd on all non-Darwin platformsJohan Dahlin2010-06-061-4/+1
|
* [shlibs] Make pep8.py happyJohan Dahlin2010-06-051-1/+1
|
* [scanner] Barf if running on unsupported platformJohan Dahlin2010-06-041-3/+7
| | | | | Let us know explicitly if the platform is unsupported by the scanner.
* use "otool -L" instead of "ldd" on DarwinAlexey Zakhlestin2010-06-041-1/+5
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=606686
* Support passing --library=lib<foo>.laOwen W. Taylor2009-08-171-11/+41
| | | | | | | | | | | | | | | | In addition to the current --library=<foo>, support --library=lib<foo>.la. This makes it unambiguous that we are referencing an uninstalled library and allows accurate extraction of the shared library name for the uninstalled library. * tests/scanner/Makefile.am tests/offsets/Makefile.am: Use the new form of --library=. Also some LD_LIBRARY_PATH frobbing as needed. *-expected.gir *-expected.tgir: We now pick out the shared library accurately, so fix shared-library="" in our reference girs. (The comparison may need some pre-sanitization now to work on non-ELF) http://bugzilla.gnome.org/show_bug.cgi?id=591669
* Resolve library names to shared libraries ourselvesOwen W. Taylor2009-08-171-0/+77
Using ctypes.util.find_library() to resolve library names to sonames causes problems with dealing with uninstalled libtool operation properly. We're unlikely to find any way of combining the two that will be robust against future changes in both facilities. Switch to a different approach - run 'ldd' on the compiled introspection binary and extract sonames from there This is less portable but should be quite robust where it works. utils.py dumper.py: Move libtool-command-line finding into utils.py girwriter.py: Remove library name resolution from here, expect libraries to be passed in preresolved. shlibs.py scannermain.py: New file including resolve_shlibs() to resolve library names using the introspection binary. tests/scanner/Makefile.am: Add .libs to LD_LIBRARY_PATH http://bugzilla.gnome.org/show_bug.cgi?id=591669
View Lorry Controller Status