Re: [Xenomai-core] [PATCH v2] build system: Fix shared libs generation

Re: [Xenomai-core] [PATCH v2] build system: Fix shared libs generation

[Stefan Schaal]

I tried the modified configure.in from the xenomai-head.git tree, but  
still the *.so libraries are not generated. This is on a x86 running  
the xenomai-2.5.rc4 under kernel 2.6.29.5.

-Stefan



> Posted by Jan Kiszka on October 29, 2009 - 15:05:
> Philippe Gerum wrote:
>
> On Thu, 2009-10-29 at 12:33 +0100, Jan Kiszka wrote:
>
> This fixes a regression of dbbd33f50d: There must be no
> AC_DISABLE_SHARED without AS_ENABLE_SHARED for the cases where it  
> shall
> remain enabled.
>
>
> Makes sense. Will you queue this in your tree?
>
> Done, it's ready to be pulled.
>
> Jan
>
>
> Signed-off-by: Jan Kiszka <jan.kiszka@domain.hid>
> ---
>  configure.in |   12 ++++++++++--
>  1 files changed, 10 insertions(+), 2 deletions(-)
>
> v2: properly rebased against head
>
> diff --git a/configure.in b/configure.in
> index 40683fe..9cce885 100644
> --- a/configure.in
> +++ b/configure.in
> @@ -117,7 +117,6 @@ case "$build_for" in
>          XENO_LINUX_ARCH=nios2
>      XENO_LINUX_INSTALL_TARGET=install
>      CONFIG_XENO_DEFAULT_PERIOD=10000000
> -    AC_DISABLE_SHARED
>          ;;
>   *) echo ""
>     echo "*******************************************"
> @@ -128,9 +127,18 @@ case "$build_for" in
>  esac
>
>  AC_MSG_RESULT([$XENO_TARGET_ARCH])
> -AC_PROG_LIBTOOL
>  AM_CONDITIONAL(XENO_LINUX_ARCH_I386,[test $XENO_LINUX_ARCH = i386])
>
> +case "$XENO_TARGET_ARCH" in
> + nios2)
> +    AC_DISABLE_SHARED
> +    ;;
> + *)
> +    AC_ENABLE_SHARED
> +    ;;
> +esac
> +AC_PROG_LIBTOOL
> +
>  dnl
>  dnl Parse options
>  dnl
>
>
> -- 
> Siemens AG, Corporate Technology, CT SE 2
> Corporate Competence Center Embedded Linux
>
>
>

Re: [Xenomai-core] [PATCH v2] build system: Fix shared libs generation

[Stefan Schaal]

OK, I seemingly needed to get the entire xenomai-head, not just the  
configure.in . With the entire installation, the *.so compile again,  
and everything looks good.

-Stefan


On Oct 29, 2009, at 12:10, Stefan Schaal wrote:

> I tried the modified configure.in from the xenomai-head.git tree,  
> but still the *.so libraries are not generated. This is on a x86  
> running the xenomai-2.5.rc4 under kernel 2.6.29.5.
>
> -Stefan
>
>
>
>> Posted by Jan Kiszka on October 29, 2009 - 15:05:
>> Philippe Gerum wrote:
>>
>> On Thu, 2009-10-29 at 12:33 +0100, Jan Kiszka wrote:
>>
>> This fixes a regression of dbbd33f50d: There must be no
>> AC_DISABLE_SHARED without AS_ENABLE_SHARED for the cases where it  
>> shall
>> remain enabled.
>>
>>
>> Makes sense. Will you queue this in your tree?
>>
>> Done, it's ready to be pulled.
>>
>> Jan
>>
>>
>> Signed-off-by: Jan Kiszka <jan.kiszka@domain.hid>
>> ---
>> configure.in |   12 ++++++++++--
>> 1 files changed, 10 insertions(+), 2 deletions(-)
>>
>> v2: properly rebased against head
>>
>> diff --git a/configure.in b/configure.in
>> index 40683fe..9cce885 100644
>> --- a/configure.in
>> +++ b/configure.in
>> @@ -117,7 +117,6 @@ case "$build_for" in
>>         XENO_LINUX_ARCH=nios2
>>     XENO_LINUX_INSTALL_TARGET=install
>>     CONFIG_XENO_DEFAULT_PERIOD=10000000
>> -    AC_DISABLE_SHARED
>>         ;;
>>  *) echo ""
>>    echo "*******************************************"
>> @@ -128,9 +127,18 @@ case "$build_for" in
>> esac
>>
>> AC_MSG_RESULT([$XENO_TARGET_ARCH])
>> -AC_PROG_LIBTOOL
>> AM_CONDITIONAL(XENO_LINUX_ARCH_I386,[test $XENO_LINUX_ARCH = i386])
>>
>> +case "$XENO_TARGET_ARCH" in
>> + nios2)
>> +    AC_DISABLE_SHARED
>> +    ;;
>> + *)
>> +    AC_ENABLE_SHARED
>> +    ;;
>> +esac
>> +AC_PROG_LIBTOOL
>> +
>> dnl
>> dnl Parse options
>> dnl
>>
>>
>> -- 
>> Siemens AG, Corporate Technology, CT SE 2
>> Corporate Competence Center Embedded Linux
>>
>>
>>

