Re: undefined symbol in tests

[Antoine Hoarau via Xenomai]

Still having this "undefined reference" issue on 3.1. Is there any news on
that ?

Le mer. 19 févr. 2020 à 13:13, Jan Kiszka  a écrit :

> On 19.02.20 13:11, Antoine Hoarau wrote:
> > Dohell does no seem to be included either. Is that normal ?
> >
>
> It is, see /usr/lib/xenomai/testsuite/dohell.
>
> Jan
>
> > Le mer. 19 févr. 2020 à 12:35, Jan Kiszka  > <mailto:jan.kis...@siemens.com>> a écrit :
> >
> > On 19.02.20 09:54, Jan Kiszka via Xenomai wrote:
> >  > On 18.02.20 18:45, Antoine Hoarau via Xenomai wrote:
> >  >> Le mar. 18 févr. 2020 à 12:12, Gylstorff Quirin <
> >  >> quirin.gylsto...@siemens.com
> > <mailto:quirin.gylsto...@siemens.com>> a écrit :
> >  >>
> >  >>> Hi Antoine,
> >  >>>
> >  >>> On 2/18/20 12:04 AM, Antoine Hoarau via Xenomai wrote:
> >  >>>> # ldd /usr/lib/xenomai/testsuite/libalchemy-test.so
> >  >>>>   linux-vdso.so.1 (0x7fff1f944000)
> >  >>>>   libcobalt.so.2 => /usr/lib/libcobalt.so.2
> >  >>>> (0x7f2a40bc9000)
> >  >>>>   libalchemy.so.0 => /usr/lib/libalchemy.so.0
> >  >>>> (0x7f2a409b1000)
> >  >>>>   libcopperplate.so.0 => /usr/lib/libcopperplate.so.0
> >  >>>> (0x7f2a407a3000)
> >  >>>>   libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
> >  >>> (0x7f2a403b2000)
> >  >>>>   librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1
> >  >>> (0x7f2a401aa000)
> >  >>>>   libpthread.so.0 =>
> /lib/x86_64-linux-gnu/libpthread.so.0
> >  >>>> (0x7f2a3ff8b000)
> >  >>>>   /lib64/ld-linux-x86-64.so.2 (0x7f2a40ff4000)
> >  >>>>
> >  >>>>
> >  >>>> For info I added --enable-dlopen-libs
> >  >>>> As in
> > https://xenomai.org/pipermail/xenomai/2020-January/042306.html
> >  >>>>
> >  >>>> Le lun. 17 févr. 2020 à 17:51, Jan Kiszka
> > mailto:jan.kis...@siemens.com>> a
> >  >>> écrit :
> >  >>>>
> >  >>>>> On 14.02.20 15:15, Antoine Hoarau wrote:
> >  >>>>>> I just built the debians:
> >  >>>>>> debchange -v 3.1 Release 3.1
> >  >>>>>> debuild -uc -us
> >  >>>>>>
> >  >>>
> >  >>> What is the Debian version and CPU architecture of your build
> > system?A
> >  >>
> >  >>
> >  >> A very standard Ubuntu 18.04 x64.
> >  >> Debuild version 2.17.12ubuntu1.1
> >  >>
> >  >
> >  > Ah! That is surely untested as no one here is using Ubuntu
> anymore.
> >  > Will check if it's a generic or a Ubuntu-exposed issue.
> >  >
> >
> > I'm starting to understand the issue. It's likely related to
> > optimizations of library dependency done differently by the Ubuntu
> > toolchain than that of Debian 10. I think we can avoid that by adding
> > all actual deps to our libs. Playing with it...
> >
> > Jan
> >
> > --
> > Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> > Corporate Competence Center Embedded Linux
> >
>
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux
>

Re: Xenomai Community Call Minutes - April 7, 2021

[Antoine Hoarau via Xenomai]

I ran into the same issue. Using default config too. Had to enable EFI
manually.

Le jeu. 8 avr. 2021 à 10:28, Jan Kiszka via Xenomai  a
écrit :

