[ell-i-developers] Re: Robot Framework Testing: Test Cases Design, Scripting and other Issues

From: Asif Sardar <engr.asif.sardar@xxxxxxxxxxxxxx>
To: ell-i-developers@xxxxxxxxxxxxx
Date: Sat, 31 May 2014 22:43:05 +0300
Hi again,

While loading shared library from test scripts, I got following error:

*[ ERROR ] Error in file
'/home/asif/Ell-i-Working-Directory/Ell-i-Software-Testing/ELL-i-PyBot-Tests/test-suites/ELL-i-PyBot-Tests.wiki/DigitalRead.rest':
Importing test library
'/home/asif/Ell-i-Working-Directory/Ell-i-Software-Testing/ELL-i-PyBot-Tests/test-scripts/DigitalRead.py'
failed: OSError: ../libemulator.so: wrong ELF class: ELFCLASS32*
*Traceback (most recent call last):*
*  File
"/home/asif/Ell-i-Working-Directory/Ell-i-Software-Testing/ELL-i-PyBot-Tests/test-scripts/DigitalRead.py",
line 8, in <module>*
*    emulator = CDLL("../libemulator.so")*
*  File "/usr/lib/python2.7/ctypes/__init__.py", line 365, in __init__*
*    self._handle = _dlopen(self._name, mode)*

I tried to compile a 32 bit version of python (aliasing
python=/path/to/32/bit/python), install the robotframework using this
python. Still same problem ...

Some kind of problem as 32 bit vs 64 bit incompatibility ->
http://askubuntu.com/questions/398929/unable-to-load-shared-object-wrong-elf-class-elfclass32

Am I still using (default 64 bit python from /usr/bin/python/) for
installing robotframework ? Shall I try manually building the
robotframework from source code configuring it for 32-bit.

I don't want uninstall the default python, because some system scripts
might depend on that.

Any suggestions please ...


On Sat, May 31, 2014 at 10:21 PM, Asif Sardar <
engr.asif.sardar@xxxxxxxxxxxxxx> wrote:

> Hello all,
>
> Trying to load a shared library such as 'libemulator.so' using ctypes
> modules and running the test cases such as DigitalRead resulted in the
> following error:
>
>
>
>
>
>
> *[ ERROR ] Error in file
> '/home/asif/Ell-i/Ell-i-Pybot/ELL-i-PyBot-Tests/test-suites/ELL-i-PyBot-Tests.wiki/DigitalRead.rest':
> Importing test library
> '/home/asif/Ell-i/Ell-i-Pybot/ELL-i-PyBot-Tests/test-scripts/DigitalRead.py'
> failed: OSError: ../libemulator.so: wrong ELF class: ELFCLASS32 Traceback
> (most recent call last):  File
> "/home/asif/Ell-i/Ell-i-Pybot/ELL-i-PyBot-Tests/test-scripts/DigitalRead.py",
> line 9, in <module>    emulator = CDLL("../libemulator.so")  File
> "/usr/lib/python2.7/ctypes/__init__.py", line 365, in __init__
> self._handle = _dlopen(self._name, mode)*
>
> *---------------------------------------------------------------*
>
> @Pekka ---
> Besides that problem. Can you please check the emulator.mk and app.mk
> files attached to this e-mail. I messed my ubuntu system on Thursday and
> Friday while struggling with shared emulator library to start working with
> python scripts ... which resulted some lost files and crashes.
>
> So, if you can again guide me making shared library please... i get
> following error after applying patch for shared emulator library that you
> sent last week ...
>
> *make PLATFORM=emulator -f ../make/app.mk <http://app.mk> all*
> *make[1]: Entering directory
> `/home/asif/Ell-i-Working-Directory/Ell-i-Software-Development/Runtime/stm32/build'*
> *g++ -m32 -march=i386 -m32 -demangle -march=i386 -Xlinker -T -Xlinker
> ../scripts//elf_i386.xc -o sketch  main.o sketch.o ellduino.o "-L."
> "-L../variants/ellduino" "-lstm32f0" -lstdc++  *
> */usr/bin/ld: skipping incompatible ../variants/ellduino/libstm32f0.a when
> searching for -lstm32f0*
> */usr/bin/ld: cannot find -lstm32f0*
> *collect2: error: ld returned 1 exit status*
> *make[1]: *** [sketch] Error 1*
> *make[1]: Leaving directory
> `/home/asif/Ell-i-Working-Directory/Ell-i-Software-Development/Runtime/stm32/build'*
> *make: *** [all] Error 2*
>
>
>
>
>
> On Mon, May 26, 2014 at 7:39 PM, Asif Sardar <
> engr.asif.sardar@xxxxxxxxxxxxxx> wrote:
>
>> Hello all,
>>
>> Instead of using python C API to implement C libraries, it is often
>> easier to interact with C code from Python libraries using ctypes module.
>>
>> Please have a look at
>> https://github.com/Ell-i/ELL-i-PyBot-Tests/blob/master/test-scripts/DigitalRead.py
>>
>> This approach leaves much of the coding stuff to python. We can load the
>> shared library and call the C functionality easily using the ctypes
>> module's primitive C compatible fundamental data types.
>>
>>
>>
>>
>>
>> On Mon, Apr 28, 2014 at 2:05 PM, Asif Sardar <
>> engr.asif.sardar@xxxxxxxxxxxxxx> wrote:
>>
>>> > The first thing is to get the c-python modules in the
>>> arduino-functions/Digital-I-O to include the right subdirectories from the
>>> > Runtime.  The following in setup.py seems to work as a first
>>> approximation:
>>>
>>> > ---------------
>>> > from os import path
>>>
>>> > runtime='/my/path/to/Runtime'
>>>
>>> > arduelli   = path.join(runtime, 'cores/arduelli')
>>> > system_inc = path.join(runtime, 'system/stm32/inc')
>>> > cmsis      = path.join(runtime, 'system/stm32/CMSIS/Include')
>>> > variant    = path.join(runtime, 'variants/ellduino')
>>>
>>> > include_dirs=[arduelli, system_inc, cmsis, variant]
>>>
>>> > setup(name='digitalRead', version='1.0',
>>>    >   ext_modules=[Extension('
>>> > digitalRead',
>>> >                          ['Digital-I-O/digitalRead.c'],
>>> >                        include_dirs=include_dirs)])
>>> > --------------------
>>>
>>> > The key there is the include_dirs in creating the Extension. See
>>>
>>> >   https://docs.python.org/2.7/distutils/setupscript.html
>>>
>>> > for more information.
>>>
>>> > With that you can include <wiring_digital.h> in digitalRead.c, but
>>> note that it must be included *before* including <Python.h>.
>>> > That then allows you to call the actual Runtime functions, and it
>>> compiles.  Python also tries to load the resulting shared library, > but
>>> that fails.
>>>
>>> With above paths included into the extension modules, we can compile the
>>> c-python modules. But, we also need the libraries or executable code for
>>> these functions at runtime. When I run the test cases with c-python modules
>>> compiled with above setup.py script, the test suite exits with segmentation
>>> fault.
>>>
>>>
>>> > The next step would then be to actually add the emulator functions to
>>> the python runtime.  That I don't know yet how to do
>>> > exactly, but I imagine that it would be best to compile the emulator
>>> into a shared library, through adding a new make target in
>>> > Runtime/stm32/make, and then including the shared library into the
>>> (DY)LD_LIBRARY_PATH.  That might suffice.
>>>
>>> I think the shared library for emulator functions might help eliminating
>>> the above weird problems at runtime ...
>>>
>>>
>>>
>>> On Sun, Apr 27, 2014 at 4:42 PM, Pekka Nikander <pekka.nikander@xxxxxx>
>>> wrote:
>>>
>>>> > May I get some help regarding linking the c-python modules against
>>>> the emulator? I cannot call the Arduino functions directly from c-python
>>>> code files without linking against emulator and stm32 cores.
>>>>
>>>> I had a brief look at this today.  While I cannot present a full
>>>> solution, I think I made some progress.
>>>>
>>>> The first thing is to get the c-python modules in the
>>>> arduino-functions/Digital-I-O to include the right subdirectories from the
>>>> Runtime.  The following in setup.py seems to work as a first approximation:
>>>>
>>>> ---------------
>>>> from os import path
>>>>
>>>> runtime='/my/path/to/Runtime'
>>>>
>>>> arduelli   = path.join(runtime, 'cores/arduelli')
>>>> system_inc = path.join(runtime, 'system/stm32/inc')
>>>> cmsis      = path.join(runtime, 'system/stm32/CMSIS/Include')
>>>> variant    = path.join(runtime, 'variants/ellduino')
>>>>
>>>> include_dirs=[arduelli, system_inc, cmsis, variant]
>>>>
>>>> setup(name='digitalRead', version='1.0',
>>>>       ext_modules=[Extension('digitalRead',
>>>>                              ['Digital-I-O/digitalRead.c'],
>>>>                              include_dirs=include_dirs)])
>>>> --------------------
>>>>
>>>> The key there is the include_dirs in creating the Extension. See
>>>>
>>>>   https://docs.python.org/2.7/distutils/setupscript.html
>>>>
>>>> for more information.
>>>>
>>>> With that you can include <wiring_digital.h> in digitalRead.c, but note
>>>> that it must be included *before* including <Python.h>.  That then allows
>>>> you to call the actual Runtime functions, and it compiles.  Python also
>>>> tries to load the resulting shared library, but that fails.
>>>>
>>>> The next step would then be to actually add the emulator functions to
>>>> the python runtime.  That I don't know yet how to do exactly, but I imagine
>>>> that it would be best to compile the emulator into a shared library,
>>>> through adding a new make target in Runtime/stm32/make, and then including
>>>> the shared library into the (DY)LD_LIBRARY_PATH.  That might suffice.
>>>>
>>>> --Pekka
>>>>
>>>>
>>>
>>>
>>> --
>>>
>>>
>>>
>>> *With Best Regards,Asif Sardar.+358 43 8265795 <%2B358%2043%208265795> *
>>>
>>
>>
>>
>> --
>>
>>
>>
>> *With Best Regards,Asif Sardar.+358 43 8265795 <%2B358%2043%208265795>*
>>
>
>
>
> --
>
>
>
> *With Best Regards,Asif Sardar.+358 43 8265795 <%2B358%2043%208265795>*
>



-- 



*With Best Regards,Asif Sardar.+358 43 8265795*
References:
- [ell-i-developers] Re: Robot Framework Testing: Test Cases Design, Scripting and other Issues
  - From: Asif Sardar
- [ell-i-developers] Re: Robot Framework Testing: Test Cases Design, Scripting and other Issues
  - From: Asif Sardar
[ell-i-developers] Re: Robot Framework Testing: Test Cases Design, Scripting and other Issues

Other related posts:
