Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handle 64-bit binaries in elf/dl #289

Merged
merged 22 commits into from
Jan 17, 2021
Merged

Handle 64-bit binaries in elf/dl #289

merged 22 commits into from
Jan 17, 2021

Conversation

NiLuJe
Copy link
Member

@NiLuJe NiLuJe commented Jan 15, 2021

That should hopefully have been the last non-toolchain-related hurdle for an aarch64 build ;).


This change is Reviewable

Copy link
Member

@Frenzie Frenzie left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you say so. :-P

@pazos
Copy link
Member

pazos commented Jan 15, 2021

That should hopefully have been the last non-toolchain-related hurdle for an aarch64 build ;).

The standalone example worked before, but I guess it was because LuaJIT was part of the main shared lib?

@NiLuJe
Copy link
Member Author

NiLuJe commented Jan 15, 2021

@pazos: What standalone example? ^^.

(The two formats are very similar, there's a vague chance using the Elf32 data types on a 64-bit host mostly worked for what we were doing).

@Frenzie
Copy link
Member

Frenzie commented Jan 15, 2021

@NiLuJe examples/helloWorld I imagine

@NiLuJe
Copy link
Member Author

NiLuJe commented Jan 16, 2021

Yep, confirmed that it failed on Elf64 files before (random test on an x64 binary ;p).

luajit utils/print_dt_needed.lua /usr/bin/ag
luajit: utils/elf.lua:164: no .dynstr section in /usr/bin/ag
stack traceback:
        [C]: in function 'assert'
        utils/elf.lua:164: in function 'dlneeds'
        utils/print_dt_needed.lua:14: in main chunk
        [C]: at 0x55d8662fdfc0
needed => libpcre.so.1 (1 of 5) <= /usr/bin/ag
needed => liblzma.so.5 (2 of 5) <= /usr/bin/ag
needed => libz.so.1 (3 of 5) <= /usr/bin/ag
needed => libpthread.so.0 (4 of 5) <= /usr/bin/ag
needed => libc.so.6 (5 of 5) <= /usr/bin/ag

It's liable to be more informative, and tell us exactly *why* it failed
to open.
Because the string from error might be lost in the logcat noise, or
something, depending on who catches it.
@NiLuJe
Copy link
Member Author

NiLuJe commented Jan 16, 2021

Tweaked the logging and asserts some more, and actually tested on a real device ;p.

@NiLuJe NiLuJe merged commit b6663f7 into koreader:master Jan 17, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants