We Keep Coding

How do I avoid an ELFCLASS64 error when building Android 8 from source?

I have an old tablet I'm toying around with for the fun of it. I'm trying to build Android 8 from source just to tinker with it and see if I can install it on the tablet. I'm using Lubuntu 20.04 LTS.
So far, all I've done is set up my environment, sync to the android-8.1.0_r81 repo, and run m, all per the instructions here: https://source.android.com/setup
My tablet uses an ARMv7 processor, so when I ran lunch I chose aosp_arm-eng, which corresponds to a generic 32-bit ARMv7 processor.
However, when I run m, it eventually fails with the following error:
[ 0% 1/9730] build out/target/product/generic/obj/ETC/sepolicy_tests_intermediates/sepolicy_tests
FAILED: out/target/product/generic/obj/ETC/sepolicy_tests_intermediates/sepolicy_tests
/bin/bash -c "(python out/host/linux-x86/bin/sepolicy_tests.py -l out/host/linux-x86/lib64 -f out/target/product/generic/obj/ETC/plat_file_contexts_intermediates/plat_file_contexts -f out/target/product/generic/obj/ETC/nonplat_file_contexts_intermediates/nonplat_file_contexts -p out/target/product/generic/obj/ETC/sepolicy_intermediates/sepolicy ) && (touch out/target/product/generic/obj/ETC/sepolicy_tests_intermediates/sepolicy_tests )"
Traceback (most recent call last):
File "out/host/linux-x86/bin/sepolicy_tests.py", line 73, in <module>
pol = policy.Policy(options.policy, options.file_contexts, options.libpath)
File "/home/username/Android/Development/Oreo/out/host/linux-x86/bin/policy.py", line 255, in __init__
self.__InitLibsepolwrap(LibPath)
File "/home/username/Android/Development/Oreo/out/host/linux-x86/bin/policy.py", line 190, in __InitLibsepolwrap
lib = CDLL(LibPath + "/libsepolwrap.so")
File "/home/username/Android/Development/Oreo/prebuilts/python/linux-x86/2.7.5/lib/python2.7/ctypes/__init__.py", line 365, in __init__
self._handle = _dlopen(self._name, mode)
OSError: out/host/linux-x86/lib64/libsepolwrap.so: wrong ELF class: ELFCLASS64
...
From what I understand, the out directory is the output of the make command--out isn't in the original repo. I also understand (I think) that the wrong ELF class: ELFCLASS64 error means that the libsepolwrap.so library is expecting a 32-bit OS and getting a 64-bit one. What I don't understand is why libsepolwrap.so is expecting a 32-bit OS.
According to the docs,
A 64-bit environment is required for Android 2.3.x (Gingerbread) and higher versions, including the master branch. You can compile older versions on 32-bit systems.
Given that I haven't actually modified anything yet and I'm building a pure vanilla Android 8 ROM, I'm stumped as to how to even start trying to fix this.
Side Note: I am already aware that I can find a vanilla Android 8 ROM somewhere online; I'm more interested in building it myself so I can learn the process and have something to tinker with.

ImportError libssl.so.6: cannot open shared object file error even after having the file in the path

