Address "WARNING :: Failed to get_static_lib_exports(*.a)"#4221
Address "WARNING :: Failed to get_static_lib_exports(*.a)"#4221mbargull wants to merge 5 commits intoconda:mainfrom
Conversation
| # print(syms_b) | ||
| else: | ||
| obj = lief.ELF.parse(raw=content[obj_start:obj_end]) | ||
| obj = lief.ELF.parse(raw=list(content[obj_start:obj_end])) |
There was a problem hiding this comment.
lief.parse accepts raw: bytes or raw: List[int], but lief.*.parse only accepts raw: List[int].
0d712d0 to
ee24322
Compare
| imported_function_names = set() | ||
| if len(binary.exported_functions): | ||
| syms = binary.exported_functions | ||
| imported_function_names = {s.name for s in binary.imported_functions} |
There was a problem hiding this comment.
I don't really know if this is the correct thing to do. Just made sense given the names of lief.Binary's members.
| pass | ||
| res = [] | ||
| imported_function_names = set() | ||
| if len(binary.exported_functions): |
There was a problem hiding this comment.
NB: Due to lack of deeper knowledge of LIEF, I have no idea what the implications are in prioritizing binary.exported_functions over binary.symbols over binary.static_symbols. So, IDK if it makes sense to use a (maybe?) smaller set of symbols from .exported_functions rather than just .symbols.
ee24322 to
0d91589
Compare
0d91589 to
a964af9
Compare
|
@isuruf, @xhochy, apart from Ray, you are the ones that I know of who had a look at LIEF or related code. Could one of you take a look at this? |
I sadly don't have any expertise either that would go beyond running this code and seeing whether it passes. So I cannot add something on top of what other conda-build reviewers would do here. |
|
Hi there, thank you for your contribution! This pull request has been automatically marked as stale because it has not had recent activity. It will be closed automatically if no further activity occurs. If you would like this pull request to remain open please:
NOTE: If this pull request was closed prematurely, please leave a comment. Thanks! |
|
Hi there, thank you for your contribution! This pull request has been automatically marked as stale because it has not had recent activity. It will be closed automatically if no further activity occurs. If you would like this pull request to remain open please:
NOTE: If this pull request was closed prematurely, please leave a comment. Thanks! |
lief.Function from the Python API does not seem to expose flags directly. Maybe lief.Binary.imported_functions can act as a counterpart to lief.Binary.exported_functions then?
Signed-off-by: Marcel Bargull <marcel.bargull@udo.edu>
a964af9 to
e828b60
Compare
|
pre-commit.ci autofix |
for more information, see https://pre-commit.ci
|
Hi there, thank you for your contribution! This pull request has been automatically marked as stale because it has not had recent activity. It will be closed automatically if no further activity occurs. If you would like this pull request to remain open please:
NOTE: If this pull request was closed prematurely, please leave a comment. Thanks! |
|
Not stale |
|
Hi there, thank you for your contribution! This pull request has been automatically marked as stale because it has not had recent activity. It will be closed automatically if no further activity occurs. If you would like this pull request to remain open please:
NOTE: If this pull request was closed prematurely, please leave a comment. Thanks! |
|
not stale |
Currently,
conda-buildprints outWARNING :: Failed to get_static_lib_exports(*.a)whenever static libraries are using in the builds.This is because of a mismatched type of
lief.*.parse(raw=...)(explicitly needsList[int]rather thanbytes).When the parameter type is fixed, it fails because
lief.Binary.exported_functionsgives an iterable oflief.Functionobjects (or just names, i.e.,strs, in older versions) which do not have.exported/.importedmembers.I can't say with any confidence, I know what I'm doing here because I did not dig in too deep of LIEF, the surrounding code and everything. Silver lining: If the changed code now raises another exception, the behavior would be identical because the previous one always failed (and the exception is caught and replaced the the mentioned warning). The unknown for me is just in case no exception is raised, IDK what difference a non-empty list of returned "imported by not exported" symbols affects.