Capstone 2.1.2

[GoogleCodeExporter]

Capstone disasm engine 2.1.1 is out. Please update it for Pentoo.

More information is at www.capstone-engine.org. Thanks!
Thanks!

Original issue reported on code.google.com by aqu...@gmail.com on 13 Mar 2014 at 2:03

[GoogleCodeExporter]

bumped in r5562 . Thanks for reporting!

Original comment by blshkv on 17 Mar 2014 at 4:10

• Changed state: Fixed

[GoogleCodeExporter]

it turned out 2.1.1 did it wrong on the SONAME setup for libcapstone.so. are 
you still alright???

on Ubuntu, libcapstone.so cannot be loaded due to the wrong soname. so i doubt 
that Gentoo can be OK.

i committed a fix for this at 
https://github.com/aquynh/capstone/commit/017f18403829fbefd5d4d7518a9dd36c414e42
9f. thanks to this, Ubuntu now can load libcapstone.so and everything else 
seems fine.

any comment?

thanks.

Original comment by aqu...@gmail.com on 17 Mar 2014 at 7:35

[GoogleCodeExporter]

I relied on you and bumped without running. Apparently, both 2.1 and 2.1.1 
segfauts here:

/usr/share/capstone/tests/test
Segmentation fault

Original comment by blshkv on 18 Mar 2014 at 7:39

• Changed state: Accepted

[GoogleCodeExporter]

i suppose the latest code on "master" branch on github fixed this issue.
can you confirm?

https://github.com/aquynh/capstone/archive/master.zip

Original comment by aqu...@gmail.com on 18 Mar 2014 at 7:47

[GoogleCodeExporter]

btw, 2.1 should not segfault. can you compile "master" from command line,
install then run tests/test again?
if you dont see problem, something is wrong with package i guess.

Original comment by aqu...@gmail.com on 18 Mar 2014 at 7:56

[GoogleCodeExporter]

yeah, it works from master

Original comment by blshkv on 18 Mar 2014 at 8:39

[GoogleCodeExporter]

forgot to say, I had to create a symlink in order to avoid this problem:

./test: error while loading shared libraries: libcapstone.so.2: cannot open 
shared object file: No such file or directory

You might want to check you Makefile to make sure it creates it (I didn't run 
install and not sure)

Original comment by blshkv on 18 Mar 2014 at 8:42

[GoogleCodeExporter]

hmm so perhaps something is wrong with Pentoo package?

you can double check that 2.1 doesnt segfault either.

thanks.

Original comment by aqu...@gmail.com on 18 Mar 2014 at 8:43

[GoogleCodeExporter]

yes, please also run "make install", as "master" solved this issue.

i need few confirmation to release 2.1.2 to fix this "soname" problem, i
think.

thanks.

Original comment by aqu...@gmail.com on 18 Mar 2014 at 8:45

[GoogleCodeExporter]

I'll wait for the next version. You release it often enough so there is real 
need in a live ebuild =) . 

Original comment by blshkv on 18 Mar 2014 at 8:49

[GoogleCodeExporter]

Issue 250 has been merged into this issue.

Original comment by blshkv on 8 Apr 2014 at 4:09

[GoogleCodeExporter]

Original comment by blshkv on 8 Apr 2014 at 4:10

• Changed title: Capstone 2.1.2

[GoogleCodeExporter]

I'm getting sanbox violation during python compilcation with the latest 2.1.2 
release:

 * --------------------------- ACCESS VIOLATION SUMMARY ---------------------------
 * LOG FILE: "/var/log/sandbox/sandbox-31037.log"
 * 
VERSION 1.0
FORMAT: F - Function called
FORMAT: S - Access Status
FORMAT: P - Path as passed to function
FORMAT: A - Absolute Path (not canonical)
FORMAT: R - Canonical Path
FORMAT: C - Command Line

F: unlinkat
S: deny
P: /usr/lib64/python3.3/site-packages/capstone/__init__.py
A: /usr/lib64/python3.3/site-packages/capstone/__init__.py
R: /usr/lib64/python3.3/site-packages/capstone/__init__.py
C: /usr/bin/python3.3 setup.py build 

F: unlink
S: deny
P: /usr/lib64/python2.7/site-packages/capstone/__init__.py
A: /usr/lib64/python2.7/site-packages/capstone/__init__.py
R: /usr/lib64/python2.7/site-packages/capstone/__init__.py
C: /usr/bin/python2.7 setup.py build

Please provide a fix

Original comment by blshkv on 8 Apr 2014 at 9:06

[GoogleCodeExporter]

Original comment by blshkv on 8 Apr 2014 at 9:07

Attachments:

• capstone.log

[GoogleCodeExporter]

can you elaborate the problem? dont really get what is wrong from the above
log.

regarding Python 3, sorry but currently Python binding of Capstone only
supports Python 2.

Original comment by aqu...@gmail.com on 8 Apr 2014 at 9:14

[GoogleCodeExporter]

It usually happens when a software does not respect $(DESTDIR) or $(PREFIX) 
variables and trying to access/install files using absolute paths. I don't have 
time to debug it ATM. Can you try to compare it with version 2.1 or early? 

Original comment by blshkv on 8 Apr 2014 at 9:27

[GoogleCodeExporter]

Please hold on for awhile. I'm having the same problem with even 2.0. It might 
be Gentoo changed something

Original comment by blshkv on 8 Apr 2014 at 9:33

[GoogleCodeExporter]

OK, here is the problem:

20:11 <+floppym> blshkv: Try removing lines 7-16 of setup.py
20:12 <+floppym> It's trying to remove the installed copy there.

I did and it worked

Original comment by blshkv on 10 Apr 2014 at 1:08

[GoogleCodeExporter]

obviously, the same has to be done in setup_cython.py

Original comment by blshkv on 10 Apr 2014 at 1:09

[GoogleCodeExporter]

I've submitted the patch in the following commitment:
https://code.google.com/p/pentoo/source/detail?r=5600

feel free to fix it in the next version

Original comment by blshkv on 10 Apr 2014 at 1:30

[GoogleCodeExporter]

can you explain why removing old package directory fix the problem?
the idea of this code is to clean old code, and install the new one. so
that should not cause any problem.
i dont really get why your patch fixes it.

actually, this code has been there since forever, so why only now you see
the issue?

thanks.

Original comment by aqu...@gmail.com on 10 Apr 2014 at 2:35

[GoogleCodeExporter]

When gentoo builds a package, it is built and installed into a sandbox, then 
merged onto the live filesystem.

Touching the live filesystem in any way is entirely unacceptable.  As such, 
when you try to remove files from the live filesystem, sandbox prevent it, and 
tosses an error.  Since the package manager is already going to remove the old 
version for us, we can safely remove this bit of code with no ill effect.

Likely the reason this wasn't noticed till now is that no one ever tried to 
install without uninstalling first, so there were never files to delete.  Kind 
of odd, but entirely possible.

Personally, I'd suggest not removing files from user's systems during install, 
no part of that seems right.

Original comment by sidhayn on 10 Apr 2014 at 2:45

[GoogleCodeExporter]

oh right, got it.

agreed, this should be fixed in the next version.

thanks.

Original comment by aqu...@gmail.com on 10 Apr 2014 at 2:49

[GoogleCodeExporter]

Just to add, it seems python does not provide "uninstall" function. So it must 
be done by a packet manager (egg, portage, whatever).

And it's definitely wrong to delete random files from a *my* hdd, especially at 
the "build" stage. 

Gentoo might have ignored such attempts in the past, but it fails now. That's 
the only logical explanation I have.

Original comment by blshkv on 10 Apr 2014 at 3:03

[GoogleCodeExporter]

right, setup.py of Python never has uninstall function. you have to do that
yourself.
this is why i added that code cleaning up old package in setup.py

Original comment by aqu...@gmail.com on 10 Apr 2014 at 3:07

[GoogleCodeExporter]

Original comment by blshkv on 10 Apr 2014 at 1:08

• Changed state: Fixed

[GoogleCodeExporter]

cool! but how did you fix the problem?

Original comment by aqu...@gmail.com on 10 Apr 2014 at 1:57

[GoogleCodeExporter]

Which one? ;-) check out my last two commits.

Original comment by blshkv on 10 Apr 2014 at 2:02