[etherlab-users] Limitations on Matlab Version - R2018b vs R2019a
Moritz Schappler
moritz.schappler at imes.uni-hannover.de
Mon Apr 6 18:10:55 CEST 2020
The remark on the external mode patch was perhaps misleading. To test
this I used the official versions of the mercurial repos and not the
patched version.
When comparing the output of `make VERBOSE=1 clean all`, it becomes
obvious that the argument "-lethercat" is missing to the g++ command in
R2019a.
Previous to that, in R2018b I have as part of the line
> -Wall -W -Wwrite-strings -Winline -Wpointer-arith -Wcast-align
> -Wstrict-prototypes -Wnested-externs -Wno-long-long
> "/usr/local/share/etherlab/src/ecrt_support.c"
and in R2019a I have for the corresponding part just
> /mnt/FP500/usr/local/MATLAB/R2019a/rtw/c/etherlab/blocks/EtherCAT/ecrt_support.c.
The compiler resolves my symbolic link for saving space in my root
directory:
> $ ll /usr/local/MATLAB
> lrwxrwxrwx 1 root root 27 Jun 24 2017 /usr/local/MATLAB ->
> /mnt/FP500/usr/local/MATLAB/
So the file seems to be searched in the wrong place (matlab directory).
The full log is attached.
I am not sure if the missing "-lethercat" is related or a different
issue. When manually adding the "lethercat" to the command in the
terminal, the error remains.
The library can be found:
> $ ld -lethercat --verbose
> [...]
> found ld-linux-x86-64.so.2 at
> //lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
> ld: warning: cannot find entry symbol _start; not setting start
> address
I currently have no access on a different machine for testing, so I
don't want to waste your time with what could be a problem specific to
my computer setup unaware to me.
I am currently on Ubuntu 18.04 (upgraded from 16.04). If someone else
could report the same error or show that it works, it could already help
a lot.
Thanks already
On 06.04.20 17:19, Richard Hacker wrote:
> The file 'ecrt_support.c' in $MATLABDIR should be empty. It shouldn't
> even be there, but matlab complains that this file is missing, thus
> the 0Byte file.
>
> The generated Makefile from etherlab_hrt.tmf, however, ensures that
> the (non-empty) source file is found in $INSTALLDIR/src/ecrt_support.c
> before $MATLABDIR/rtw/c/etherlab/src. (It could probably better have
> been a link from $MATLABDIR to $INSTALLDIR)
>
> You seem to be applying patches to use matlab's external mode and your
> problem could be found there.
>
> Try
> make VERBOSE=1 clean all
> in the generated directory to find out where ecrt_support.c is found.
>
>
> On 2020-04-06 16:57, Moritz Schappler wrote:
>> Hello Richard,
>>
>> thanks for the quick reply. The output of `nm ecrt_support.o` showed a
>> potential reason: It is empty and the underlying file
>> rtw/blocks/EtherCAT/ecrt_support.c in the Matlab directory is also empty
>> (0 bytes).
>> It seems, as if the file should be used from
>> /usr/local/share/etherlab/src with 44kB, but Matlab takes the wrong
>> file. Matlab R2018b also has the empty file, but seems to not take it.
>> I installed Etherlab for both R2018b and R2019a in the same way, using
>> install.sh and setup_etherlab.m:
>> https://github.com/SchapplM/etherlab-examples/blob/master/SETUP_ETHERCAT.MD#entwpc
>>
>> Perhaps setting up the directories for linking the Simulink project has
>> changed in R2019a, or I messed up the Matlab path without having
>> noticed.
>> I re-tested on a different machine this time, though.
>>
>> This duplicate 0B-file was already introduced in hg-commit 1146
>> (2018-02-08).
>> When I overwrite the 0B file with the full version in the Matlab dir, I
>> get similar errors. Instead of
>>> new_2019a.o: In Funktion »new_2019a_step«:
>>> new_2019a.c:(.text+0x15): Warnung: undefinierter Verweis auf
>>> »ecs_receive«
>> I get something like
>>> ecrt_support.o: In Funktion »ecs_receive«:
>>> ecrt_support.c:(.text+0xa0b): Warnung: undefinierter Verweis auf
>>> »ecrt_domain_process«
>> The output of nm ecrt_support.o` now gives for R2018b and R2019a
>>> U calloc
>>> U clock_gettime
>>> [...]
>>> U ecrt_domain_data
>>> [...]
>> So the symbols are undefined ("U") also in the previous version R2018b.
>> Is it possible that the linker/compiler since R2019a is "stricter" and
>> now raises an error for the undefined references?
>>
>> As for manually running the g++ command: Building fails with the same
>> error in R2019a and R2018b.
>> Therefore the path configuration only seems to work from within Matlab
>> (R2018b).
>> Up to now, the only manual adaptation to making the build process work
>> was symbolically linking the shared libraries in /usr/local/lib/ with
>>> $ ll /usr/local/lib/
>>> lrwxrwxrwx 1 root root 44 Apr 6 14:54 libethercat.so ->
>>> /usr/local/share/etherlab/lib/libethercat.so*
>>> lrwxrwxrwx 1 root root 42 Apr 6 14:56 libpdserv.so ->
>>> /usr/local/share/etherlab/lib/libpdserv.so
>> I attached the detailed logs.
>>
>> In matlab-mex of the setup_etherlab.m I got the warnings
>>> Warning: You are using gcc version '7.5.0'. The version of gcc is not
>>> supported. The
>>> version currently supported with MEX is '6.3.x'. For a list of
>>> currently supported
>>> compilers see:
>>> https://www.mathworks.com/support/compilers/current_release.
>> which could also be related to handling of warnings/errors, but did not
>> pose a problem in R2018b for instance.
>>
>> Thanks already for looking into this.
>>
>> Viele Grüße
>> Moritz Schappler
>>
>>
>> On 06.04.20 13:18, Richard Hacker wrote:
>>> Hi Moritz
>>>
>>> I do not have Matlab > 2017 available to test, but I do not see a
>>> reason that ecs_*() symbols are not be found. They are defined in
>>> ecrt_support.c which is compiled and linked.
>>>
>>> Please go into the directory and supply me with the output of:
>>> cd /home/schappler/IMES/REPO/ethercat/etherlab-slaves/ixxa
>>> /new_2019a_etl_hrt
>>> nm ecrt_support.o
>>>
>>> Maybe try to compile the executable with (I just moved new_2019a.o
>>> forward):
>>> g++ -o ../new_2019a new_2019a_capi.o new_2019a.o new_2019a_data.o
>>> new_2019a_header.o rtGetInf.o rtGetNaN.o rt_nonfinite.o ecrt_support.o
>>> hrt_main.o -L/usr/local/lib -lm -lpdserv -ldl -lrt -pthread
>>>
>>> Mit freundlichem Gruß
>>>
>>> Richard Hacker
>>>
>>
--
__________________________________________________________
M. Sc. Moritz Schappler
Wissenschaftlicher Mitarbeiter und Gruppenleiter
Robotik & autonome Systeme
Gottfried Wilhelm Leibniz Universität Hannover
Institut für Mechatronische Systeme
An der Universität 1, Gebäude 8142 (Etage 1, Raum 108)
30823 Garbsen
Fon: +49 (0)511 762-4116
Fax: +49 (0)511 762-19976
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2018b_v2.log
Type: text/x-log
Size: 9823 bytes
Desc: not available
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20200406/08cadc28/attachment-0008.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2019a_v2.log
Type: text/x-log
Size: 32097 bytes
Desc: not available
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20200406/08cadc28/attachment-0009.bin>
More information about the Etherlab-users
mailing list