> On 08.04.21 10:19, Chen, Hongzhan via Xenomai wrote:
> >> From: Xenomai  On Behalf Of Wang, Rick Y
> via Xenomai
> >> Sent: Thursday, April 8, 2021 8:52 AM
> >> To: xenomai@xenomai.org
> >> Subject: Xenomai Community Call Minutes - April 7, 2021
> >>
> >> Attendees:
> >>
> >> Jan Kiszka, Florian Bezdeka, Florent Pirou, Hongzhan Chen,
> >> Dao Zhang, Jianbo Cao, Yanfeng Pu, Rick Wang
> >>
> >>
> >> *Community update
> >>
> >> - No code change in the past two weeks
> >> - Greg is debugging jitter issue on ARM.
> >> - Siemens is testing WIP-Dovetail branch internally. Some issues were
> >> reported related to clock source or gdb crash.
> >> - Jan will log the issues to gitlab Xenomai hacker space:
> >> https://gitlab.com/Xenomai/xenomai-hacker-space/-/issues
> >> - For Xenomai 3.2, there are some submitted patches pending on Jan's
> review
> >> and merge. Also some patches in Philippe's private tree are pending on
> >> submission.
> >> - Florian and Song are working on Y2038 issue on Philippe's tree. It
> depends
> >> on some Dovetail codes to be merged first.
> >> - Hongzhan is working on latmus GPIO porting. 5.10 Dovetail-based
> Xenomai
> >> and EVL can't boot up on his dev board yet. 5.9 kernel can boot on the
> >
> > After further debug , when failure happen, actually system is wrong to
> use pit instead of
> > LAPIC as clock event device because pit can not work with dovetail.
> After check log , found
> > that there is abnormal info related to APIC reported "[2.812126]
> APIC: ACPI MADT or MP tables are not detected"
> > It mentioned ACPI.  So I traced ACPI related log suggested by Jan and
> Florian and found that there is
> > ACPI related error reported earlier in log like " [0.013416] ACPI
> BIOS Error (bug): A valid RSDP was not found (20200925/tbxfroot-210)".
> > I googled this error but all the solution related to it  can not fix the
> issue for example enabling ACPI in BIOS.
> > And then I captured kernel log for 5.9 and compare them with 5.10 and
> finally found that there is log info related to ACPI missing with my 5.10
> image like
> > " [0.00] efi: ACPI 2.0=0x8c3ee000 ACPI=0x8c3ee000
> TPMFinalLog=0x8c4ad000 SMBIOS=0x8c9ca000 SMBIOS 3.0=0x8c9c9000
> MEMATTR=0x88059418"
> > After check kernel config, I found  that my 5.10 config actually have
> not enabled CONFIG_EFI. After enable it, evl successfully boot up on
> > my Rock PI X board now.
> >
> > Thanks for Jan and Florian's suggestions.
> >
>
> Great to hear it works now!
>
> Yeah, CONFIG_EFI=y is part of x86_64_defconfig - that's why I suggested
> to retry starting from there.
>
> Jan
>
> --
> Siemens AG, T RDA IOT
> Corporate Competence Center Embedded Linux
>
>

Updating the r8169 driver

[Antoine Hoarau via Xenomai]

Hi all,
I have a setup where I need an updated r8169.
I started updating the (very) old one provided with rtnet with the cards
from linux 2.6 (the code is quite similar). Attached the first draft,
(highly) experimental.
In the end I need an even more up to date version, so I'll start from the
4.19 when I can, but the code is completely different. I'm really wondering
why this driver would need to be completely re-written at every kernel
version, but anyways.
I see the e1000e just got updated, anyone working on updating this
particular driver ?
Thanks a bunch,
Antoine
-- next part --
A non-text attachment was scrubbed...
Name: r8169_2.6.c
Type: text/x-csrc
Size: 79209 bytes
Desc: not available
URL: 

Re: RTnet drivers is out of date

[Antoine Hoarau via Xenomai]

The updated r8169 would be great now that we have e1000e updated.

Le mer. 23 oct. 2019 à 20:00, G.Strobbe via Xenomai  a
écrit :

>
>
> - On Oct 22, 2019, at 3:26 AM, xenomai xenomai@xenomai.org wrote:
>
> > Will someone update RTnet NICs drivers?
>
> Which RTnet driver do you need?
>
>

RTnet from userspace

[Antoine Hoarau via Xenomai]