[Xenomai-core] lots of mode switches in xenomai-head tree?

[Stefan Schaal]

Hi,

   I am working with the latest xenomai-head tree (we need analogy for  
our NI board ...). Under Xenomai 2.4.8 our code did not have any mode  
switches. Using the xenomai-head, we get a lot of mode switches. Using  
he backtrace_symbols_fd, we get print-outs like:


xsimulation[0x808553b]
[0xffffe400]
/usr/xenomai/lib/librtdk.so.0(assert_nrt+0x85)[0xb7fa2ea5]
/usr/xenomai/lib/librtdk.so.0(__wrap_clock_gettime+0x17)[0xb7fa2ef7]
xsimulation[0x807cd16]
xsimulation[0x807d7fb]
/usr/xenomai/lib/libnative.so.3[0xb7fab689]
/lib/tls/i686/cmov/libpthread.so.0[0xb7f824ff]
/lib/tls/i686/cmov/libc.so.6(clone+0x5e)[0xb7e8f49e]

Which indicates that the wrapper for clock_gettime causes this  
trouble, which is also confirmed by commenting clock_gettime out, and  
the  mode switches disappear.

  Maybe something that needs fixing?

Best wishes,

-Stefan

Re: [Xenomai-core] lots of mode switches in xenomai-head tree?

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1335 bytes --]

Stefan Schaal wrote:
> Hi,
> 
>    I am working with the latest xenomai-head tree (we need analogy for  
> our NI board ...). Under Xenomai 2.4.8 our code did not have any mode  
> switches. Using the xenomai-head, we get a lot of mode switches. Using  
> he backtrace_symbols_fd, we get print-outs like:
> 
> 
> xsimulation[0x808553b]
> [0xffffe400]
> /usr/xenomai/lib/librtdk.so.0(assert_nrt+0x85)[0xb7fa2ea5]
> /usr/xenomai/lib/librtdk.so.0(__wrap_clock_gettime+0x17)[0xb7fa2ef7]
> xsimulation[0x807cd16]
> xsimulation[0x807d7fb]
> /usr/xenomai/lib/libnative.so.3[0xb7fab689]
> /lib/tls/i686/cmov/libpthread.so.0[0xb7f824ff]
> /lib/tls/i686/cmov/libc.so.6(clone+0x5e)[0xb7e8f49e]
> 
> Which indicates that the wrapper for clock_gettime causes this  
> trouble, which is also confirmed by commenting clock_gettime out, and  
> the  mode switches disappear.
> 
>   Maybe something that needs fixing?

Do you wrap & link against the POSIX library, ie. use that skin as well?
If not, your code is actually using clock_gettime incorrectly as it then
falls back to the Linux service which can trigger syscalls (or even
deadlocks when the TSC is used).

If you do use libpthread_rt, then my next question is if your work is
based on today's git head or some older version not including 4a2cb7b817.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

Re: [Xenomai-core] lots of mode switches in xenomai-head tree?

[Stefan Schaal]

Hi Jan,

   we updated the git on Oct. 29 (3 days ago). We do use the posix  
skin, i.e., we use the xeno-config --posix-ldflags. This worked all  
fine without mode switches under Xenomai 2.4.8. My git does include  
4a2cb7b817. I will try to reproduce the error in a test program.

-Stefan


On Nov 1, 2009, at 23:43, Jan Kiszka wrote:

