Skip to contentSkip to conversation

Fix build for relative invocations of configure

PATCH Applied Jan Kiszka 4 participants 4 messages Feb 7, 2012 – Mar 1, 2012

lore
Share & tools
lore

Jan Kiszka

author
#0 lore raw

PATCH 1/1 Fix build for relative invocations of configure

This fixes build setups like '../configure'.

Signed-off-by Jan Kiszka <[email protected]>
---
 configure.in |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
configure.in +1 -1
index c0a7d17..0bdced8 100644
@@ -547,7 +547,7 @@ LD_FILE_OPTION=$ac_cv_ld_file_option
 AC_SUBST(LD_FILE_OPTION)
 
 if test x$rtcore_type = xcobalt; then
-   XENO_USER_CFLAGS="-I$srcdir/include/cobalt $XENO_USER_CFLAGS"
+   XENO_USER_CFLAGS="-I`cd $srcdir && pwd`/include/cobalt $XENO_USER_CFLAGS"
    if [[ $ac_cv_ld_file_option = yes ]]; then
 	XENO_POSIX_WRAPPERS="-Wl,@`cd $srcdir && pwd`/lib/cobalt/posix.wrappers"
    else
Signature · 1 line
1.7.3.4
Applied
#1 lore raw
Quoted 2 lines · Jan Kiszka

This fixes build setups like '../configure'.

Merged, thanks.

Quoted 18 lines
Signed-off-by Jan Kiszka<[email protected]>
---
  configure.in |    2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)
configure.in +1 -1
index c0a7d17..0bdced8 100644
@@ -547,7 +547,7 @@ LD_FILE_OPTION=$ac_cv_ld_file_option
  AC_SUBST(LD_FILE_OPTION)
 
  if test x$rtcore_type = xcobalt; then
-   XENO_USER_CFLAGS="-I$srcdir/include/cobalt $XENO_USER_CFLAGS"
+   XENO_USER_CFLAGS="-I`cd $srcdir&&  pwd`/include/cobalt $XENO_USER_CFLAGS"
     if [[ $ac_cv_ld_file_option = yes ]]; then
  	XENO_POSIX_WRAPPERS="-Wl,@`cd $srcdir&&  pwd`/lib/cobalt/posix.wrappers"
     else
Signature · 1 line
Philippe.
#2 lore raw

[Xenomai-core] high duration of __ipipe_handle_irq

Hi,

i have this problem with xenomai ( 2.5.6 - arm freescale imx25 ):

I have a xenomai application that uses more rt_tasks, and i have a strange behaviour.
When i run my application the period of *__ipipe_handle_irq* is very long ( ~3ms in some cases ) in the moment that come the *__ipipe_mach_timerint *interrupt and so the other interrupts are very late.

Do you know something about this ?

Thanks for all

Signature · 33 lines
+------------------------------------------------------------------------------------------------+
							
Roberto Bielli
Sviluppo Software					
Axel S.r.l.					
							
Via Del Cannino, 3 				
21020 Crosio Della Valle			
Varese - Italy					
							
Telefono: +39 0332 949600			
Fax:      +39 0332 969315			
							
E-mail:   [email protected]	
Web Site: www.axelsw.it

+------------------------------------------------------------------------------------------------+

Si precisa che le informazioni contenute in questo messaggio sono riservate e ad uso esclusivo del destinatario.
Qualora il messaggio in parola Le fosse pervenuto per errore, La preghiamo di eliminarlo senza copiarlo e di non inoltrarlo a terzi,
dandocene gentilmente comunicazione. Grazie.
Informativa sul trattamento dei dati personali (D. Lgs. 196/2003).
I dati utilizzati per la spedizione del presente messaggio sono utilizzati da Axel S.r.l., titolare del trattamento,
per l'invio delle comunicazioni dei diversi settori aziendali, non essendo autorizzata la divulgazione a terzi.
Potrete rivolgere alla seguente mail richieste di verifica, rettifica o cancellazione dei Vostri dati: [email protected]

This e-mail and any attachments is confidential and may contain privileged information
intended for the addressee(s) only. Dissemination, copying, printing or use by anybody
else is unauthorised. If you are not the intended recipient,
please delete this message and any attachments and advise the sender
by return e-mail.Thank you.  			
							
+------------------------------------------------------------------------------------------------+
#3 lore raw

Re: [Xenomai-core] high duration of __ipipe_handle_irq

Quoted 4 lines · Roberto Bielli

Hi,

i have this problem with xenomai ( 2.5.6 - arm freescale imx25 ):

Quoted 8 lines

I have a xenomai application that uses more rt_tasks, and i have a strange behaviour.
When i run my application the period of *__ipipe_handle_irq* is very long ( ~3ms in some cases ) in the moment
that come the *__ipipe_mach_timerint *interrupt and so the other interrupts are very late.

Do you know something about this ?

I am sorry, but I do not understand your mail. __ipiep_handle_irq is not periodic and this sentence:

When i run my application the period of *__ipipe_handle_irq* is very long ( ~3ms in some cases ) in the moment
that come the *__ipipe_mach_timerint *interrupt and so the other

is not understandable.

Please try to describe your problem more clearly, or better, use the I-pipe tracer and record a trace of the problem, and post the relevant part of the trace here.

Signature · 1 line
					    Gilles.