Hi,
I'm trying to run rtnet executables (ex: rtifconfig) from user-space.
User is in the xenomai group and can run xenomai applications without
sudo/being root.
rtifconfig results in:  ioctl: Operation not permitted
What would be the best/most linux way to only authorize the xenomai group
to access those functions ?
Thanks !

undefined symbol in tests

[Antoine Hoarau via Xenomai]

If I run xeno tests I get :
symbol lookup error: /usr/lib/libalchemy.so.0: undefined symbol: __real_free
/usr/lib/xenomai/testsuite/smokey: test dlopen failed: Unknown error -127
child 1458 returned: exited with status 1

Tests on 3.1 release.

Re: undefined symbol in tests

[Antoine Hoarau via Xenomai]

I generated the debian then installed them in the "xenomai computer"
Maybe something is wrong in the debian script.
The computer is an IPC127e.

Le ven. 14 févr. 2020 à 10:53, Jan Kiszka  a écrit :

> On 14.02.20 10:48, Antoine Hoarau via Xenomai wrote:
> > If I run xeno tests I get :
> > symbol lookup error: /usr/lib/libalchemy.so.0: undefined symbol:
> __real_free
> > /usr/lib/xenomai/testsuite/smokey: test dlopen failed: Unknown error -127
> > child 1458 returned: exited with status 1
> >
> > Tests on 3.1 release.
> >
>
> As this ran through our testlab here, there must be some local deviation
> in your build. Can you provide more details on how and for what you built?
>
> Jan
>
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux
>

Re: undefined symbol in tests

[Antoine Hoarau via Xenomai]

I just built the debians:
debchange -v 3.1 Release 3.1
debuild -uc -us


Le ven. 14 févr. 2020 à 14:52, Jan Kiszka  a écrit :

> On 14.02.20 14:46, Antoine Hoarau wrote:
> > I generated the debian then installed them in the "xenomai computer"
> > Maybe something is wrong in the debian script.
> > The computer is an IPC127e.
>
> We are testing on 227e, which is very close, without that issue. Were
> you using xenomai-images for the generation or did you just build the
> debian packages?
>
> Jan
>
> >
> > Le ven. 14 févr. 2020 à 10:53, Jan Kiszka  > <mailto:jan.kis...@siemens.com>> a écrit :
> >
> > On 14.02.20 10:48, Antoine Hoarau via Xenomai wrote:
> >  > If I run xeno tests I get :
> >  > symbol lookup error: /usr/lib/libalchemy.so.0: undefined symbol:
> > __real_free
> >  > /usr/lib/xenomai/testsuite/smokey: test dlopen failed: Unknown
> > error -127
> >  > child 1458 returned: exited with status 1
> >  >
> >  > Tests on 3.1 release.
> >  >
> >
> > As this ran through our testlab here, there must be some local
> > deviation
> > in your build. Can you provide more details on how and for what you
> > built?
> >
> > Jan
> >
> > --
> > Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> > Corporate Competence Center Embedded Linux
> >
>
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux
>

Re: undefined symbol in tests

[Antoine Hoarau via Xenomai]

# ldd /usr/lib/xenomai/testsuite/libalchemy-test.so
linux-vdso.so.1 (0x7fff1f944000)
libcobalt.so.2 => /usr/lib/libcobalt.so.2 (0x7f2a40bc9000)
libalchemy.so.0 => /usr/lib/libalchemy.so.0 (0x7f2a409b1000)
libcopperplate.so.0 => /usr/lib/libcopperplate.so.0
(0x7f2a407a3000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f2a403b2000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f2a401aa000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x7f2a3ff8b000)
/lib64/ld-linux-x86-64.so.2 (0x7f2a40ff4000)


For info I added --enable-dlopen-libs
As in https://xenomai.org/pipermail/xenomai/2020-January/042306.html

Le lun. 17 févr. 2020 à 17:51, Jan Kiszka  a écrit :

> On 14.02.20 15:15, Antoine Hoarau wrote:
> > I just built the debians:
> > debchange -v 3.1 Release 3.1
> > debuild -uc -us
> >
>
> I've done that (well, minus debchange) on a Debian 10, installed a
> Xenomai kernel, and ran xeno-test - no problem. I would need this info:
>
> ldd /usr/lib/xenomai/testsuite/libalchemy-test.so
>
> Jan
>
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux
>

Re: undefined symbol in tests

[Antoine Hoarau via Xenomai]

Le mar. 18 févr. 2020 à 12:12, Gylstorff Quirin <
quirin.gylsto...@siemens.com> a écrit :

> Hi Antoine,
>
> On 2/18/20 12:04 AM, Antoine Hoarau via Xenomai wrote:
> > # ldd /usr/lib/xenomai/testsuite/libalchemy-test.so
> >  linux-vdso.so.1 (0x7fff1f944000)
> >  libcobalt.so.2 => /usr/lib/libcobalt.so.2 (0x7f2a40bc9000)
> >  libalchemy.so.0 => /usr/lib/libalchemy.so.0 (0x7f2a409b1000)
> >  libcopperplate.so.0 => /usr/lib/libcopperplate.so.0
> > (0x7f2a407a3000)
> >  libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
> (0x7f2a403b2000)
> >  librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1
> (0x7f2a401aa000)
> >  libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
> > (0x7f2a3ff8b000)
> >  /lib64/ld-linux-x86-64.so.2 (0x7f2a40ff4000)
> >
> >
> > For info I added --enable-dlopen-libs
> > As in https://xenomai.org/pipermail/xenomai/2020-January/042306.html
> >
> > Le lun. 17 févr. 2020 à 17:51, Jan Kiszka  a
> écrit :
> >
> >> On 14.02.20 15:15, Antoine Hoarau wrote:
> >>> I just built the debians:
> >>> debchange -v 3.1 Release 3.1
> >>> debuild -uc -us
> >>>
>
> What is the Debian version and CPU architecture of your build system?A


A very standard Ubuntu 18.04 x64.
Debuild version 2.17.12ubuntu1.1

>
>
> >>
> >> I've done that (well, minus debchange) on a Debian 10, installed a
> >> Xenomai kernel, and ran xeno-test - no problem. I would need this info:
> >>
> >> ldd /usr/lib/xenomai/testsuite/libalchemy-test.so
> >>
> >> Jan
> >>
> >> --
> >> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> >> Corporate Competence Center Embedded Linux
> >>Quirin
>
> Siemens AG
> Corporate Technology
> CT RDA IOT SES-DE
>
>

Re: undefined symbol in tests

[Antoine Hoarau via Xenomai]

Dohell does no seem to be included either. Is that normal ?

Le mer. 19 févr. 2020 à 12:35, Jan Kiszka  a écrit :

> On 19.02.20 09:54, Jan Kiszka via Xenomai wrote:
> > On 18.02.20 18:45, Antoine Hoarau via Xenomai wrote:
> >> Le mar. 18 févr. 2020 à 12:12, Gylstorff Quirin <
> >> quirin.gylsto...@siemens.com> a écrit :
> >>
> >>> Hi Antoine,
> >>>
> >>> On 2/18/20 12:04 AM, Antoine Hoarau via Xenomai wrote:
> >>>> # ldd /usr/lib/xenomai/testsuite/libalchemy-test.so
> >>>>   linux-vdso.so.1 (0x7fff1f944000)
> >>>>   libcobalt.so.2 => /usr/lib/libcobalt.so.2
> >>>> (0x7f2a40bc9000)
> >>>>   libalchemy.so.0 => /usr/lib/libalchemy.so.0
> >>>> (0x7f2a409b1000)
> >>>>   libcopperplate.so.0 => /usr/lib/libcopperplate.so.0
> >>>> (0x7f2a407a3000)
> >>>>   libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
> >>> (0x7f2a403b2000)
> >>>>   librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1
> >>> (0x7f2a401aa000)
> >>>>   libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
> >>>> (0x7f2a3ff8b000)
> >>>>   /lib64/ld-linux-x86-64.so.2 (0x7f2a40ff4000)
> >>>>
> >>>>
> >>>> For info I added --enable-dlopen-libs
> >>>> As in https://xenomai.org/pipermail/xenomai/2020-January/042306.html
> >>>>
> >>>> Le lun. 17 févr. 2020 à 17:51, Jan Kiszka  a
> >>> écrit :
> >>>>
> >>>>> On 14.02.20 15:15, Antoine Hoarau wrote:
> >>>>>> I just built the debians:
> >>>>>> debchange -v 3.1 Release 3.1
> >>>>>> debuild -uc -us
> >>>>>>
> >>>
> >>> What is the Debian version and CPU architecture of your build system?A
> >>
> >>
> >> A very standard Ubuntu 18.04 x64.
> >> Debuild version 2.17.12ubuntu1.1
> >>
> >
> > Ah! That is surely untested as no one here is using Ubuntu anymore.
> > Will check if it's a generic or a Ubuntu-exposed issue.
> >
>
> I'm starting to understand the issue. It's likely related to
> optimizations of library dependency done differently by the Ubuntu
> toolchain than that of Debian 10. I think we can avoid that by adding
> all actual deps to our libs. Playing with it...
>
> Jan
>
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux
>

