|

»

Gnome - ORBit - General

Crosscompiling ORBit2

View: New views

5 Messages — Rating Filter: Alert me

	Crosscompiling ORBit2 by Guillermo Sanchez-2 :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Hello collisters: I'm quite new in the ORBit world, so sorry if this is not the correct way of asking things. I wanted to compile an ORBit program (server, client, skelimp...) using RTAI flags (Real Time Aplication Interface) and includes, since I'm using this last to communicate ORBit with a real time process. I thought it would be a matter of makefile edition but when I edited it I realized how new I'm in this world. Indeed I don't know where ORBit2 compiles at all. Is there any chance of somebody to light my path? (I include the makefile's code) By the way, is there any difference between using g_thread_create and pthread_create? Also, can I create a thread inside the skeleton implementation code? Thanks a lot, Guillermo Makefile (modified code). ------------------------------------ prefix1 := $(shell rtai-config --prefix) prefix2 := /usr ifeq ($(prefix1),) $(error Please add <rtai-install>/bin to your PATH variable) endif CC = $(shell rtai-config --cc) LXRT_CFLAGS = $(shell rtai-config --lxrt-cflags) LXRT_LDFLAGS = $(shell rtai-config --lxrt-ldflags) ORBIT_IDL=$(prefix2)/bin/orbit-idl-2 CFLAGS=$(shell pkg-config ORBit-2.0 ORBit-CosNaming-2.0 --cflags) LDFLAGS=$(shell pkg-config ORBit-2.0 ORBit-CosNaming-2.0 --libs) TARGETS= Uneje-client Uneje-server IDLOUT= Uneje-common.c Uneje-stubs.c Uneje-skels.c Uneje.h all: $(IDLOUT) Uneje-client Uneje-server Uneje-server.o: Uneje-server.c Uneje-skelimpl.c Uneje-client : Uneje-client.o Uneje-stubs.o Uneje-common.o examples-toolkit.o Uneje-server : Uneje-server.o Uneje-skels.o Uneje-common.o examples-toolkit.o Uneje-skelimpl.o $(IDLOUT): Uneje.idl $(ORBIT_IDL) Uneje.idl %-skelimpl.c: %.idl $(ORBIT_IDL) --skeleton-impl $^ # This is how RTAI compiles: # $(CC) $(LXRT_CFLAGS) -o $@ $< $(LXRT_LDFLAGS) -llxrt # Possible Solution?: # $(CC) $(LXRT_CFLAGS) $(CFLAGS) -o $@ $< $(LDFLAGS) $(LXRT_LDFLAGS) -llxrt clean: rm -rf .o ~ $(IDLOUT) .ior .ref Uneje-client Uneje-server _______________________________________________ orbit-list mailing list orbit-list@... http://mail.gnome.org/mailman/listinfo/orbit-list
	Re: Crosscompiling ORBit2 by Frank Rehberger :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Guillermo Sanchez wrote: > Hello collisters: > > I'm quite new in the ORBit world, so sorry if this is not the correct > way of asking things. > > I wanted to compile an ORBit program (server, client, skelimp...) > using RTAI flags (Real Time Aplication Interface) and includes, since > I'm using this last to communicate ORBit with a real time process. I > thought it would be a matter of makefile edition but when I edited it > I realized how new I'm in this world. Indeed I don't know where ORBit2 > compiles at all. > > first you need to invoke the IDL compiler which generates the C code for your IDL interfaces, this way you will get the stubs and skeletons. $(IDLOUT): Uneje.idl $(ORBIT_IDL) Uneje.idl The skeletons are for the server-side, the stubs for the client side. These files are ordinary C files which can be compiled to object files with gcc. On server side you will need also to implement the skeletons, commonly called "classname-skeleton-impl.c", which implement the logic of your server. Hope that helps. > By the way, is there any difference between using g_thread_create and > pthread_create? > little, g_thread_create will be mapped onto pthread_create, but for portability it is better to choose g_thread_create, which might also do some magic in background. > Also, can I create a thread inside the skeleton implementation code? > Off course you can, but if it is about to calculate a return value, you should not. Instead, the requests are managed by the POA, the portable object adapter. This Adapter will be initialized with so called concurrency-policy, which can be "single-threaded", "thread-per-connection" or a "system" specific threaded policy. AFAICS, thread per connection is the best choice for RealTime applications. This way each client (alias connection) would be associated with a specific thread on server side, and requests of high priorized clients would not share thread-resources with requests of low priorized threads. RT-CORBA defines a n umber of thread-pool features, but they are not implemented for ORBit2 yet (AFAIK). Regards, Frank _______________________________________________ orbit-list mailing list orbit-list@... http://mail.gnome.org/mailman/listinfo/orbit-list
	Re: Crosscompiling ORBit2 by Guillermo Sanchez-2 :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Hi Frank, Thanks a lot for your answer. But I have no trouble in the stubs and skels creation through idl compilation - After running the "echo" example one hundred times i finally got it. My troubles appears in the next stage when compiling the server, client and skeleton implementation "classname-skelimp.c". I simply don't know where the flags are applied or where the compilation is done in the Makefile file. I know it has to be here: $(ORBIT_IDL) --skeleton-impl $^ But I don't know what is it doing or what's going on and I need to add some flags. The thread question comes because to use some RTAI funtions I have to launch a couple of threads. Threads that aren't going to give a response they will just be created, do their stuff in the server side and be destroyed every time I need them. Again thank you very much for the info. Cheers, Guillermo 2009/7/23 Frank Rehberger <Frank.Rehberger@...>: > Guillermo Sanchez wrote: >> Hello collisters: >> >> I'm quite new in the ORBit world, so sorry if this is not the correct >> way of asking things. >> >> I wanted to compile an ORBit program (server, client, skelimp...) >> using RTAI flags (Real Time Aplication Interface) and includes, since >> I'm using this last to communicate ORBit with a real time process. I >> thought it would be a matter of makefile edition but when I edited it >> I realized how new I'm in this world. Indeed I don't know where ORBit2 >> compiles at all. >> >> > first you need to invoke the IDL compiler which generates the C code for > your IDL interfaces, this way you will get the stubs and skeletons. > > $(IDLOUT): Uneje.idl > $(ORBIT_IDL) Uneje.idl > > > The skeletons are for the server-side, the stubs for the client side. > > These files are ordinary C files which can be compiled to object files > with gcc. > > On server side you will need also to implement the skeletons, commonly > called "classname-skeleton-impl.c", which implement the logic of your > server. > > Hope that helps. > >> By the way, is there any difference between using g_thread_create and >> pthread_create? >> > little, g_thread_create will be mapped onto pthread_create, but for > portability it is better to choose g_thread_create, which might also do > some magic in background. > >> Also, can I create a thread inside the skeleton implementation code? >> > Off course you can, but if it is about to calculate a return value, you > should not. > > Instead, the requests are managed by the POA, the portable object > adapter. This Adapter will be initialized with so called > concurrency-policy, which can be "single-threaded", > "thread-per-connection" or a "system" specific threaded policy. AFAICS, > thread per connection is the best choice for RealTime applications. This > way each client (alias connection) would be associated with a specific > thread on server side, and requests of high priorized clients would not > share thread-resources with requests of low priorized threads. RT-CORBA > defines a n umber of thread-pool features, but they are not implemented > for ORBit2 yet (AFAIK). > > Regards, Frank > _______________________________________________ orbit-list mailing list orbit-list@... http://mail.gnome.org/mailman/listinfo/orbit-list
	Re: Crosscompiling ORBit2 by Frank Rehberger :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Guillermo Sanchez wrote: > Hi Frank, > > Thanks a lot for your answer. But I have no trouble in the stubs and > skels creation through idl compilation - After running the "echo" > example one hundred times i finally got it. > > My troubles appears in the next stage when compiling the server, > client and skeleton implementation "classname-skelimp.c". I simply > don't know where the flags are applied or where the compilation is > done in the Makefile file. I know it has to be here: > > $(ORBIT_IDL) --skeleton-impl $^ > > But I don't know what is it doing or what's going on and I need to add > some flags. > Talking in terms of C++ or Java, the skeleton-impl inherits from skeleton, implementing the (well) "virtual" skeleton-methods. As the "inheriting" in pure C this is a bit cumbersome, the IDL compiler provides a feature to generate the corresponding skeleton-impl code (method-templates and vtables), so you just have got to add your code into the method templates. The skeleton-impl generation stuff is done once only, as long as IDL does not change. Mind that changing the IDL you might want to repeat the skeleton-impl generation, merging in your code again later. Regards, Frank > The thread question comes because to use some RTAI funtions I have to > launch a couple of threads. Threads that aren't going to give a > response they will just be created, do their stuff in the server side > and be destroyed every time I need them. > > Again thank you very much for the info. > > Cheers, > > Guillermo > > 2009/7/23 Frank Rehberger <Frank.Rehberger@...>: > >> Guillermo Sanchez wrote: >> >>> Hello collisters: >>> >>> I'm quite new in the ORBit world, so sorry if this is not the correct >>> way of asking things. >>> >>> I wanted to compile an ORBit program (server, client, skelimp...) >>> using RTAI flags (Real Time Aplication Interface) and includes, since >>> I'm using this last to communicate ORBit with a real time process. I >>> thought it would be a matter of makefile edition but when I edited it >>> I realized how new I'm in this world. Indeed I don't know where ORBit2 >>> compiles at all. >>> >>> >>> >> first you need to invoke the IDL compiler which generates the C code for >> your IDL interfaces, this way you will get the stubs and skeletons. >> >> $(IDLOUT): Uneje.idl >> $(ORBIT_IDL) Uneje.idl >> >> >> The skeletons are for the server-side, the stubs for the client side. >> >> These files are ordinary C files which can be compiled to object files >> with gcc. >> >> On server side you will need also to implement the skeletons, commonly >> called "classname-skeleton-impl.c", which implement the logic of your >> server. >> >> Hope that helps. >> >> >>> By the way, is there any difference between using g_thread_create and >>> pthread_create? >>> >>> >> little, g_thread_create will be mapped onto pthread_create, but for >> portability it is better to choose g_thread_create, which might also do >> some magic in background. >> >> >>> Also, can I create a thread inside the skeleton implementation code? >>> >>> >> Off course you can, but if it is about to calculate a return value, you >> should not. >> >> Instead, the requests are managed by the POA, the portable object >> adapter. This Adapter will be initialized with so called >> concurrency-policy, which can be "single-threaded", >> "thread-per-connection" or a "system" specific threaded policy. AFAICS, >> thread per connection is the best choice for RealTime applications. This >> way each client (alias connection) would be associated with a specific >> thread on server side, and requests of high priorized clients would not >> share thread-resources with requests of low priorized threads. RT-CORBA >> defines a n umber of thread-pool features, but they are not implemented >> for ORBit2 yet (AFAIK). >> >> Regards, Frank >> >> > _______________________________________________ > orbit-list mailing list > orbit-list@... > http://mail.gnome.org/mailman/listinfo/orbit-list > _______________________________________________ orbit-list mailing list orbit-list@... http://mail.gnome.org/mailman/listinfo/orbit-list
	Re: Crosscompiling ORBit2 by Guillermo Sanchez-2 :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Hi Frank, Thank you again. I really think I'm not explaining well where my trouble is. I'm sorry. First I create the idl file: myfile.idl After using the IDL compiler on myfile.idl by tiping in console: orbit-idl-2 --skeleton-impl myfile.idl I get: DO NOT EDIT --------------------- myfile-stubs.c myfile-skels.c myfile-common.c myfile.h TO EDIT ------------- myfile-skelimpl.c TO CREATE ------------------- myfile-client.c myfile-server.c After client and server creation (server is almost C&P-ed from another server file) I fill the skelimpl file with my code, just where it said /**********PUT YOUR CODE HERE********/ My code. /********END OF YOUR CODE*************/ After that, I have to compile the server and client in order to get an executable. And here is when the trouble comes. I want to the get executable done just by tiping "make" in console. Like in the "echo" example. But I have to edit the Makefile to change some things. I need to add flags and includes to compile it with RTAI. An there is where my knowledge ends. I got the includes and the prefixes for RTAI from another compilation, something like this: $(CC) $(LXRT_CFLAGS) -o $@ $< $(LXRT_LDFLAGS) -llxrt And to compile : gcc -o server 'pkg-config --cflags --libs ORBit-2.0' myfile-skelimpl.c myfile-common.c myfile-skels.c I need a common command for both of them, something like: server: $(CC) $(LXRT_CFLAGS) $(CFLAGS) -o pkg-config $@ $< myfile-skelimpl.c myfile-common.c myfile-skels.c $(LXRT_LDFLAGS) -llxrt $(LDFLAGS) Thanks. Cheers, Guillermo 2009/7/24 Frank Rehberger <Frank.Rehberger@...>: > Guillermo Sanchez wrote: >> Hi Frank, >> >> Thanks a lot for your answer. But I have no trouble in the stubs and >> skels creation through idl compilation - After running the "echo" >> example one hundred times i finally got it. >> >> My troubles appears in the next stage when compiling the server, >> client and skeleton implementation "classname-skelimp.c". I simply >> don't know where the flags are applied or where the compilation is >> done in the Makefile file. I know it has to be here: >> >> $(ORBIT_IDL) --skeleton-impl $^ >> >> But I don't know what is it doing or what's going on and I need to add >> some flags. >> > Talking in terms of C++ or Java, the skeleton-impl inherits from > skeleton, implementing the (well) "virtual" skeleton-methods. > As the "inheriting" in pure C this is a bit cumbersome, the IDL > compiler provides a feature to generate the corresponding skeleton-impl > code (method-templates and vtables), so you just have got to add your > code into the method templates. > > The skeleton-impl generation stuff is done once only, as long as IDL > does not change. Mind that changing the IDL you might want to repeat > the skeleton-impl generation, merging in your code again later. > > Regards, Frank > >> The thread question comes because to use some RTAI funtions I have to >> launch a couple of threads. Threads that aren't going to give a >> response they will just be created, do their stuff in the server side >> and be destroyed every time I need them. >> >> Again thank you very much for the info. >> >> Cheers, >> >> Guillermo >> >> 2009/7/23 Frank Rehberger <Frank.Rehberger@...>: >> >>> Guillermo Sanchez wrote: >>> >>>> Hello collisters: >>>> >>>> I'm quite new in the ORBit world, so sorry if this is not the correct >>>> way of asking things. >>>> >>>> I wanted to compile an ORBit program (server, client, skelimp...) >>>> using RTAI flags (Real Time Aplication Interface) and includes, since >>>> I'm using this last to communicate ORBit with a real time process. I >>>> thought it would be a matter of makefile edition but when I edited it >>>> I realized how new I'm in this world. Indeed I don't know where ORBit2 >>>> compiles at all. >>>> >>>> >>>> >>> first you need to invoke the IDL compiler which generates the C code for >>> your IDL interfaces, this way you will get the stubs and skeletons. >>> >>> $(IDLOUT): Uneje.idl >>> $(ORBIT_IDL) Uneje.idl >>> >>> >>> The skeletons are for the server-side, the stubs for the client side. >>> >>> These files are ordinary C files which can be compiled to object files >>> with gcc. >>> >>> On server side you will need also to implement the skeletons, commonly >>> called "classname-skeleton-impl.c", which implement the logic of your >>> server. >>> >>> Hope that helps. >>> >>> >>>> By the way, is there any difference between using g_thread_create and >>>> pthread_create? >>>> >>>> >>> little, g_thread_create will be mapped onto pthread_create, but for >>> portability it is better to choose g_thread_create, which might also do >>> some magic in background. >>> >>> >>>> Also, can I create a thread inside the skeleton implementation code? >>>> >>>> >>> Off course you can, but if it is about to calculate a return value, you >>> should not. >>> >>> Instead, the requests are managed by the POA, the portable object >>> adapter. This Adapter will be initialized with so called >>> concurrency-policy, which can be "single-threaded", >>> "thread-per-connection" or a "system" specific threaded policy. AFAICS, >>> thread per connection is the best choice for RealTime applications. This >>> way each client (alias connection) would be associated with a specific >>> thread on server side, and requests of high priorized clients would not >>> share thread-resources with requests of low priorized threads. RT-CORBA >>> defines a n umber of thread-pool features, but they are not implemented >>> for ORBit2 yet (AFAIK). >>> >>> Regards, Frank >>> >>> >> _______________________________________________ >> orbit-list mailing list >> orbit-list@... >> http://mail.gnome.org/mailman/listinfo/orbit-list >> > > _______________________________________________ orbit-list mailing list orbit-list@... http://mail.gnome.org/mailman/listinfo/orbit-list