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

Compilation issues #85

Open
mister-Q opened this issue Sep 26, 2023 · 8 comments
Open

Compilation issues #85

mister-Q opened this issue Sep 26, 2023 · 8 comments

Comments

@mister-Q
Copy link

Hi,
I am trying to compile python bindings to test libvmi with volatility, but got compilation errors :
(BTW: All libvmi/libkvmi examples are working with my VM and libvmi is installed on my system)

x86_64-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O2 -Wall -g -ffile-prefix-map=/build/python3.9-RNBry6/python3.9-3.9.2=. -fstack-protector-strong -Wformat -Werror=format-security -g -fwrapv -O2 -g -ffile-prefix-map=/build/python3.9-RNBry6/python3.9-3.9.2=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/python3.9 -c build/temp.linux-x86_64-3.9/_libvmi.c -o build/temp.linux-x86_64-3.9/build/temp.linux-x86_64-3.9/_libvmi.o

build/temp.linux-x86_64-3.9/_libvmi.c: In function ‘_cffi_checkfld_typedef_access_context_t’:

build/temp.linux-x86_64-3.9/_libvmi.c:1050:12: error: ‘access_context_t’ has no member named ‘version’
 1050 |   (void)((p->version) | 0);  /* check that 'access_context_t.version' is an integer */
      |            ^~

Indeed this struct has no member (def in /usr/local/include/libvmi.h)
BTW: header file in build/lib.linux-xxx/libvmi_cdef.h is present.

So my questions are:

  • Am i using the right repo (i used kvm-vmi in order to use kvm as hypervisor)
  • Is python bindings still the way to go to link libvmi with volatility3 (i have seen another project microvmi)
  • could i have some help regarding to these errors ?
    Best regards,
@Wenzel
Copy link
Member

Wenzel commented Sep 27, 2023

Hi,

i've just installed libvmi from master branch, created a venv, and ran

python3 setup.py build

it completed without any issues.

How did you proceed to get the error ?

@mister-Q
Copy link
Author

well it seems to me that i have done this exactly.
Installed kvm, qemu, mibkvmi then libvmi (so i got include in /usr/local/include/libvmi.h)
Created a domain
--> all examples working

Now I try to install python bindings

$ git clone https://github.com/KVM-VMI/python.git 
$ virtualenv -p python3 venv 
$ source venv/bin/activate 
$ python3 ./setup.py build 

--> errors

==> I should say that i am not python friendly:)

@Wenzel
Copy link
Member

Wenzel commented Sep 29, 2023

I retriggered a CI build, and I had to fixes a few things in libvmi dependencies, etc
but the build works:
#86
https://github.com/libvmi/python/actions/runs/6353687904/job/17258819604

@pjcolp
Copy link

pjcolp commented Dec 5, 2023

I've been having this same issue. For reference, I'm trying to build it on Oracle Linux 7. As best I can tell, what's happening (or not happening) is that the stuff that gets created in build/lib.linux-x86_64-3.8 is not being included in the build. Nor do I see it adding any sort of -l libvmi or even -l glib-2.0 for that matter. I don't know what the correct gcc line is supposed to look like, but this is what I have:

gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -I/opt/rh/rh-python38/root/usr/include -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -I/opt/rh/rh-python38/root/usr/include -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -fPIC -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/opt/rh/rh-python38/root/usr/include/python3.8 -c build/temp.linux-x86_64-3.8/_libvmi.c -o build/temp.linux-x86_64-3.8/build/temp.linux-x86_64-3.8/_libvmi.o

@pjcolp
Copy link

pjcolp commented Dec 5, 2023

Digging into it a bit more, it makes no difference whether I include libraries=libs or not, so I think the issue is indeed something to do with it not including the libraries. I've tried various different incantations, and nothing so far has helped (or made any difference at all).

@Wenzel
Copy link
Member

Wenzel commented Dec 6, 2023

@pjcolp this is the build script that's used to create the GCC command line:
https://github.com/libvmi/python/blob/master/libvmi/libvmi_build.py

If you have a Dockerfile to repro this issue, we can take a look.

@pjcolp
Copy link

pjcolp commented Dec 6, 2023

Unfortunately I don't have a Dockerfile, but this is just running python3 setup.py build, which calls libvmi_build.py. I've been mucking about in that file trying to chase this down -- that's how I know that removing the library stuff makes no difference to the generated gcc line (for me). I would be curious to see what the gcc line is supposed to look like, though. I looked at the output from the CI build above, but I couldn't find the actual gcc command that was invoked.

@pjcolp
Copy link

pjcolp commented Dec 6, 2023

I just tried compiling it on an OL8 box and that worked fine. It could just be an issue with the python packages on OL7.

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

No branches or pull requests

3 participants