Re: [PATCH] libs: Add linking dependencies to libraries

[Antoine Hoarau via Xenomai]

Same error when reverting the patch !
: symbol lookup error: /usr/lib/libalchemy.so.0: undefined symbol:
__real_free
 /usr/lib/xenomai/testsuite/smokey: test dlopen failed: Unknown error -127
child 8610 returned: exited with status 1

Le mar. 25 févr. 2020 à 16:37, Henning Schild 
a écrit :

> On Tue, 25 Feb 2020 15:33:45 +0100
> Jan Kiszka  wrote:
>
> > [adding the list]
> >
> > On 25.02.20 15:32, Jan Kiszka wrote:
> > > On 25.02.20 15:30, Henning Schild wrote:
> > >> I guess that is related to lds --(no-)as-needed which is different
> > >> in the ubuntu toolchain. Back when i looked into it Ubuntu managed
> > >> to patch the default behaviour but forgot to patch the man-pages ;)
> > >>
> > >> See
> > >>
> https://gitlab.denx.de/Xenomai/xenomai/commit/83dea2ad712ee2d2137942c7ab9891da7d4ef841
> > >>
> > >>
> > >> Maybe this can actually be reverted after the proposed fix.
> > >
> > > If someone can validate that, I'm happy to do so...
>
> That is why i pulled in Antoine again. He has a ubuntu setup and can
> probably check whether applying your fix works, and reverting the other
> one still works.
>
> Henning
>
> > > Jan
> > >
> > >>
> > >> Henning
> > >>
> > >> On Wed, 19 Feb 2020 13:31:29 +0100
> > >> Jan Kiszka via Xenomai  wrote:
> > >>
> > >>> From: Jan Kiszka 
> > >>>
> > >>> This ensures that no optimization will drop dependencies of our
> > >>> shared objects, preventing to load them via dlopen without
> > >>> explicitly loading those dropped dependencies first. See also
> > >>> https://xenomai.org/pipermail/xenomai/2020-February/042449.html
> > >>>
> > >>> As trank now explicitly depends on alchemy, reorder the build to
> > >>> ensure that the latter is available before the former is built
> > >>> (analogy is only moved for consistency reasons).
> > >>>
> > >>> Reported-by: Antoine Hoarau 
> > >>> Signed-off-by: Jan Kiszka 
> > >>> ---
> > >>>   lib/Makefile.am | 11 +++
> > >>>   lib/alchemy/Makefile.am |  4 
> > >>>   lib/analogy/Makefile.am |  2 ++
> > >>>   lib/psos/Makefile.am|  4 
> > >>>   lib/trank/Makefile.am   |  4 
> > >>>   lib/vxworks/Makefile.am |  4 
> > >>>   6 files changed, 25 insertions(+), 4 deletions(-)
> > >>>
> > >>> diff --git a/lib/Makefile.am b/lib/Makefile.am
> > >>> index c927a9bd85..e909030564 100644
> > >>> --- a/lib/Makefile.am
> > >>> +++ b/lib/Makefile.am
> > >>> @@ -1,10 +1,7 @@
> > >>>   SUBDIRS = boilerplate
> > >>>   if XENO_COBALT
> > >>> -SUBDIRS +=\
> > >>> -cobalt\
> > >>> -analogy\
> > >>> -trank
> > >>> +SUBDIRS += cobalt
> > >>>   else
> > >>>   SUBDIRS += mercury
> > >>>   endif
> > >>> @@ -16,6 +13,12 @@ SUBDIRS +=\
> > >>>   vxworks\
> > >>>   psos
> > >>> +if XENO_COBALT
> > >>> +SUBDIRS += \
> > >>> +analogy\
> > >>> +trank
> > >>> +endif
> > >>> +
> > >>>   DIST_SUBDIRS = \
> > >>>   alchemy\
> > >>>   analogy\
> > >>> diff --git a/lib/alchemy/Makefile.am b/lib/alchemy/Makefile.am
> > >>> index 5362695ed2..f97bd69bf8 100644
> > >>> --- a/lib/alchemy/Makefile.am
> > >>> +++ b/lib/alchemy/Makefile.am
> > >>> @@ -2,6 +2,10 @@ lib_LTLIBRARIES = libalchemy.la
> > >>>   libalchemy_la_LDFLAGS = @XENO_LIB_LDFLAGS@ -version-info 0:0:0
> > >>> +libalchemy_la_LIBADD =
> > >>> \
> > >>> +@XENO_CORE_LDADD@\
> > >>> +$(top_builddir)/lib/copperplate/libcopperplate.la
> > >>> +
> > >>>   libalchemy_la_SOURCES =\
> > >>>   init.c\
> > >>>   internal.c\
> > >>> diff --git a/lib/analogy/Makefile.am b/lib/analogy/Makefile.am
> > >>> index e53d8a11ab..4c6f0de013 100644
> > >>> --- a/lib/analogy/Makefile.am
> > >>> +++ b/lib/analogy/Makefile.am
> > >>> @@ -2,6 +2,8 @@ lib_LTLIBRARIES = libanalogy.la
> > >>>   libanalogy_la_LDFLAGS = @XENO_LIB_LDFLAGS@ -version-info 1:0:0
> > >>> -lm +libanalogy_la_LIBADD = @XENO_CORE_LDADD@
> > >>> +
> > >>>   libanalogy_la_SOURCES =\
> > >>>   async.c\
> > >>>   descriptor.c\
> > >>> diff --git a/lib/psos/Makefile.am b/lib/psos/Makefile.am
> > >>> index 4eb7ad84ce..6fe50881cc 100644
> > >>> --- a/lib/psos/Makefile.am
> > >>> +++ b/lib/psos/Makefile.am
> > >>> @@ -2,6 +2,10 @@ lib_LTLIBRARIES = libpsos.la
> > >>>   libpsos_la_LDFLAGS = @XENO_LIB_LDFLAGS@ -version-info 0:0:0
> > >>> +libpsos_la_LIBADD =\
> > >>> +@XENO_CORE_LDADD@\
> > >>> +$(top_builddir)/lib/copperplate/libcopperplate.la
> > >>> +
> > >>>   libpsos_la_SOURCES =\
> > >>>   init.c\
> > >>>   internal.h\
> > >>> diff --git a/lib/trank/Makefile.am b/lib/trank/Makefile.am
> > >>> index 816a1a4047..ee353c6f20 100644
> > >>> --- a/lib/trank/Makefile.am
> > >>> +++ b/lib/trank/Makefile.am
> > >>> @@ -3,6 +3,10 @@ lib_LTLIBRARIES = libtrank.la
> > >>>   libtrank_la_LDFLAGS = @XENO_LIB_LDFLAGS@ -version-info 0:0:0
> > >>> +libtrank_la_LIBADD =\
> > >>> +@XENO_CO

Re: [I-PIPE] ipipe-core-4.19.114-cip24-x86-12 released

[Antoine Hoarau via Xenomai]

This is great ! Could you elaborate on the -cip meaning ?
It is still not clear to me. Thanks !

Le jeu. 16 avr. 2020 à 10:54, xenomai--- via Xenomai 
a écrit :

> Download URL:
> https://xenomai.org/downloads/ipipe/v4.x/x86/ipipe-core-4.19.114-cip24-x86-12.patch
>
> Repository: https://git.xenomai.org/ipipe-x86
> Release tag: ipipe-core-4.19.114-cip24-x86-12
>
>