Re: [Xenomai-core] Problems with satch.c under Linux 2.4
On Wed, Mar 12, 2008 at 11:22 AM, Wolfgang Grandegger [EMAIL PROTECTED] wrote: Gilles Chanteperdrix wrote: Wolfgang Grandegger wrote: Hello, I tried to test the POSIX example program satch.c under Linux 2.4.25 for PPC. I was able to fix a few issues but the module does still not load. I have attached a patch for Xenomai 2.4.2 fixing: - User-space satch: It was necessary to move time.h and signal.h to the end of the include block to get it compiled (otherwise clockid_t is defined, etc.) - User-space satch: It was necessary to move #define xnprintf printf behind the include block, otherwise the linker complains about missing symbols. I wonder how this can work with 2.6. And what is the status of xnprintf? - Makefile: to avoid a mixup of CFLAG definitions for compiling the user-space and kernel-space part, I renamed CFLAGS to UCFLAGS etc. (see patch). Note sure if this is an issue for 2.6 as well. - Makefile: I added -DPRODUCER to the module build with Linux 2.4. - I got the module build, but insmod fails with: bash-2.05b# insmod satch.o satch.o: unresolved symbol shm_unlink satch.o: unresolved symbol ftruncate satch.o: unresolved symbol shm_open satch.o: unresolved symbol munmap satch.o: unresolved symbol mmap satch.o: unresolved symbol pse51_shm_close Any idea why? Thanks, Does the following patch improve anything ? Yes, the order of the include files does not make trouble any more. Nevertheless, I need the attached patch to fix the remaining problems with CFLAGS mangling and missing -DPRODUCER. Do we really need the UCFLAGS stuff ? CFLAGS is a standard thing, how do the other examples cope with the same problem ? Perhaps we could put modules compilation in a separated makefile name Kbuild ? -- Gilles Chanteperdrix ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Problems with satch.c under Linux 2.4
Gilles Chanteperdrix wrote: On Wed, Mar 12, 2008 at 11:22 AM, Wolfgang Grandegger [EMAIL PROTECTED] wrote: Gilles Chanteperdrix wrote: Wolfgang Grandegger wrote: Hello, I tried to test the POSIX example program satch.c under Linux 2.4.25 for PPC. I was able to fix a few issues but the module does still not load. I have attached a patch for Xenomai 2.4.2 fixing: - User-space satch: It was necessary to move time.h and signal.h to the end of the include block to get it compiled (otherwise clockid_t is defined, etc.) - User-space satch: It was necessary to move #define xnprintf printf behind the include block, otherwise the linker complains about missing symbols. I wonder how this can work with 2.6. And what is the status of xnprintf? - Makefile: to avoid a mixup of CFLAG definitions for compiling the user-space and kernel-space part, I renamed CFLAGS to UCFLAGS etc. (see patch). Note sure if this is an issue for 2.6 as well. - Makefile: I added -DPRODUCER to the module build with Linux 2.4. - I got the module build, but insmod fails with: bash-2.05b# insmod satch.o satch.o: unresolved symbol shm_unlink satch.o: unresolved symbol ftruncate satch.o: unresolved symbol shm_open satch.o: unresolved symbol munmap satch.o: unresolved symbol mmap satch.o: unresolved symbol pse51_shm_close Any idea why? Thanks, Does the following patch improve anything ? Yes, the order of the include files does not make trouble any more. Nevertheless, I need the attached patch to fix the remaining problems with CFLAGS mangling and missing -DPRODUCER. Do we really need the UCFLAGS stuff ? CFLAGS is a standard thing, how do the other examples cope with the same problem ? Perhaps we could put modules compilation in a separated makefile name Kbuild ? For Linux 2.4 we use this module capturing trick to get the CFLAGS of the kernel. That's what makes trouble. So, the problem only shows up when modules need to be built for Linux 2.4 together with at least on application. Yes, it might be better to use KCFLAGS for module compilation for 2.4. Going to find a better solution a.s.a.p. Wolfgang. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Problems with satch.c under Linux 2.4
On Tue, Mar 11, 2008 at 11:10 AM, Wolfgang Grandegger [EMAIL PROTECTED] wrote: Hello, I tried to test the POSIX example program satch.c under Linux 2.4.25 for PPC. I was able to fix a few issues but the module does still not load. I have attached a patch for Xenomai 2.4.2 fixing: - User-space satch: It was necessary to move time.h and signal.h to the end of the include block to get it compiled (otherwise clockid_t is defined, etc.) This should not happen, header file should not depend on the inclusion order. - User-space satch: It was necessary to move #define xnprintf printf behind the include block, otherwise the linker complains about missing symbols. I wonder how this can work with 2.6. And what is the status of xnprintf? - Makefile: to avoid a mixup of CFLAG definitions for compiling the user-space and kernel-space part, I renamed CFLAGS to UCFLAGS etc. (see patch). Note sure if this is an issue for 2.6 as well. - Makefile: I added -DPRODUCER to the module build with Linux 2.4. I tested satch recently on trunk. I had to make the printf change (xnprintf is now defined in xenomai include files to xnarch_printf, but xnarch_printf is not defined when compiling in user space, so I replaced #define xnprintf printf with #define xnarch_printf printf) to make it work again, but I saw no problem with include file order. - I got the module build, but insmod fails with: bash-2.05b# insmod satch.o satch.o: unresolved symbol shm_unlink satch.o: unresolved symbol ftruncate satch.o: unresolved symbol shm_open satch.o: unresolved symbol munmap satch.o: unresolved symbol mmap satch.o: unresolved symbol pse51_shm_close Any idea why? Because satch uses xenomai posix shared memories, so you have to enable support for shared memories in the posix module configuration. Thanks, Wolfgang. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core -- Gilles Chanteperdrix ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Problems with satch.c under Linux 2.4
On Tue, Mar 11, 2008 at 12:43 PM, Wolfgang Grandegger [EMAIL PROTECTED] wrote: Gilles Chanteperdrix wrote: On Tue, Mar 11, 2008 at 11:10 AM, Wolfgang Grandegger [EMAIL PROTECTED] wrote: Hello, I tried to test the POSIX example program satch.c under Linux 2.4.25 for PPC. I was able to fix a few issues but the module does still not load. I have attached a patch for Xenomai 2.4.2 fixing: - User-space satch: It was necessary to move time.h and signal.h to the end of the include block to get it compiled (otherwise clockid_t is defined, etc.) This should not happen, header file should not depend on the inclusion order. True, but it happens quite often :-(. - User-space satch: It was necessary to move #define xnprintf printf behind the include block, otherwise the linker complains about missing symbols. I wonder how this can work with 2.6. And what is the status of xnprintf? - Makefile: to avoid a mixup of CFLAG definitions for compiling the user-space and kernel-space part, I renamed CFLAGS to UCFLAGS etc. (see patch). Note sure if this is an issue for 2.6 as well. - Makefile: I added -DPRODUCER to the module build with Linux 2.4. I tested satch recently on trunk. I had to make the printf change (xnprintf is now defined in xenomai include files to xnarch_printf, but xnarch_printf is not defined when compiling in user space, so I replaced #define xnprintf printf with #define xnarch_printf printf) to make it work again, but I saw no problem with include file order. The problem with xnprintf goes away with #define xnarch_printf printf. I have attached the make log showing the errors with the original include file order. Ok. I will check this tonight. -- Gilles Chanteperdrix ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