> Stefan Schaal wrote:
>> Hi,
>>
>>   I am working with the latest xenomai-head tree (we need analogy for
>> our NI board ...). Under Xenomai 2.4.8 our code did not have any mode
>> switches. Using the xenomai-head, we get a lot of mode switches.  
>> Using
>> he backtrace_symbols_fd, we get print-outs like:
>>
>>
>> xsimulation[0x808553b]
>> [0xffffe400]
>> /usr/xenomai/lib/librtdk.so.0(assert_nrt+0x85)[0xb7fa2ea5]
>> /usr/xenomai/lib/librtdk.so.0(__wrap_clock_gettime+0x17)[0xb7fa2ef7]
>> xsimulation[0x807cd16]
>> xsimulation[0x807d7fb]
>> /usr/xenomai/lib/libnative.so.3[0xb7fab689]
>> /lib/tls/i686/cmov/libpthread.so.0[0xb7f824ff]
>> /lib/tls/i686/cmov/libc.so.6(clone+0x5e)[0xb7e8f49e]
>>
>> Which indicates that the wrapper for clock_gettime causes this
>> trouble, which is also confirmed by commenting clock_gettime out, and
>> the  mode switches disappear.
>>
>>  Maybe something that needs fixing?
>
> Do you wrap & link against the POSIX library, ie. use that skin as  
> well?
> If not, your code is actually using clock_gettime incorrectly as it  
> then
> falls back to the Linux service which can trigger syscalls (or even
> deadlocks when the TSC is used).
>
> If you do use libpthread_rt, then my next question is if your work is
> based on today's git head or some older version not including  
> 4a2cb7b817.
>
> Jan
>

Re: [Xenomai-core] lots of mode switches in xenomai-head tree?

[Stefan Schaal]

Hi Jan,

   you pointer to the 4a2cb7b817 help! We had  -lrtdk  before - 
lpthread -lpthread_rt in our compile statement. Just in 2.4.8, this  
seems to make no difference.

-Stefan


On Nov 2, 2009, at 10:42, Stefan Schaal wrote:

> Hi Jan,
>
>  we updated the git on Oct. 29 (3 days ago). We do use the posix  
> skin, i.e., we use the xeno-config --posix-ldflags. This worked all  
> fine without mode switches under Xenomai 2.4.8. My git does include  
> 4a2cb7b817. I will try to reproduce the error in a test program.
>
> -Stefan
>
>
> On Nov 1, 2009, at 23:43, Jan Kiszka wrote:
>
>> Stefan Schaal wrote:
>>> Hi,
>>>
>>>  I am working with the latest xenomai-head tree (we need analogy for
>>> our NI board ...). Under Xenomai 2.4.8 our code did not have any  
>>> mode
>>> switches. Using the xenomai-head, we get a lot of mode switches.  
>>> Using
>>> he backtrace_symbols_fd, we get print-outs like:
>>>
>>>
>>> xsimulation[0x808553b]
>>> [0xffffe400]
>>> /usr/xenomai/lib/librtdk.so.0(assert_nrt+0x85)[0xb7fa2ea5]
>>> /usr/xenomai/lib/librtdk.so.0(__wrap_clock_gettime+0x17)[0xb7fa2ef7]
>>> xsimulation[0x807cd16]
>>> xsimulation[0x807d7fb]
>>> /usr/xenomai/lib/libnative.so.3[0xb7fab689]
>>> /lib/tls/i686/cmov/libpthread.so.0[0xb7f824ff]
>>> /lib/tls/i686/cmov/libc.so.6(clone+0x5e)[0xb7e8f49e]
>>>
>>> Which indicates that the wrapper for clock_gettime causes this
>>> trouble, which is also confirmed by commenting clock_gettime out,  
>>> and
>>> the  mode switches disappear.
>>>
>>> Maybe something that needs fixing?
>>
>> Do you wrap & link against the POSIX library, ie. use that skin as  
>> well?
>> If not, your code is actually using clock_gettime incorrectly as it  
>> then
>> falls back to the Linux service which can trigger syscalls (or even
>> deadlocks when the TSC is used).
>>
>> If you do use libpthread_rt, then my next question is if your work is
>> based on today's git head or some older version not including  
>> 4a2cb7b817.
>>
>> Jan
>>
>
>

Re: [Xenomai-core] lots of mode switches in xenomai-head tree?

[Gilles Chanteperdrix]

Stefan Schaal wrote:
> Hi Jan,
> 
>    you pointer to the 4a2cb7b817 help! We had  -lrtdk  before - 
> lpthread -lpthread_rt in our compile statement. Just in 2.4.8, this  
> seems to make no difference.

Do you use the wrap-link.sh script, or is this order change unrelated?

-- 
					    Gilles.