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
consider not relying on libbfd #7001
Comments
Comment author: @johnwhitington libbfd doesn't ship with OS X currently, either: [WARNING] BFD library not found, 'objinfo' will be unable to display info on .cmxs files. I believe this is a recent change, since I don't remember warnings on ./configure until recently. |
Comment author: @xavierleroy libbfd is used in one rarely-used OCaml tool (ocamlobjinfo), in the rarely-exercised case where ocamlobjinfo is given a .cmxs file. If libbfd is not there, everything else will still work (AFAIK). Besides, it's not like we can reimplement libbfd ourselves, the various formats of shared object files are just too complicated for that. Concerning MacOS X, you may have to install it using Macports or Homebrew. Unless you have a better alternative to libbfd to propose, I move to close this PR. |
Comment author: @whitequark
I entirely disagree. First we don't need to; platforms already have the format descriptions in the C bindings (the kernel header elf.h on Linux; winnt.h and its IMAGE_FILE_* structures on Windows; mach_* on OS X). Second, we don't need all of libbfd, we only need to look up one symbol, which is trivial; the libbfd-independent code shouldn't even be longer than the existing code, with the catch that it has to be in triplicate. |
Comment author: @xavierleroy We're not big fans of libbfd either, which is why it is not used by the OCaml compilers, despite some temptation to use it (e.g. #6779, #6845). Nonetheless, I think we all collectively have many more urgent things to do than reimplement parts of libbfd in OCaml so that an obscure use case of an obscure tool works on systems that lack libbfd. I move to resolve/suspend this PR. |
Comment author: @whitequark I still disagree because I think that, if implemented, such support for symbol lookup without libbfd would be useful in cross-compilation as well. |
Comment author: @xavierleroy All right, I keep this PR alive, but with a target after 4.03, and a "feature wish" tag. |
This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc. |
This issue can be closed, I think. |
Closing as suggested. Nonetheless, I'd be interested to know what alternatives to libbfd exist already. |
@xavierleroy I'm not aware of anything lightweight that would be appropriate for use in OCaml. I know of LLVM machine code libraries (that depend on LLVM), and there are Rust libraries (that depend on Rust), but it seems that your original judgement about this (as quoted below) was spot-on and no one is particularly interested in solving this specific problem.
|
FWIW there has been renewed interest (at least by me) in the context of the library linking proposal see e.g. #9306 and ocaml/RFCs#17 in particular for the Dynlink API. |
I agree with @dbuenzli that if we had a "good" alternative to libbfd (portable, widely available, license-compatible, and actively maintained by someone else), we'd have other uses for it. Thanks @whitequark for the pointers. |
There is also a LIEF but it's written in C++ and quite heavy for this use, it also focuses on the instrumenting and patching binaries instead. |
Original bug ID: 7001
Reporter: @whitequark
Status: acknowledged (set by @xavierleroy on 2015-11-24T10:37:29Z)
Resolution: open
Priority: normal
Severity: feature
Target version: later
Category: tools (ocaml{lex,yacc,dep,debug,...})
Monitored by: @gasche @diml
Bug description
libbfd is not easily available, e.g. it does not ship with the stock Android toolchain. This presents a problem if someone wants to use native code plugins on Android. This is a milder version of bug #6779, in essence.
(This is not a problem on iOS because iOS does not have dynamic libraries.)
See also ocaml-cross/opam-cross-android#11.
The text was updated successfully, but these errors were encountered: