> >> Next, how was in sucess to mix stl headers and kernel headers ?
> >> stl_alloc.h fails with PTHREAD_MUTEX_INITIALIZER
>
> OP> template <bool __threads, int __inst>
> OP> pthread_mutex_t
> OP> __default_alloc_template<__threads, __inst>::_S_node_allocator_lock
> OP> = PTHREAD_MUTEX_INITIALIZER;
>
> it seems that __STL_PHREADS is defined somewhere in your includes (?),
Yep, but where 8) ?
> because i don't even had warnings at this part of the code. i had some
> different errors with stl_alloc.h as i described sometime ago (using
> egcs too).
rtl-3.0preX ??
> this brings me to another question: is it possible that rtl-pthreads
> interfere with standard pthread-library? i had some problems compiling
> programs against qt and gtk+. they abort with error: Fatal X error or
> something like this. in the gtk-list i found that these problems are
> expected to rise when a multi-threaded application does not care much
> about locking and stuff like this. but the apps don't run properly
> only on some machines. hmm ...
I guess only the function calls are posix conform so if you mix rtl-posix and
linux pthreads you will get into trouble due to different internal, like this
PTHREAD_MUTEX_INITIALIZER;
> i played around with rtti in kernel space and found the following: i
> didn't get unresolved symbols on the mysterious frame_pointer. indeed
> it seems that the module can resolve it, because it has some symbols
> regarding the frame_pointer defined inside. but when i use
> dynamic_cast's inside my module i get an unresolved error for that
> specfic cast. when i remove the -fno-rtti flag from my compilations i
> addditionaly get unresolved errors for rtti_class and two other
> rtti_* classes. i link my module only against crtbegin.o and crtend,o
> without stdlibs.
rtti needs typeinfo's which are compiler spezific as I assume.
You can use an overlaoded int type() whih returns an unique id of each class.
Than you can compare a->type() == b->type(). dynamic_cast throws as well - here
you have the next problem. No having exceptions inside kernel is for me very
complicated, since I use to have it (auto_ptr etc....) An emulation wtith
global flags doesn't solve the problem really, since the object is constructed
allways. Well you can write in that manner that is working for kernel space,
but if you have interface classes for user and kernel space, you have a lot of
ifdef's.
For myself I never have needed crtbegin.o and crtend.o.
# nm `g++ -print-file-name=crtbegin.o`
00000000 ? __CTOR_LIST__
00000000 ? __DTOR_LIST__
00000000 ? __EH_FRAME_BEGIN__
w __deregister_frame_info
00000000 t __do_global_dtors_aux
w __register_frame_info
00000004 d completed.4
00000060 t fini_dummy
00000008 d force_to_data
00000070 t frame_dummy
00000000 t gcc2_compiled.
000000a0 t init_dummy
00000000 b object.11
00000000 d p.3
# nm `g++ -print-file-name=crtend.o`
00000000 ? __CTOR_END__
00000000 ? __DTOR_END__
00000000 ? __FRAME_END__
w __deregister_frame_info
00000000 t __do_global_ctors_aux
w __register_frame_info
00000000 d force_to_data
00000000 t gcc2_compiled.
00000030 t init_dummy
Only of interest ist __do_global_dtors_aux && __do_global_ctors_aux for
globals imo. No idea about the rest like _register_frame_info yet.
> but when i use c-style casts like the following:
>
> SomeDerivedClass* pDC = new SomeDerivedClass;
> void* pv = (void*) (pDC);
> SomeBaseClass* pBC = (SomeBaseClass*) pv;
>
> same for downcasts:
>
> SomeBaseClass *pBC; // assuming that pBC stores a
> // link to some derived class of
> // SomeBaseClass!
> ...
>
> void* pv = (void*) pBC;
> (SomeDerivedClass*) (pBC)->DoSomething();
>
> this perfectly works even with the -fno-rtti flag set ...
C-cast ... you know what you do - they are not type safe, so if you cast wrong
and use it, you can reboot (maybee).
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
