Thread: [Opentnl-general] Porting Question
Brought to you by:
mark_frohnmayer,
s_alanet
From: Boris K. <Fli...@in...> - 2004-10-26 15:33:18
|
Hi ! We would like to use the TNL for a project where a high level of cross-platform compatability is very much desired. Having been recommended to use the TNL, we considered it a very interesting project and a good choice. However, a couple of weeks ago we learnt that the TNL currently compiles only on a relatively small set of platforms - compared to other cross-platform networking libraries that compile on pretty much any POSIX-compliant OS, - also there seem to be problems related to using recent GCC versions ? Regardless of that, we'd still like to use the TNL for our project, simply because it seems by far the most powerful and user-friendly library that's available - and libraries like ACE would certainly be beyond the scope of our project. So, we're hoping to be able to obtain our goals relatively quickly using the TNL. We are wondering what would be involved in trying to port the TNL to another platforms, whether there have been any such efforts attempted before and what hurdles we can expect to face. We did read on your webpage that the TNL should actually be fairly "simple" to port over to other platforms, as it uses platform specific "modules", having recently looked into the platforms.h and tnlTypes.h headers, it seems somewhat possible to give it a go, however we'd still like to get some feedback about the process itself and the things that we need to keep an eye on - possibly there are even some pointers about the porting process ? Maybe you folks can at least provide us with some feedback about how feasible the attempt would really be - or simply why exactly it is that the TNL currently compiles only on a relatively small set of platforms, taking into account that it is supposed to be "cross-platform". Thanks for your help in advance ---------- Boris |
From: Mark F. <ma...@ga...> - 2004-10-26 17:38:01
|
Hi Boris, The one gotcha for TNL as far as multiplatform capability is that the RPC mechanism uses specialized assembly language functions to read stack arguments and then dispatch the function call on the remote host. I'm currently working on a version of that code that uses templates instead, that should be totally cross-platform. What platforms are you looking at porting to? You can look at tnlMethodDispatch.cpp/.h for the architecture specific assembly code. - Mark Boris Koenig wrote: > Hi ! > > We would like to use the TNL for a project where a high level of > cross-platform compatability is very much desired. > > Having been recommended to use the TNL, we considered it a very > interesting project and a good choice. > > However, a couple of weeks ago we learnt that the TNL currently > compiles only on a relatively small set of platforms - compared to > other cross-platform networking libraries that compile on > pretty much any POSIX-compliant OS, - also there seem to be > problems related to using recent GCC versions ? > > Regardless of that, we'd still like to use the TNL for our project, > simply because it seems by far the most powerful and user-friendly > library that's available - and libraries like ACE would certainly > be beyond the scope of our project. > > So, we're hoping to be able to obtain our goals relatively quickly > using the TNL. > > We are wondering what would be involved in trying to port the TNL > to another platforms, whether there have been any such efforts attempted > before and what hurdles we can expect to face. > > We did read on your webpage that the TNL should actually be fairly > "simple" to port over to other platforms, as it uses platform specific > "modules", having recently looked into the platforms.h and tnlTypes.h > headers, it seems somewhat possible to give it a go, however we'd > still like to get some feedback about the process itself and the things > that we need to keep an eye on - possibly there are even some pointers > about the porting process ? > > Maybe you folks can at least provide us with some feedback about > how feasible the attempt would really be - or simply why exactly > it is that the TNL currently compiles only on a relatively small > set of platforms, taking into account that it is supposed to be > "cross-platform". > > > Thanks for your help in advance > > > ---------- > Boris > > > ------------------------------------------------------- > This SF.net email is sponsored by: IT Product Guide on ITManagersJournal > Use IT products in your business? Tell us what you think of them. Give us > Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out > more > http://productguide.itmanagersjournal.com/guidepromo.tmpl > _______________________________________________ > Opentnl-general mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opentnl-general |
From: Boris K. <Fli...@in...> - 2004-10-26 18:13:06
|
Mark Frohnmayer wrote: > Hi Boris, Hi Mark ! > The one gotcha for TNL as far as multiplatform capability is that the > RPC mechanism uses specialized assembly language functions to read stack > arguments and then dispatch the function call on the remote host. okay, I see - does that mean, that we might have better chances if we simply decided not to use TNL's RPC functionality ? > I'm currently working on a version of that code that uses templates instead, > that should be totally ross-platform. sounds good ! :-) > What platforms are you looking at porting to? actually, we didn't yet really look into specific platforms, rather we did "by accident" notice that TNL doesn't seem to compile on each platform that easily. That's also when we checked the exact description on the webpage and noticed the remark that it would generally only compile on three different platforms, that's where we stopped to look into the details. The platforms where we encountered said problems were mostly typical unix platforms (SGI/Irix) if I remember correctly. Also, the TNL webpage reads that there's currently only support for x86 linux ? A maximally platform-independent implementation would be preferable because we could use the TNL for all components of our project, while we would otherwise be forced to use the TNL stuff only for the client side because most usual server platforms aren't yet supported. I am sure that other users of your library would probably also benefit from such an almost "platform-independent" implementation. > You can look at tnlMethodDispatch.cpp/.h for the architecture specific > assembly code. Okay, thanks for that hint - I am going to look into it, but actually we wouldn't want to mess around with assembly code. How much work do you think is involved in porting the current assembly code-based approach over to a pure C++/template oriented one ? Depending on the amount of time that might take, we could meanwhile try to determine where exactly the TNL sources need to be modified in order to compile with recent versions of GCC - if that'd help. Additionally, I would have personally found it helpful if the library had been packaged like a standard GNU tarball, including a conventional configure/makefile build chain, possibly with a central default location where to place the header files - what do you think ? Thanks -------- Boris |
From: Mark F. <ma...@ga...> - 2004-10-26 18:26:55
|
Boris Koenig wrote: > Mark Frohnmayer wrote: > > okay, I see - does that mean, that we might have better chances if we > simply decided not to use TNL's RPC functionality ? > Much of TNL's higher level functionality (GhostConnetion) depends on the RPC stuff working, so although you could strip it out, you would lose much useful functionality. This may or may not be an issue depending on your application. >> I'm currently working on a version of that code that uses templates >> instead, that should be totally ross-platform. > > > sounds good ! :-) > >> What platforms are you looking at porting to? > > > actually, we didn't yet really look into specific platforms, rather we > did "by accident" notice that TNL doesn't seem to compile on each > platform that easily. It should compile directly on x86linux, win32 and Mac OSX. > > That's also when we checked the exact description on the webpage and > noticed the remark that it would generally only compile on three > different platforms, that's where we stopped to look into the details. > > The platforms where we encountered said problems were mostly typical > unix platforms (SGI/Irix) if I remember correctly. > > Also, the TNL webpage reads that there's currently only support > for x86 linux ? For linux, yes. It should also be a trivial port to PPC linux, since there's a PPC version of the assembly code for OS X. > > A maximally platform-independent implementation would be preferable > because we could use the TNL for all components of our project, > while we would otherwise be forced to use the TNL stuff only for the > client side because most usual server platforms aren't yet supported. Of course... though x86 linux is a fairly common server platform. > Depending on the amount of time that might take, we could meanwhile > try to determine where exactly the TNL sources need to be modified in > order to compile with recent versions of GCC - if that'd help. It should compile fine with GCC 2.9.5 and 3.x > > Additionally, I would have personally found it helpful if the library > had been packaged like a standard GNU tarball, including a conventional > configure/makefile build chain, possibly with a central default location > where to place the header files - what do you think ? We currently don't have a Unix master on the project to manage such a thing. Are you volunteering? :) - Mark |
From: Boris K. <Fli...@in...> - 2004-10-27 06:26:08
|
Mark Frohnmayer wrote: > Boris Koenig wrote: > >> Mark Frohnmayer wrote: >> >> okay, I see - does that mean, that we might have better chances if we >> simply decided not to use TNL's RPC functionality ? >> > Much of TNL's higher level functionality (GhostConnetion) depends on the > RPC stuff working, so although you could strip it out, you would lose > much useful functionality. This may or may not be an issue depending on > your application. I was merely trying to get some feedback whether not to use RPC functionality would solve some of the porting issues. As John said already: being able to use RPC would definitely be "nice". >> Also, the TNL webpage reads that there's currently only support >> for x86 linux ? > > > For linux, yes. It should also be a trivial port to PPC linux, since > there's a PPC version of the assembly code for OS X. I seel, well I don't think it's necessary to do that - because if the general plans are to slowly migrate over to a template based approach for the platform specific code, it should not be that important for us - regardless of how long the actual migration is going to take. >> A maximally platform-independent implementation would be preferable >> because we could use the TNL for all components of our project, >> while we would otherwise be forced to use the TNL stuff only for the >> client side because most usual server platforms aren't yet supported. > > > Of course... though x86 linux is a fairly common server platform. yes, certainly right - but there's so much POSIX stuff that people use ... x86 is probably not always the first choice. >> Depending on the amount of time that might take, we could meanwhile >> try to determine where exactly the TNL sources need to be modified in >> order to compile with recent versions of GCC - if that'd help. > > > It should compile fine with GCC 2.9.5 and 3.x I haven't had problems with that personally, but I think John can comment on that ? >> Additionally, I would have personally found it helpful if the library >> had been packaged like a standard GNU tarball, including a conventional >> configure/makefile build chain, possibly with a central default location >> where to place the header files - what do you think ? > > > We currently don't have a Unix master on the project to manage such a > thing. Are you volunteering? lol, well I wouldn't mind to look into it in more detail, I just noticed that the current Makefiles mention that you ultimatley intend to switch to autconf/automake, so a first stab at it would probably not be a bad idea, one could still keep the old makefiles around as a fallback solution. ---------- Boris |
From: John W. <ca...@mm...> - 2004-10-27 14:23:50
|
Boris Koenig wrote: > Mark Frohnmayer wrote: > > >> >> >> It should compile fine with GCC 2.9.5 and 3.x > > > I haven't had problems with that personally, but I think John > can comment on that ? > I've had no problems with GCC 2.9.5 and 3.0. Believe Jon Stockill was having run time problems with the dynamic casting when we ran the field test. <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< ----- Original Message ----- > From: "Jon Stockill" <li...@st...> > To: "FlightGear developers discussions" <fli...@fl...> > Sent: Saturday, October 09, 2004 3:41 AM > Subject: Re: [Flightgear-devel] Buildiing/running the ATC network test > > >> > >> > And the master falls over: >> > >> > Program received signal SIGSEGV, Segmentation fault. >> > [Switching to Thread 16384 (LWP 11705)] >> > 0x080a3e68 in ?? () >> > (gdb) bt >> > #0 0x080a3e68 in ?? () >> > #1 0x400e0974 in __dynamic_cast (from=0x80a3e68, >> > to=0x807b740 <typeinfo for TNL::Object>, require_public=134723644, >> > address=0x0, sub=0xbfffefb8, subptr=0x4000a490) >> > at ../../gcc-2.95.3/gcc/cp/tinfo2.cc:282 >> > #2 0x08056613 in TNL::NetConnectionRep::create ( >> > name=0xbfffeb80 "MasterServerConnection") at netConnection.cpp:50 >> > #3 0x0805c458 in TNL::NetInterface::handleConnectRequest (this=0x809a520, > > >>> > address=@0xbffff010, stream=0xbffff030) at netInterface.cpp:762 >>> > #4 0x0805b11f in TNL::NetInterface::processPacket (this=0x809a520, >>> > sourceAddress=@0xbffff010, pStream=0xbffff030) at >> >> >> netInterface.cpp:462 > > >>> > #5 0x0805affb in TNL::NetInterface::checkIncomingPackets(this=0x809a520) >> >> >>> > at netInterface.cpp:422 >>> > #6 0x08049cc6 in main (argc=1, argv=0xbffff7f4) at main.cpp:667 >>> > (gdb) >>> > >>> > >> >> >> It looks like they assert the case when the the NULL pointer is returned, >> but don't catch the exception throw. I guess the bigger question is why the > > >> dynamic_cast fails. Need to dig a little more... >> >> BTW, is this the same problem you had when you tried to connect with the >> controller/pilot nodes during the field test. The test log shows the initial > >> handshake sequence, a couple of resends by the master, and then "silence" > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Have been unable to duplicate or decipher where the problem might be. Need to query Jon on more details on system specifics, Linux version, GCC, etc Regards John W. |
From: John W. <ca...@mm...> - 2004-10-27 00:33:06
|
Mark Frohnmayer wrote: > Hi Boris, > > The one gotcha for TNL as far as multiplatform capability is that the > RPC mechanism uses specialized assembly language functions to read > stack arguments and then dispatch the function call on the remote > host. I'm currently working on a version of that code that uses > templates instead, that should be totally cross-platform. What > platforms are you looking at porting to? > > You can look at tnlMethodDispatch.cpp/.h for the architecture specific > assembly code. > One of the more attractive aspects (at least in my ideas for the OpenATC protocol) is the use of the RPC mechanisms. For the interested reader, see Chap 18 in Unix Network Programming by Stevens to better understand the problems and pitfalls in implementing RPCs. 100% cross-platform compatibility is a goal, not an absolute. Regards John W. |