Re: [Xenomai-core] libnative versioning
Philippe Gerum wrote: > There is one for the nucleus already, so maybe we could extend the > feature. This said, the point ABI revs is basically to detect potential > mismatches; would an old POSIX app run improperly over the new library, > or would it choke at startup? The mismatch would occur if running the new library with an old kernel or an old library with a new kernel, the pthread_cond_wait and pthread_cond_timedwait syscalls have been replaced with pthread_cond_wait_prologue/pthread_cond_wait_epilogue. -- Gilles Chanteperdrix ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] libnative versioning
On Fri, 2006-12-01 at 18:44 +0100, Gilles Chanteperdrix wrote: > Philippe Gerum wrote: > > > > The Xenomai ABI has been kept compatible between versions > > I am afraid you are being optimistic: I for one made some changes in the > posix skin that break the kernel/user interface. Sorry, I've been unclear: s,Xenomai ABI,Xenomai native interface ABI, > Maybe we need an ABI > revision for each skin ? > There is one for the nucleus already, so maybe we could extend the feature. This said, the point ABI revs is basically to detect potential mismatches; would an old POSIX app run improperly over the new library, or would it choke at startup? -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] libnative versioning
Philippe Gerum wrote: > > The Xenomai ABI has been kept compatible between versions I am afraid you are being optimistic: I for one made some changes in the posix skin that break the kernel/user interface. Maybe we need an ABI revision for each skin ? -- Gilles Chanteperdrix ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] libnative versioning
On Fri, 2006-12-01 at 16:39 +0100, Jan Kiszka wrote: > Hi, > > we just had some fun here with incompatible native libraries. A program > was built against some 2.2 release and was then started on a target with > 2.3 libs installed. The result: undefined symbol rt_mutex_lock. The > reason: this function was renamed to rt_mutex_acquire in trunk to > resolve a naming conflict in recent kernels. > > So we now have incompatible libraries and should either increment some > version number of libnative or export the necessary aliases for > lock/unlock. What is preferred? The Xenomai ABI has been kept compatible between versions, so we want to provide the proper aliases for user-space; the conflict is kernel-space only, and there is no reason to ask user-space apps to conform to some obscure change that took place within the vanilla kernel API. Actually, I already wrappers in include/native/mutex.h, but unfortunately as macros, so dynamic binding could not work. I'm fixing this. Thanks. > > Jan > > ___ > Xenomai-core mailing list > Xenomai-core@gna.org > https://mail.gna.org/listinfo/xenomai-core -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] libnative versioning
Hi, we just had some fun here with incompatible native libraries. A program was built against some 2.2 release and was then started on a target with 2.3 libs installed. The result: undefined symbol rt_mutex_lock. The reason: this function was renamed to rt_mutex_acquire in trunk to resolve a naming conflict in recent kernels. So we now have incompatible libraries and should either increment some version number of libnative or export the necessary aliases for lock/unlock. What is preferred? Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
