Philippe Gerum wrote:
> On Fri, 2006-12-01 at 16:39 +0100, Jan Kiszka wrote:
>> 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.
And this fixes the fix (/wrt C++ users).
--- include/native/mutex.h (revision 1920)
+++ include/native/mutex.h (working copy)
@@ -121,10 +121,6 @@ int rt_mutex_release(RT_MUTEX *mutex);
int rt_mutex_inquire(RT_MUTEX *mutex,
#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,18)
static inline int __deprecated_call__ rt_mutex_lock(RT_MUTEX *mutex, RTIME
@@ -146,4 +142,8 @@ int rt_mutex_unlock(RT_MUTEX *mutex);
#endif /* __KERNEL__ */
#endif /* !_XENO_MUTEX_H */
Xenomai-core mailing list