I am getting following error even after having following packages installed. Recently os has been upgraded and python has been updated from 2.5 to 2.7 and before that application was using 2.7.11 which is installed on local folder.
After up gradation I am unable to run my scirpts and getting following ssl error.
File "/itStorage/tools/swutils/pylibs/shu/common.py", line 5, in <module>
import ssl
File "/itStorage/tools/swutils/deps/python_2.7.11/lib/python2.7/ssl.py", line 97, in
import _ssl # if we can't import it, let the error propagate
ImportError: libssl.so.6: cannot open shared object file: No such file or directory
After searching google it may be due to openssl packages or libssl path. we have every thing in place even after that we having issue.
[aafedc#afeae ~]$ sudo rpm -qa *openssl*
openssl-1.0.2k-8.el7.x86_64
openssl-devel-1.0.2k-8.el7.x86_64
openssl-libs-1.0.2k-8.el7.i686
openssl-libs-1.0.2k-8.el7.x86_64
openssl098e-0.9.8e-29.el7_2.3.i686
[abcd#abcd ~]$ sudo ls -l /usr/lib/libssl.so.6*
lrwxrwxrwx. 1 root root 16 May 25 03:34 /usr/lib/libssl.so.6 -> libssl.so.0.9.8e
any help is greatly appropriated!!..
Thanks in advance.

You could try to run the script using strace, then you should see what fails.. I'm not sure but I think it could be a missing dependency of libssl as well or permissions problem.

Permission denied on dl.open() with ipython but not with python

My initial goal is to open a dll file on Cygwin using ctypes. However I found some issues with it. I dug up to sys.dl which returns an unknown Permission denied only on IPython.
With python everything looks fine:
$ ls
my.dll
$ python
Python 2.7.8 (default, Jul 28 2014, 01:34:03)
[GCC 4.8.3] on cygwin
>>> import dl
>>> dl.open('my.dll')
<dl.dl object at 0xfffaa0c0>
With ipython I get the error:
$ ipython
Python 2.7.8 (default, Jul 28 2014, 01:34:03)
In [1]: import dl
In [2]: dl.open('my.dll')
---------------------------------------------------------------------------
error Traceback (most recent call last)
<ipython-input-2-c681630fa713> in <module>()
----> 1 dl.open('my.dll')
error: Permission denied
I investigated on this using strace. The output log for `IPython is huge, more than 4MB. Fortunately, I identified some weird things:
symlink.check(C:\Users\user\Home\projects\foo\my.dll, 0x28AB88) (0x4022)
35 2705178 [main] python2.7 16924 path_conv::check: this->path(C:\Users\user\Home\projects\foo\my.dll), has_acls(1)
37 2705215 [main] python2.7 16924 cwdstuff::get: posix /cygdrive/c/Users/user/Home/projects/foo
32 2705247 [main] python2.7 16924 cwdstuff::get: (C:\Users\user\Home\projects\foo) = cwdstuff::get (0x8006ECF0, 32768, 0, 0), errno 11
--- Process 14376, exception c0000138 at 7726163E
3286 2708533 [main] python2.7 16924 seterrno_from_win_error: /home/corinna/src/cygwin/cygwin-1.7.35/cygwin-1.7.35-1.i686/src/src/winsup/cygwin/dlfcn.cc:174 windows error 182
42 2708575 [main] python2.7 16924 geterrno_from_win_error: unknown windows error 182, setting errno to 13
36 2708611 [main] python2.7 16924 dlopen: ret 0x0
Who is /home/corinna? I have no corinna user in my installation, neither on my Windows. Corinna does not come from my installation. Is it some hard-coded stuff?
Now, here is what I get from strace for python:
symlink.check(C:\Users\user\Home\projects\foo\my.dll, 0x28B728) (0x4022)
26 10440048 [main] python 12604 path_conv::check: this->path(C:\Users\user\Home\projects\foo\my.dll), has_acls(1)
23 10440071 [main] python 12604 cwdstuff::get: posix /cygdrive/c/Users/user/Home/projects/foo
25 10440096 [main] python 12604 cwdstuff::get: (C:\Users\user\Home\projects\foo) = cwdstuff::get (0x8006ECF0, 32768, 0, 0), errno 0
3405 10443501 [main] python 12604 dlopen: ret 0x5B9C0000
dlopen is returning 0x0 in IPython while it is returning 0x5B9C0000 for python. I notice that cwdstuff::get is raising an error before dlopen is called.
EDIT
I sent a message to Cygwin's mailing list and the answer of Corinna regarding this issue is:
This is not Cygwin's fault, AFAICS. Cygwin never loads functions by
ordinal. This is also a bit on the lean side as far as information is
concerned. One can't see how the process calls dlopen, for instance.
Corinna
How to solve this issue?
My earlier tests using ctypes
Initially when I asked my question I was just playing with ctypes.
I am working on Cygwin 32-bit and Windows 7.
With IPython I got an OSError when I tried to load a dll using cdll.LoadLibrary.

Two ideas:
1) in the next cell, type %pdb, and then interactively "print self._name" to see what it is.
2) Use a full path to cdll.LoadLibrary("foo.dll") to see if that works.
Once you know what the issue is, then you can decide whose bug it is, and report it (could be a ctypes issue, but probably ipython)

More ideas:
Check that the user accessing the DLL is the same. You do that like this:
import getpass
print(getpass.getuser())
Check what's the current process actually doing. I haven't used cygwin but in the linux shell the executable strace should show you this.
Usage: get the PID of your current process: import os; os.getpid()
After this, you can use (from outside the python/ipython console the command strace -p <the pid> -e file. After this setup, you can try to load your DLL.
Remarks: the -e file flag should be written exactly like that. The word file tells strace to report all file operations that the process makes. If no differences occur when running on python/ ipython, you can try dropping the -e file flag. Then you will see all system calls that the process makes. I haven't worked on windows like that, so this might not work at all there, but on linux at least, this should report to you everything that the process did. You could see there at least all the files that got opened, but more interesting things could be found there as well. If the outputs are identical, then the problem can be debugged further in python/ ipython. This would require basically what #Doug Blank suggested, but I'd also recommend investigating every name (variable) that gets touched. The self, _dlopen and mode names also sound like they might contain useful information.
Otherwise, do a dir(self) and dir(_dlopen) to see what other properties you could find there that might have gotten modified by IPYthon.
Try these first, and after that we can help you dig further.

Perhaps Python executable and IPython kernel use different manifest files which define loading policy?
Try appending the DLL path to sys.path in both cases.
Check admin rights (UAC) in both cases.
Use dependency walker to figure out dependencies of this DLL. Maybe the problem comes from dependencies?
Possibly your machine has multiple copies of this DLL?
Finally you can use Process Explorer to see the list of DLLs loaded in both cases and see any differences.
I'm working on a very similar issue:
ipython notebook & script difference - loading DLLs

Cannot connect to a ssl-enabled perforce server using p4python

Python version: 2.7.8
P4Python version: P4PYTHON/NTX86/2014.1/807760 (2014.1/807760 API) (2014/03/18)
Client OS: Win2k8 Server
Python script:
from P4 import P4, P4Exception
p4agent = P4()
p4agent.port = "ssl:my-perforce-server.com:1666"
p4agent.user = "abc"
p4agent.password = "a$3"
p4agent.connect()
p4agent.run_login()
Output:
Traceback (most recent call last):
File "C:\Users\Administrator\Desktop\PythonSync\P4Sync.py", line 44, in <module>
getLatestRevision()
File "C:\Users\Administrator\Desktop\PythonSync\P4Sync.py", line 41, in getLatestRevision
initP4()
File "C:\Users\Administrator\Desktop\PythonSync\P4Sync.py", line 36, in initP4
p4agent.connect()
File "c:\python27\lib\site-packages\P4.py", line 678, in connect
P4API.P4Adapter.connect( self )
P4Exception: [P4.connect()] Connect to server failed; check $P4PORT.
SSL library must be at least version 1.0.1.
p4agent.identify() output:
Perforce - The Fast Software Configuration Management System.
Copyright 1995-2014 Perforce Software. All rights reserved.
This product includes software developed by the OpenSSL Project
for use in the OpenSSL Toolkit (http://www.openssl.org/)
See 'p4 help legal' for full OpenSSL license information
Version of OpenSSL Libraries: OpenSSL 1.0.1d 5 Feb 2013
Rev. P4PYTHON/NTX86/2014.1/807760 (2014.1/807760 API) (2014/03/18).
The path to OpenSSL (lib) is set in the Path variable.
I also checked 'p4 set' on the client machine (from where I am trying to connect to the perforce server) and I see that all environment variables are properly set.
Can someone please let me know how to resolve this?

I believe the problem is that you are linking with the wrong Openssl library. The output of P4.identify() is misleading: this is the version of the OpenSSL the API was compiled with, not the version you are linking against.
Where did you get that version of P4Python from? Did you compile it yourself or did you download it from some other site?
If you want to use a ready-made version of P4Python for Windows Python 2.7 and 3.4 32bit and 64bit, please have a look at https://swarm.workshop.perforce.com/projects/p4pythonlib/files/p4pythonlib/bin. Let me know if you have any problems with these builds.

wxPython import error

I'm having trouble figuring out an error message in Python.
yesterday, I've installed python using the latest EPD package, and wxPython2.9 using the wxPython2.9-osx-cocoa-py2.7 package for Mac OS.
I then added wx to my PYTHONPATH.
export WXDIR=/usr/local/lib/wxPython-2.9.1.1/lib/python2.7/site-packages/wx-2.9.1-osx_cocoa
export PYTHONPATH=$WXDIR
export PYTHONPATH=$PYTHONPATH:$WXDIR/tools
but when I try to run stuff I get this error:
In [14]: import matplotlib.pyplot
---------------------------------------------------------------------------
ImportError Traceback (most recent call last)
/Users/imrisofer/Documents/third/hddm-read-only/hddm/<ipython console> in <module>()
/Library/Frameworks/EPD64.framework/Versions/7.0/lib/python2.7/site-packages/matplotlib/pyplot.py in <module>()
93
94 from matplotlib.backends import pylab_setup
---> 95 new_figure_manager, draw_if_interactive, show = pylab_setup()
96
97 #docstring.copy_dedent(Artist.findobj)
/Library/Frameworks/EPD64.framework/Versions/7.0/lib/python2.7/site-packages/matplotlib/backends/__init__.py in pylab_setup()
23 backend_name = 'matplotlib.backends.%s'%backend_name.lower()
24 backend_mod = __import__(backend_name,
---> 25 globals(),locals(),[backend_name])
26
27 # Things we pull in from all backends
/Library/Frameworks/EPD64.framework/Versions/7.0/lib/python2.7/site-packages/matplotlib/backends/backend_wxagg.py in <module>()
21
22 from backend_agg import FigureCanvasAgg
---> 23 import backend_wx # already uses wxversion.ensureMinimal('2.8')
24 from backend_wx import FigureManager, FigureManagerWx, FigureCanvasWx, \
25 FigureFrameWx, DEBUG_MSG, NavigationToolbar2Wx, error_msg_wx, \
/Library/Frameworks/EPD64.framework/Versions/7.0/lib/python2.7/site-packages/matplotlib/backends/backend_wx.py in <module>()
43 import wxversion
44 except ImportError:
---> 45 raise ImportError(missingwx)
46
47 # Some early versions of wxversion lack AlreadyImportedError.
ImportError: Matplotlib backend_wx and backend_wxagg require wxPython >=2.8
I can successfully import wx, so I don't no what's the problem.
Am I missing anything in the PYTHONPATH?

In Ubuntu 12.04, this problem can be solved by running the command
sudo apt-get install libjpeg62
I realize this may not be useful here, but I wanted to document it somewhere on teh interwebz so I can find it when I run into this problem again myself which will undoubtedly happen.

I'm using Ubuntu 13.10, Canopy 1.2, and PyCharm 3.0.2. When trying to use matlablib, it always complains "Matplotlib backend_wx and backend_wxagg require wxPython >=2.8".Pretty sure that I'm using wxPython 2.8. Then I tried all the methods described in this page, but neither of them works for me.
It turns out that it can be solved by modifying matplotlibrc file. There is a line:
backend : WXAgg
In fact we can change the backend to whatever we like, and I change it to TKAgg, which works just fine for me.

Select your wx version before importing any wx modules
import wxversion
wxversion.select('2.8')
The above code should come before import wx

This happened to me on a Windows x64 installation that did not install wxversion.py in the site-packages directory (c:\Python27\Lib\site-packages by default).
You can get a copy of wxversion.py from the WX svn repository:
http://svn.wxwidgets.org/viewvc/wx/wxPython/trunk/wxversion/wxversion.py?content-type=text%2Fplain&view=co

this link helped me
https://support.enthought.com/entries/22601196-wxPython-2-8-and-2-9
Here's how I fixed the problem, which I hope will be useful for others in future
In Terminal: gedit Enthought/Canopy_64bit/User/lib/python2.7/site-packages/matplotlib/mpl-data/matplotlibrc
Edit the line "backend : WXAgg" into "backend : QtAgg"
Save and exit

I just ran into this myself. One potential cause of this (quite unhelpful) error message is if you installed wx as a single-version installation (INSTALL_MULTIVERSION=0 when running setup.py). In this case, the module wxversion does not get built (or installed) and as such matplotlib incorrectly assumes that all of wx is missing.
This currently is the default setting in installations by the homebrew version of wxWidgets (wxmac) with the option --python.
In your case (albeit a year and a half late), you'd need to ensure that wxversion.py exists within /usr/local/lib/wxPython-2.9.1.1/lib/python2.7/site-packages/. If it doesn't, you'd need to recompile wx with the above flag set. Otherwise you just need to set your $PYTHONPATH such that it includes the base site-packages directory, too:
export WXDIR=/usr/local/lib/wxPython-2.9.1.1/lib/python2.7/site-packages
export PYTHONPATH=$WXDIR:$WXDIR/wx-2.9.1-osx_cocoa:$WXDIR/wx-2.9.1-osx_cocoa/tools

I've solved with this:
defaults write com.apple.versioner.python Prefer-32-Bit -bool yes

I solved this by setting the backend to MacOSX in ~/.matplotlib/matplotlibrc:
backend : MacOSX

I've solved this on Windows by looking in the site packages folder in the python library. In there, there should be another folder titled site-packages. In this subfolder, there is the wxversion library. If you copy this library into the Lib folder in python, this import error should be averted.

sudo apt-get install python-wxtools
Install it. Worked for me.