[etherlab-users] Limitations on Matlab Version - R2018b vs R2019a

[Richard Hacker]

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
>>
>