Subject: Re: [dtn-users] DTN2 release plan...
From: "Scott, Keith L." <[email-masked]>
To: Stephen Farrell <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: DTN <[email-masked]>
Date: Thu, 23 Sep 2010 14:13:25 -0400
List-Id: dtn-users mailing list <dtn-users.maillists.intel-research.net>

We've got some multicast extensions, some outputs from the NASA work, and a gossiping/anti-entropy DTN router we're working on that I would like to coordinate insertion of.

		--keith

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephen Farrell
Sent: Thursday, September 23, 2010 8:40 AM
To: [email-masked]
Cc: DTN
Subject: [dtn-users] DTN2 release plan...

Hiya,

We're thinking of getting started on a process to do a DTN2 2.8 for
release early in the new year, probably in Feb/Mar.

The main reason for us is that we have a number of changes and
additions from the N4C project that should be pushed out before that
project finishes at the end of April. I know there are a few other
folks who have things they've developed who'd also like to get them
into a DTN2 release, so if you're interested in helping with this
or have code you'd like to get into that release, then please
reply to this (just on the dtn-users list please) and we can start
the job of seeing what to include and who can do what to get it
done.

Thanks,
Stephen.

_______________________________________________
dtn-users mailing list
[email-masked]
http://maillists.intel-research.net/mailman/listinfo/dtn-users

From: Darren Long <[email-masked]>
Date: Thu, 23 Sep 2010 19:07:34 +0100
To: Stephen Farrell <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-users] [dtn-interest] DTN2 release plan...

Hi,

I'd like the AX.25 Connected Mode CL to make it into the next release, though I'm guessing that as it is in the upstream repo already, it will be probably be in the release by default.  

I've got some  tweaks for it which I've not pushed upstream yet, and I've started to knock up a discovery mechanism too which I'd hope would be useable in the timeframe you mention. 

Cheers,

Darren

On 23 Sep 2010, at 13:39, Stephen Farrell wrote:

> 
> Hiya,
> 
> We're thinking of getting started on a process to do a DTN2 2.8 for
> release early in the new year, probably in Feb/Mar.
> 
> The main reason for us is that we have a number of changes and
> additions from the N4C project that should be pushed out before that
> project finishes at the end of April. I know there are a few other
> folks who have things they've developed who'd also like to get them
> into a DTN2 release, so if you're interested in helping with this
> or have code you'd like to get into that release, then please
> reply to this (just on the dtn-users list please) and we can start
> the job of seeing what to include and who can do what to get it
> done.
> 
> Thanks,
> Stephen.
> 
> 
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Date: Thu, 23 Sep 2010 18:42:40 +0100
From: Elwyn Davies <[email-masked]>
To: Stephen Farrell <[email-masked]>
Cc: dtn-users <[email-masked]>
Subject: Re: [dtn-users] DTN2 release plan...

Hi.

Sounds like a good idea. Count me in.

I have a number of things which I have done or am planning to do over 
the next few months:
- Look at some problems I identified while writing the functional spec 
(documented within the fs).
- Add a few bug fixes including the one that Darren Long found a couple 
of weeks ago in the Python interface for which we have a fix.
- Improve the manual particularly as regards the TCL configuration 
commands. I have the full text in the fs already. Need to decide on the 
format for an HTML version (preferably by setting up a suitable CSS - i 
have discussed this with Alex McMahon in the past). One approach would 
be to use the same CSS that Doxygen uses so that the manual has the same 
look and feel as the auto-generated Doxygen stuff. BTW we have also got 
an improved version of the Doxygen config that produces more diagrams.
- I am intending to develop a new and more integrated version of the 
PRoPHET routing protocol stack over the next few months.

Regards,
Elwyn

Stephen Farrell wrote:
> Hiya,
>
> We're thinking of getting started on a process to do a DTN2 2.8 for
> release early in the new year, probably in Feb/Mar.
>
> The main reason for us is that we have a number of changes and
> additions from the N4C project that should be pushed out before that
> project finishes at the end of April. I know there are a few other
> folks who have things they've developed who'd also like to get them
> into a DTN2 release, so if you're interested in helping with this
> or have code you'd like to get into that release, then please
> reply to this (just on the dtn-users list please) and we can start
> the job of seeing what to include and who can do what to get it
> done.
>
> Thanks,
> Stephen.
>
>
>
> _______________________________________________
> dtn-users mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-users
>   

Date: Thu, 23 Sep 2010 13:39:31 +0100
From: Stephen Farrell <[email-masked]>
To: [email-masked]
Cc: DTN <[email-masked]>
Subject: [dtn-users] DTN2 release plan...

Hiya,

We're thinking of getting started on a process to do a DTN2 2.8 for
release early in the new year, probably in Feb/Mar.

The main reason for us is that we have a number of changes and
additions from the N4C project that should be pushed out before that
project finishes at the end of April. I know there are a few other
folks who have things they've developed who'd also like to get them
into a DTN2 release, so if you're interested in helping with this
or have code you'd like to get into that release, then please
reply to this (just on the dtn-users list please) and we can start
the job of seeing what to include and who can do what to get it
done.

Thanks,
Stephen.

Date: Tue, 21 Sep 2010 17:25:27 -0400
From: Victor lyamtsev <[email-masked]>
To: [email-masked]
Subject: [dtn-users] questions regarding dtn address resolution in DTN2

I've been trying to follow comments in dtn.conf, but the proper use of
 "routes", "linkes" and "interfaces" still evades me...

For example, suppose I would like me DTN2 daemon "A" on 10.0.1.1 to
forward bundles to the daemon "B" bound to interface
udp://10.0.1.2:4444. What entries in "conf" files on "A" and "B"
should I make?
Should i add
interface add udp 0 udp
route add  10.0.1.2:4444 udp0 - on host A

link add link1  dtn://hostA/* ONDEMAND udp - on host B ?

Is it possible to have multiple udp interfaces with one network interface?

I'd appreciate if someone clarify this.
Thank you,
-V

Date: Fri, 17 Sep 2010 13:33:08 +0100
From: Elwyn Davies <[email-masked]>
To: Darren Long <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-users] dtn_cancel in python

Darren Long wrote:
> Hi,
>
> Yep, I confirm that your proposed fix works for me.
>
> Darren
>   
Great!  I'll file a bug report and update the source code in due course 
(I'm supposed to be having a break this week!)

Thanks for testing this.

Regards,
Elwyn
> ----- Original message -----
>   
>> Hi, Darren.
>>
>> A couple of points in line...
>>
>> Darren Long wrote:
>>     
>>> Hi,
>>>
>>> Thanks for the pointers.
>>>
>>> On 16 Sep 2010, at 18:45, Elwyn Davies wrote:
>>>
>>>
>>>       
>>>> Hi, Darren.
>>>>
>>>> I have used the Python wrappers but as it turns out not the
>>>> dtn_cancel wrapper.
>>>>
>>>> Having had a look through the code, I notice:
>>>> 1. The Python test code in applib/python/test-swig-api.py doesn't
>>>> exercise dtn_cancel.
>>>>
>>>>         
>>> Actually, I was originally only wondering about whether or not the
>>> core bundle cancel functionality worked as I'd never tried it and
>>> figured I'd test it quickly by hacking test-swig-api.py to call it. 
>>> At least I know know that it works in the core system, even if there
>>> is an issue with the python bindings.   Still, it would be good to
>>> figure out a fix for it, as I have a couple of minor python projects
>>> for dtn on the slow cooker :)
>>>
>>>       
>> I think the fix is extremely simple... more below.
>>     
>>>> 2. The dtn_api_wrap.cc (from which I believe the SWIG code is
>>>> generated does not explicitly set the frag_offset and orig_length
>>>> fields in the bundle_id_t structure which is passed across to the
>>>> api server (the C++
>>>>
>>>>         
>>> I keep forgetting that's there's actually a C++ wrapper for a C++ core
>>> with a C API, perhaps deliberately.
>>>
>>>
>>>       
>> It's a little strange. The C interface (which stems from using the Sun 
>> RPC tools to generate the interface code) uses the full bundle_id_t 
>> directly so that in principle fragment bundles can be deleted while the 
>> script wrappers use the reduced form that can only handle complete 
>> bundles. Of course if you are only interested in canceling bundles that 
>> were generated locally this may not be a problem - although I am not 
>> sure what happens if the bundle gets fragmented before sending.
>>
>> I guess it worked with the hacked dtnping because you sent the 
>> dtn_bundle_id_t structure you got from dtn_send straight back to 
>> dtn_cancel in which case the extra fields are already set to zero.
>>
>> The Python interface to dtn_send returns the truncated form as well if I 
>> understand correctly.
>>
>>     
>>>> and Python APIs for bundle_id just take the source string and the
>>>> bundle timestamp as parameters whereas the RPC interface can handle
>>>> a fragment identifier). The applib/APIserver.cc code looks at these
>>>> two unset variables. This is possibly the cause of the problem. The
>>>> DTN server should emit a warning if it can't find the bundle to be
>>>> cancelled - the search parameters derived from the dtn_cancel call
>>>> are printed in the warning - check the 4th, 5th and 6th items
>>>> printed in the warning message. If the 5th or 6th is non-zero then
>>>> the search has looked for a fragment and won't have found it.
>>>>
>>>>         
>>> That rings bells.   The dtnd log did show warnings from the api and
>>> there were a bunch of large numbers in the shown params to dtn_cancel
>>> that I'd   not yet distinguished the meanings of.
>>>
>>>       
>> Check out APIserver.cc and servlib/bundling/gbofid.cc to see what the 
>> output means.
>>
>> As far as I can see the fix is very simple: Modify
>> applib/dtn_api_wrap.cc: *** dtn_api_wrap.cc.old 2010-09-16
>> 22:19:46.000000000 +0100 --- dtn_api_wrap.cc 2010-09-16
>> 22:21:53.000000000 +0100 ***************
>> *** 288,293 ****
>> --- 288,295 ----
>> strcpy(id2.source.uri, id.source.c_str());
>> id2.creation_ts.secs = id.creation_secs;
>> id2.creation_ts.seqno = id.creation_seqno;
>> + id2.frag_offset = 0;
>> + id2.orig_length = 0;
>> return dtn_cancel(h, &id2);
>> }
>>
>> You'll need to install swig to regenerate the Python interface code and 
>> then execute
>> make swig
>> in the applib directory.
>>
>> Then rebuild the Python module and reinstall it.
>> make pythonapi; make pythonapi_install
>>
>> Regards,
>> Elwyn
>>     
>>>       
>>>> I think you have hit a bug here but I haven't experimented yet.
>>>>
>>>>         
>>>       
>>> I guess I deserved to hit a bug as I wondered if it worked :)
>>>
>>> Out of curiosity, I checked out folly.org.uk, it seems I'm just down
>>> the A14 from you, In Bury St Edmunds.
>>>
>>> Cheers,
>>>
>>> Darren
>>>
>>>       
>
>   

From: Darren Long <[email-masked]>
To: Elwyn Davies <[email-masked]>
Date: Fri, 17 Sep 2010 12:51:09 +0100
Cc: [email-masked]
Subject: Re: [dtn-users] dtn_cancel in python
Reply-To: Darren Long <[email-masked]>

Hi,

Yep, I confirm that your proposed fix works for me.

Darren

----- Original message -----
> Hi, Darren.
> 
> A couple of points in line...
> 
> Darren Long wrote:
> > Hi,
> > 
> > Thanks for the pointers.
> > 
> > On 16 Sep 2010, at 18:45, Elwyn Davies wrote:
> > 
> > 
> > > Hi, Darren.
> > > 
> > > I have used the Python wrappers but as it turns out not the
> > > dtn_cancel wrapper.
> > > 
> > > Having had a look through the code, I notice:
> > > 1. The Python test code in applib/python/test-swig-api.py doesn't
> > > exercise dtn_cancel.
> > > 
> > 
> > Actually, I was originally only wondering about whether or not the
> > core bundle cancel functionality worked as I'd never tried it and
> > figured I'd test it quickly by hacking test-swig-api.py to call it. 
> > At least I know know that it works in the core system, even if there
> > is an issue with the python bindings.   Still, it would be good to
> > figure out a fix for it, as I have a couple of minor python projects
> > for dtn on the slow cooker :)
> > 
> I think the fix is extremely simple... more below.
> > 
> > > 2. The dtn_api_wrap.cc (from which I believe the SWIG code is
> > > generated does not explicitly set the frag_offset and orig_length
> > > fields in the bundle_id_t structure which is passed across to the
> > > api server (the C++
> > > 
> > 
> > I keep forgetting that's there's actually a C++ wrapper for a C++ core
> > with a C API, perhaps deliberately.
> > 
> > 
> It's a little strange. The C interface (which stems from using the Sun 
> RPC tools to generate the interface code) uses the full bundle_id_t 
> directly so that in principle fragment bundles can be deleted while the 
> script wrappers use the reduced form that can only handle complete 
> bundles. Of course if you are only interested in canceling bundles that 
> were generated locally this may not be a problem - although I am not 
> sure what happens if the bundle gets fragmented before sending.
> 
> I guess it worked with the hacked dtnping because you sent the 
> dtn_bundle_id_t structure you got from dtn_send straight back to 
> dtn_cancel in which case the extra fields are already set to zero.
> 
> The Python interface to dtn_send returns the truncated form as well if I 
> understand correctly.
> 
> > > and Python APIs for bundle_id just take the source string and the
> > > bundle timestamp as parameters whereas the RPC interface can handle
> > > a fragment identifier). The applib/APIserver.cc code looks at these
> > > two unset variables. This is possibly the cause of the problem. The
> > > DTN server should emit a warning if it can't find the bundle to be
> > > cancelled - the search parameters derived from the dtn_cancel call
> > > are printed in the warning - check the 4th, 5th and 6th items
> > > printed in the warning message. If the 5th or 6th is non-zero then
> > > the search has looked for a fragment and won't have found it.
> > > 
> > 
> > That rings bells.   The dtnd log did show warnings from the api and
> > there were a bunch of large numbers in the shown params to dtn_cancel
> > that I'd   not yet distinguished the meanings of.
> > 
> Check out APIserver.cc and servlib/bundling/gbofid.cc to see what the 
> output means.
> 
> As far as I can see the fix is very simple: Modify
> applib/dtn_api_wrap.cc: *** dtn_api_wrap.cc.old 2010-09-16
> 22:19:46.000000000 +0100 --- dtn_api_wrap.cc 2010-09-16
> 22:21:53.000000000 +0100 ***************
> *** 288,293 ****
> --- 288,295 ----
> strcpy(id2.source.uri, id.source.c_str());
> id2.creation_ts.secs = id.creation_secs;
> id2.creation_ts.seqno = id.creation_seqno;
> + id2.frag_offset = 0;
> + id2.orig_length = 0;
> return dtn_cancel(h, &id2);
> }
> 
> You'll need to install swig to regenerate the Python interface code and 
> then execute
> make swig
> in the applib directory.
> 
> Then rebuild the Python module and reinstall it.
> make pythonapi; make pythonapi_install
> 
> Regards,
> Elwyn
> > 
> > 
> > > I think you have hit a bug here but I haven't experimented yet.
> > > 
> > 
> > 
> 
> > I guess I deserved to hit a bug as I wondered if it worked :)
> > 
> > Out of curiosity, I checked out folly.org.uk, it seems I'm just down
> > the A14 from you, In Bury St Edmunds.
> > 
> > Cheers,
> > 
> > Darren
> > 
> 

Date: Thu, 16 Sep 2010 22:39:26 +0100
From: Elwyn Davies <[email-masked]>
To: Darren Long <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-users] dtn_cancel in python

Hi, Darren.

A couple of points in line...

Darren Long wrote:
> Hi,
>
> Thanks for the pointers.
>
> On 16 Sep 2010, at 18:45, Elwyn Davies wrote:
>
>   
>> Hi, Darren.
>>
>> I have used the Python wrappers but as it turns out not the dtn_cancel wrapper.
>>
>> Having had a look through the code, I notice:
>> 1. The Python test code in applib/python/test-swig-api.py doesn't exercise dtn_cancel.
>>     
>
> Actually, I was originally only wondering about whether or not the core bundle cancel functionality worked as I'd never tried it and figured I'd test it quickly by hacking test-swig-api.py to call it.  At least I know know that it works in the core system, even if there is an issue with the python bindings.  Still, it would be good to figure out a fix for it, as I have a couple of minor python projects for dtn on the slow cooker :)
>   
I think the fix is extremely simple... more below.
>   
>> 2. The dtn_api_wrap.cc (from which I believe the SWIG code is generated does not explicitly set the frag_offset and orig_length fields in the bundle_id_t structure which is passed across to the api server (the C++
>>     
>
> I keep forgetting that's there's actually a C++ wrapper for a C++ core with a C API, perhaps deliberately.
>
>   
It's a little strange. The C interface (which stems from using the Sun 
RPC tools to generate the interface code) uses the full bundle_id_t 
directly so that in principle fragment bundles can be deleted while the 
script wrappers use the reduced form that can only handle complete 
bundles. Of course if you are only interested in canceling bundles that 
were generated locally this may not be a problem - although I am not 
sure what happens if the bundle gets fragmented before sending.

I guess it worked with the hacked dtnping because you sent the 
dtn_bundle_id_t structure you got from dtn_send straight back to 
dtn_cancel in which case the extra fields are already set to zero.

The Python interface to dtn_send returns the truncated form as well if I 
understand correctly.

>> and Python APIs for bundle_id just take the source string and the bundle timestamp as parameters whereas the RPC interface can handle a fragment identifier). The applib/APIserver.cc code looks at these two unset variables. This is possibly the cause of the problem. The DTN server should emit a warning if it can't find the bundle to be cancelled - the search parameters derived from the dtn_cancel call are printed in the warning - check the 4th, 5th and 6th items printed in the warning message. If the 5th or 6th is non-zero then the search has looked for a fragment and won't have found it.
>>     
>
> That rings bells.  The dtnd log did show warnings from the api and there were a bunch of large numbers in the shown params to dtn_cancel that I'd  not yet distinguished the meanings of.
>   
Check out APIserver.cc and servlib/bundling/gbofid.cc to see what the 
output means.

As far as I can see the fix is very simple: Modify applib/dtn_api_wrap.cc:
*** dtn_api_wrap.cc.old 2010-09-16 22:19:46.000000000 +0100
--- dtn_api_wrap.cc 2010-09-16 22:21:53.000000000 +0100
***************
*** 288,293 ****
--- 288,295 ----
strcpy(id2.source.uri, id.source.c_str());
id2.creation_ts.secs = id.creation_secs;
id2.creation_ts.seqno = id.creation_seqno;
+ id2.frag_offset = 0;
+ id2.orig_length = 0;
return dtn_cancel(h, &id2);
}

You'll need to install swig to regenerate the Python interface code and 
then execute
make swig
in the applib directory.

Then rebuild the Python module and reinstall it.
make pythonapi; make pythonapi_install

Regards,
Elwyn
>
>   
>> I think you have hit a bug here but I haven't experimented yet.
>>     
>
>   

> I guess I deserved to hit a bug as I wondered if it worked :)
>
> Out of curiosity, I checked out folly.org.uk, it seems I'm just down the A14 from you, In Bury St Edmunds.
>
> Cheers,
>
> Darren
>   

From: Darren Long <[email-masked]>
Date: Thu, 16 Sep 2010 20:21:29 +0100
To: Elwyn Davies <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-users] dtn_cancel in python

Hi,

Thanks for the pointers.

On 16 Sep 2010, at 18:45, Elwyn Davies wrote:

> Hi, Darren.
> 
> I have used the Python wrappers but as it turns out not the dtn_cancel wrapper.
> 
> Having had a look through the code, I notice:
> 1. The Python test code in applib/python/test-swig-api.py doesn't exercise dtn_cancel.

Actually, I was originally only wondering about whether or not the core bundle cancel functionality worked as I'd never tried it and figured I'd test it quickly by hacking test-swig-api.py to call it.  At least I know know that it works in the core system, even if there is an issue with the python bindings.  Still, it would be good to figure out a fix for it, as I have a couple of minor python projects for dtn on the slow cooker :)

> 2. The dtn_api_wrap.cc (from which I believe the SWIG code is generated does not explicitly set the frag_offset and orig_length fields in the bundle_id_t structure which is passed across to the api server (the C++

I keep forgetting that's there's actually a C++ wrapper for a C++ core with a C API, perhaps deliberately.

> and Python APIs for bundle_id just take the source string and the bundle timestamp as parameters whereas the RPC interface can handle a fragment identifier). The applib/APIserver.cc code looks at these two unset variables. This is possibly the cause of the problem. The DTN server should emit a warning if it can't find the bundle to be cancelled - the search parameters derived from the dtn_cancel call are printed in the warning - check the 4th, 5th and 6th items printed in the warning message. If the 5th or 6th is non-zero then the search has looked for a fragment and won't have found it.

That rings bells.  The dtnd log did show warnings from the api and there were a bunch of large numbers in the shown params to dtn_cancel that I'd  not yet distinguished the meanings of.

> I think you have hit a bug here but I haven't experimented yet.

I guess I deserved to hit a bug as I wondered if it worked :)

Out of curiosity, I checked out folly.org.uk, it seems I'm just down the A14 from you, In Bury St Edmunds.

Cheers,

Darren

Date: Thu, 16 Sep 2010 18:45:50 +0100
From: Elwyn Davies <[email-masked]>
To: Darren Long <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-users] dtn_cancel in python

Hi, Darren.

I have used the Python wrappers but as it turns out not the dtn_cancel 
wrapper.

Having had a look through the code, I notice:
1. The Python test code in applib/python/test-swig-api.py doesn't 
exercise dtn_cancel.
2. The dtn_api_wrap.cc (from which I believe the SWIG code is generated 
does not explicitly set the frag_offset and orig_length fields in the 
bundle_id_t structure which is passed across to the api server (the C++ 
and Python APIs for bundle_id just take the source string and the bundle 
timestamp as parameters whereas the RPC interface can handle a fragment 
identifier). The applib/APIserver.cc code looks at these two unset 
variables. This is possibly the cause of the problem. The DTN server 
should emit a warning if it can't find the bundle to be cancelled - the 
search parameters derived from the dtn_cancel call are printed in the 
warning - check the 4th, 5th and 6th items printed in the warning 
message. If the 5th or 6th is non-zero then the search has looked for a 
fragment and won't have found it. I think you have hit a bug here but I 
haven't experimented yet.

Regards,
Elwyn
Darren Long wrote:
> Hi,
> I seem to be having problems using dtn_cancel using the python API wrappers for DTN2.  I did a quick hack to test the functionality by modifying dtnping to cancel bundles and that seems to work OK.
>
> I wonder if anyone has any ideas on what the issue with dtn_cancel in the python api wrappers might be.
>
> Cheers,
>
> Darren
> _______________________________________________
> dtn-users mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-users
>   

From: Darren Long <[email-masked]>
To: [email-masked]
Date: Thu, 16 Sep 2010 16:04:37 +0100
Subject: [dtn-users] dtn_cancel in python
Reply-To: Darren Long <[email-masked]>

Hi,
I seem to be having problems using dtn_cancel using the python API wrappers for DTN2.  I did a quick hack to test the functionality by modifying dtnping to cancel bundles and that seems to work OK.

I wonder if anyone has any ideas on what the issue with dtn_cancel in the python api wrappers might be.

Cheers,

Darren

From: Elwyn Davies <[email-masked]>
To: [email-masked]
Organization: Folly Consulting
Date: Thu, 16 Sep 2010 14:02:08 +0100
Cc: [email-masked]
Subject: Re: [dtn-users] How to resolve the error of compiling oasys

Hi.

I think the problem is that you are using Xerces v3.x.  Oasys requires
the older v2.8.0 if my experience is anything to go by.  This ought to
be in the docs but isn't.  I don't remember the exact errors but it
certainly wouldn't compile.

Regards,
Elwyn

On Thu, 2010-09-16 at 14:49 +0900, ������ wrote:
> Hello 
> 
> I am trying to build DTN2.
> Before that, I have been compiling oasys-1.4.0 according to the manual
> (http://dtn.sourceforge.net/DTN2/doc/manual/compiling.html#Oasys). 
> 
> 
> First, 
> ./configure --enable-google-profiling --with-google-perftools=../google-
> perftools-1.6  --with-dbver=4.8 --with-xsd-tool=xsd --with-
> python=/usr/local/python
> 
> 
> The result is that : 
> ============================================================================
> ==================================================
> Build options:
>   TARGET is: native
>   CC: gcc
>   CXX: g++
> 
> Options:
>   DEBUG: -g -fno-inline
>   OPTIMIZE:
>   PICFLAGS: -fPIC -DPIC
>   PROFILE:
>   DEFS: -DHAVE_CONFIG_H
>   SYS_CFLAGS: -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
>   INCFLAGS: -I. -I. -I/usr/oasys-1.4.0 -I./ext
>   EXTRA_CFLAGS:
>   LDFLAGS: -L.
> 
> 
> Oasys Configuration:
>   OASYS_INCDIR: /usr/oasys-1.4.0
>   OASYS_LIBDIR: /usr/oasys-1.4.0/lib
>   OASYS_ETCDIR: /usr/oasys-1.4.0
>   OASYS_VERSION: 1.4.0
> 
> External Packages:
>   EXTLIB_CFLAGS: -I/usr/local/BerkeleyDB.4.8/include
>   EXTLIB_LDFLAGS: -ldl -lm  -ltcl8.5 -lexpat -lxerces-c -
> L/usr/local/BerkeleyDB.4.8/lib -ldb-4.8 -lpthread
> ============================================================================
> ==================================================
> 
> Then after running make, I have met the following errors:
> ============================================================================
> ==================================================
> g++ -g -fno-inline  -fPIC -DPIC -MMD -MP -MT "serialize/XMLSerialize.o
> serialize/XMLSerialize.E"  -DHAVE_CONFIG_H -D_LARGEFILE_SOURCE -
> D_FILE_OFFSET_BITS=64 -I. -I. -I/usr/oasys-1.4.0 -I./ext -
> I/usr/local/BerkeleyDB.4.8/include  -Wall -W -Wcast-align  -c
> serialize/XMLSerialize.cc -o serialize/XMLSerialize.o
> serialize/XMLSerialize.cc: In member function ��virtual void
> oasys::XMLMarshal::process(const char*, u_char*, u_int32_t)��:
> serialize/XMLSerialize.cc:114: error: invalid conversion from ��XMLByte**��
> to ��char**��
> serialize/XMLSerialize.cc:114: error:   initializing argument 1 of ��static
> void xercesc_3_1::XMLString::release(char**, xercesc_3_1::MemoryManager*)��
> serialize/XMLSerialize.cc: In member function ��void
> oasys::XMLMarshal::process(const char*, oasys::BufferCarrier<unsigned
> char>*, size_t*)��:
> serialize/XMLSerialize.cc:134: error: invalid conversion from ��XMLByte**��
> to ��char**��
> serialize/XMLSerialize.cc:134: error:   initializing argument 1 of ��static
> void xercesc_3_1::XMLString::release(char**, xercesc_3_1::MemoryManager*)��
> make: *** [serialize/XMLSerialize.o] error 1
> ============================================================================
> ==================================================
> 
> Does any of you have any clue of it? 
> Could you help me to solve it if you have the similar experiences? 
> 
> 
> Best Regards,
> Seung Hun Oh
> 
> 
> _______________________________________________
> dtn-users mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-users

From: =?ks_c_5601-1987?B?v8C9wsjG?= <[email-masked]>
To: <[email-masked]>
Date: Thu, 16 Sep 2010 14:49:55 +0900
Organization: ETRI HRC
Subject: [dtn-users]  How to resolve the error of compiling oasys
Reply-To: [email-masked]

Hello 

I am trying to build DTN2.
Before that, I have been compiling oasys-1.4.0 according to the manual
(http://dtn.sourceforge.net/DTN2/doc/manual/compiling.html#Oasys). 

First, 
./configure --enable-google-profiling --with-google-perftools=../google-
perftools-1.6  --with-dbver=4.8 --with-xsd-tool=xsd --with-
python=/usr/local/python

The result is that : 
============================================================================
==================================================
Build options:
  TARGET is: native
  CC: gcc
  CXX: g++

Options:
  DEBUG: -g -fno-inline
  OPTIMIZE:
  PICFLAGS: -fPIC -DPIC
  PROFILE:
  DEFS: -DHAVE_CONFIG_H
  SYS_CFLAGS: -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
  INCFLAGS: -I. -I. -I/usr/oasys-1.4.0 -I./ext
  EXTRA_CFLAGS:
  LDFLAGS: -L.

Oasys Configuration:
  OASYS_INCDIR: /usr/oasys-1.4.0
  OASYS_LIBDIR: /usr/oasys-1.4.0/lib
  OASYS_ETCDIR: /usr/oasys-1.4.0
  OASYS_VERSION: 1.4.0

External Packages:
  EXTLIB_CFLAGS: -I/usr/local/BerkeleyDB.4.8/include
  EXTLIB_LDFLAGS: -ldl -lm  -ltcl8.5 -lexpat -lxerces-c -
L/usr/local/BerkeleyDB.4.8/lib -ldb-4.8 -lpthread
============================================================================
==================================================

Then after running make, I have met the following errors:
============================================================================
==================================================
g++ -g -fno-inline  -fPIC -DPIC -MMD -MP -MT "serialize/XMLSerialize.o
serialize/XMLSerialize.E"  -DHAVE_CONFIG_H -D_LARGEFILE_SOURCE -
D_FILE_OFFSET_BITS=64 -I. -I. -I/usr/oasys-1.4.0 -I./ext -
I/usr/local/BerkeleyDB.4.8/include  -Wall -W -Wcast-align  -c
serialize/XMLSerialize.cc -o serialize/XMLSerialize.o
serialize/XMLSerialize.cc: In member function ��virtual void
oasys::XMLMarshal::process(const char*, u_char*, u_int32_t)��:
serialize/XMLSerialize.cc:114: error: invalid conversion from ��XMLByte**��
to ��char**��
serialize/XMLSerialize.cc:114: error:   initializing argument 1 of ��static
void xercesc_3_1::XMLString::release(char**, xercesc_3_1::MemoryManager*)��
serialize/XMLSerialize.cc: In member function ��void
oasys::XMLMarshal::process(const char*, oasys::BufferCarrier<unsigned
char>*, size_t*)��:
serialize/XMLSerialize.cc:134: error: invalid conversion from ��XMLByte**��
to ��char**��
serialize/XMLSerialize.cc:134: error:   initializing argument 1 of ��static
void xercesc_3_1::XMLString::release(char**, xercesc_3_1::MemoryManager*)��
make: *** [serialize/XMLSerialize.o] error 1
============================================================================
==================================================

Does any of you have any clue of it? 
Could you help me to solve it if you have the similar experiences? 

Best Regards,
Seung Hun Oh

From: "Burleigh, Scott C (313B)" <[email-masked]>
To: Victor lyamtsev <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 14 Sep 2010 12:59:31 -0700
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-users] eid's dictionary storage format -??

Victor, I think I see a couple of problems.

1.  Each of the strings (scheme names and SSPs) inside the dictionary is supposed to be individually NULL-terminated -- not just a single NULL at the end of the entire byte array.

2.  The only characters in your EIDs that are omitted from representation inside the dictionary are the ':' characters that delimit the scheme names.  You're dropping the "//" characters.

3.  No string is supposed to appear multiple times within the dictionary, but you've got "dtn" in two places.

I would say that your dictionary should instead look like this (with NULLs indicated here by '+' characters):

dtn+//myhost.dtn/sink+//myhost.dtn/source+

...in which case your offsets would be:

Destination scheme name: 0
Destination SSP: 4
Source scheme name: 0
Source SSP: 19

Scott

> -----Original Message-----
> From: [email-masked] [mailto:dtn-users-
> [email-masked]] On Behalf Of Victor lyamtsev
> Sent: Tuesday, September 14, 2010 11:08 AM
> To: [email-masked]
> Subject: [dtn-users] eid's dictionary storage format -??
> 
> Hi,
> I wonder if i can have clarification on how eid's should be stored in
> dictionary byte array.
> For example, when I sent the bundle from "dtn://myhost.dtn/source" to
> ""dtn://myhost.dtn/sink" ( no "report-to", or "custodian schema"
> parts),
> i just appended schema names and SSP's like following:
>  dtnmyhost.dtn/sourcedtnmyhost.dtn/sinkNULL with
>  Destination scheme offset = 0
> Destination SSP offset = 3
> Source scheme offset =  20
> Source SSP offset = 23
> i end up with "invalid endpoint id" error:
>  'tnmyhost.dtn/sinkdtnmyhost.dtn:tnmyhost.dtn/sinkdtnmyhost.dtn':
> scheme 'tnmyhost.dtn/sinkdtnmyhost.dtn' offset 1/40 ssp
> 'tnmyhost.dtn/sinkmyhost.dtn' offset 1/40
> Any idea how this to be done ?
> Thank you,
> -V
> _______________________________________________
> dtn-users mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-users

Date: Tue, 14 Sep 2010 14:07:56 -0400
From: Victor lyamtsev <[email-masked]>
To: [email-masked]
Subject: [dtn-users] eid's dictionary storage format -??

Hi,
I wonder if i can have clarification on how eid's should be stored in
dictionary byte array.
For example, when I sent the bundle from "dtn://myhost.dtn/source" to
""dtn://myhost.dtn/sink" ( no "report-to", or "custodian schema"
parts),
i just appended schema names and SSP's like following:
 dtnmyhost.dtn/sourcedtnmyhost.dtn/sinkNULL with
 Destination scheme offset = 0
Destination SSP offset = 3
Source scheme offset =  20
Source SSP offset = 23
i end up with "invalid endpoint id" error:
 'tnmyhost.dtn/sinkdtnmyhost.dtn:tnmyhost.dtn/sinkdtnmyhost.dtn':
scheme 'tnmyhost.dtn/sinkdtnmyhost.dtn' offset 1/40 ssp
'tnmyhost.dtn/sinkmyhost.dtn' offset 1/40
Any idea how this to be done ?
Thank you,
-V

Date: Sun, 12 Sep 2010 06:17:22 -0400
From: Victor lyamtsev <[email-masked]>
To: Elwyn Davies <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-users] rfc5050 questions

Are dictionary byte array and payload SDNV encoded?
Does it say they are? No! And it wouldn't make much sense since they
aren't numerics or flags, and they both have explicit length fields.
Just apply logic... SDNVs are used so that you don't need an explicit
length field!

Payload does have block length but not the explicit field length...

Anyway, i originally thought that the purpose of sdnv is to make the
process of encoding/ decoding independent of the endianness. In that
context sdnv encoding of character fields would also make sense.
Thank you for your comments.
-V

On Sat, Sep 11, 2010 at 10:13 PM, Elwyn Davies <[email-masked]> wrote:
> Victor lyamtsev wrote:
>>
>> Hi All,
>> Can I have some clarifications ?
>> "Block Length: � The Block Length field is an SDNV that contains the
>> �aggregate length of all remaining fields of the block"
>>
>> "Remaining after proc. flags" meaning is unclear: does that include
>> length field itself, or everything beginning from destination scheme
>> offset?
>>
>
> It isn't technically unclear - 'remaining' implies fields after this one,
> but, yes, it probably ought to be more explicit.
>>
>> Is the length expressed in bytes ?
>>
>
> Yes all lengths in RFC 5050 are in octets - and no it doesn't say that. [Had
> I done the gen-art review of this draft neither of these would have got past
> me.. but that is with 20-20 hindsight - and I didn't review this draft back
> then, :-) ]
>>
>> Dictionary length: again, is that byte value?
>>
>
> yes.. see previous comment
>>
>> If every field in primary block is variable length, where's the offset
>> to dictionary byte array? Shall it be assumed that Destination scheme
>> is the first in dictionary and use that value?
>>
>
> Think! The whole point of SDNVs is that they don't need an explicit length
> field. Thus
> (1) the start of the dictionary byte array is wherever you get to when you
> have decoded all the previous SDNV fields.
> (2) There is no assumption about the location of any of the various EIDs in
> the dictionary.
> (3) It wouldn't help your (alleged) issue because as it says earlier in the
> spec the offsets are (implicitly relative) offsets within the dictionary
> byte array, NOT offsets from the block start.
>>
>> Are dictionary byte array and payload SDNV encoded?
>>
>
> Does it say they are? No! And it wouldn't make much sense since they aren't
> numerics or flags, and they both have explicit length fields. Just apply
> logic... SDNVs are used so that you don't need an explicit length field!
>
> Now its well past my bedtime!
>
> Regards,
> Elwyn
>
> PS
> The DTN2 code is a good guide if you find the spec obscure.. the functional
> spec will help you find the relevant piece of code.
>
> /E
>
>>
>> Thank you,
>> -V
>> _______________________________________________
>> dtn-users mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-users
>>
>
>

Date: Sun, 12 Sep 2010 03:13:27 +0100
From: Elwyn Davies <[email-masked]>
To: Victor lyamtsev <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-users] rfc5050 questions

Victor lyamtsev wrote:
> Hi All,
> Can I have some clarifications ?
> "Block Length:   The Block Length field is an SDNV that contains the
>  aggregate length of all remaining fields of the block"
>
> "Remaining after proc. flags" meaning is unclear: does that include
> length field itself, or everything beginning from destination scheme
> offset?
>   
It isn't technically unclear - 'remaining' implies fields after this 
one, but, yes, it probably ought to be more explicit.
> Is the length expressed in bytes ?
>   
Yes all lengths in RFC 5050 are in octets - and no it doesn't say that. 
[Had I done the gen-art review of this draft neither of these would have 
got past me.. but that is with 20-20 hindsight - and I didn't review 
this draft back then, :-) ]
> Dictionary length: again, is that byte value?
>   
yes.. see previous comment
> If every field in primary block is variable length, where's the offset
> to dictionary byte array? Shall it be assumed that Destination scheme
> is the first in dictionary and use that value?
>   
Think! The whole point of SDNVs is that they don't need an explicit 
length field. Thus
(1) the start of the dictionary byte array is wherever you get to when 
you have decoded all the previous SDNV fields.
(2) There is no assumption about the location of any of the various EIDs 
in the dictionary.
(3) It wouldn't help your (alleged) issue because as it says earlier in 
the spec the offsets are (implicitly relative) offsets within the 
dictionary byte array, NOT offsets from the block start.
> Are dictionary byte array and payload SDNV encoded?
>   
Does it say they are? No! And it wouldn't make much sense since they 
aren't numerics or flags, and they both have explicit length fields. 
Just apply logic... SDNVs are used so that you don't need an explicit 
length field!

Now its well past my bedtime!

Regards,
Elwyn

PS
The DTN2 code is a good guide if you find the spec obscure.. the 
functional spec will help you find the relevant piece of code.

/E

>
> Thank you,
> -V
> _______________________________________________
> dtn-users mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-users
>   

Date: Sat, 11 Sep 2010 14:47:22 -0400
From: Victor lyamtsev <[email-masked]>
To: [email-masked]
Subject: [dtn-users] rfc5050 questions

Hi All,
Can I have some clarifications ?
"Block Length:   The Block Length field is an SDNV that contains the
 aggregate length of all remaining fields of the block"

"Remaining after proc. flags" meaning is unclear: does that include
length field itself, or everything beginning from destination scheme
offset?
Is the length expressed in bytes ?

Dictionary length: again, is that byte value?

If every field in primary block is variable length, where's the offset
to dictionary byte array? Shall it be assumed that Destination scheme
is the first in dictionary and use that value?

Are dictionary byte array and payload SDNV encoded?

Thank you,
-V

Date: Mon, 06 Sep 2010 23:01:17 +0100
From: Elwyn Davies <[email-masked]>
To: Victor lyamtsev <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-users] dtn-users Digest, Vol 35, Issue 3

Hi.

I take it you meant you were trying to emulate the TCP convergence 
layer. You've got a good deal of work to do to send a bundle using the 
TCP convergence layer beyond encoding the bundle.  There is a transport 
layer to consider and some parameter negotiation before actual bundle 
transfer can take place. I'm not sure why you want to do this (apart 
from basic testing)  but you might be better off trying to send a 
(small) bundle using the UDP convergence layer.  This is very trivial 
and requires that the bundle fits into one packet - so all the transport 
layer stuff goes away.  Otherwise you need to read the TCP convergence 
layer draft - the 'magic number' error is a transport problem not a 
bundle problem.

Personally i'd say if you want to play on just one node you might be 
better off running two DTN daemons using different port numbers for the 
various interfaces.  And  for the simplest tests you can just use a 
single daemon!  Then dtnsend and dtnrecv can be used to inject/receive 
bundles.

Regards,
Elwyn
Victor lyamtsev wrote:
> Thanks for advise,
> I made up test implementation of bundle protocol, encoding "hello
> world" bundle with hardcoded eid etc. and tried to send it over tcp to
> port 4556 of dtn2 ( it configured to work with tcl only). I can see
> error message from dtn2: "missing magic number". Any idea what that
> magic number is - i didn't see anything about it in rfc5050 spec.
> Would this be a valid method of testing, or does the bundle also have
> to be serialized with oasys lib?
> ION would be the good candidate for my purpose, one problem with it is
> that it requires dozen of other processes to run every time to
> configure the node. Also, to make it interoperable with dtn2 it
> requires "proxy" exe to be linked with dtn2, e.g. it requires oasys
> and libstdc++ shared libs to be installed on the target...
> "Bitzalia" seems to be a nice job for the Android OS only.  From my
> brief  stub on it i ended up with impression that it would be more
> time efficient to write own bundle implementation than to port google
> java to any ther other java .
> Thanks again,
> -V
>
>
> On Mon, Sep 6, 2010 at 3:00 PM,
> <[email-masked]> wrote:
>   
>> Send dtn-users mailing list submissions to
>>        [email-masked]
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>        http://maillists.intel-research.net/mailman/listinfo/dtn-users
>> or, via email, send a message with subject or body 'help' to
>>        [email-masked]
>>
>> You can reach the person managing the list at
>>        [email-masked]
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of dtn-users digest..."
>>
>>
>> Today's Topics:
>>
>>   1. dtn2 and dtn1 interoperability -?? (Victor lyamtsev)
>>   2. Re: dtn2 and dtn1 interoperability -?? (Scott, Keith L.)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Mon, 6 Sep 2010 09:57:52 -0400
>> From: Victor lyamtsev <[email-masked]>
>> Subject: [dtn-users] dtn2 and dtn1 interoperability -??
>> To: [email-masked]
>> Message-ID:
>>        <[email-masked]>
>> Content-Type: text/plain; charset=ISO-8859-1
>>
>> Hi,
>> I've been trying to send bundle from old DTN1 node ( release 0.1)  to
>> DTN2 ( with TCL). My question:
>> would that be possible at all?
>> it seems from brief examination, that dtn1 is not even using SDNV
>> encoding, did it come later?
>>
>> The reason I am looking at dtn1 at all:  i have to forward bundles
>> from "thin client" that doesn't have resources to run DTN2, but dtn1
>> runs on it.
>> Thanks,
>> -V
>>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Mon, 6 Sep 2010 11:04:32 -0400
>> From: "Scott, Keith L." <[email-masked]>
>> Subject: Re: [dtn-users] dtn2 and dtn1 interoperability -??
>> To: Victor lyamtsev <[email-masked]>,
>>        "[email-masked]"
>>        <[email-masked]>
>> Message-ID:
>>        <[email-masked]>
>> Content-Type: text/plain; charset="us-ascii"
>>
>> That's correct; DTN1 uses a different header encoding.  There are other DTN2 implementations that might be better suited to your environment.  The NASA ION implementation (https://ion.ocp.ohiou.edu/) is designed to run on resource-constrained spacecraft and is RFC5050-conformant (and so interoperates with DTN2).  The dtnrg website lists a few other implementations.  There was at one time a Python implementation (ok, maybe not light) that would need some work to interoperate with DTN2 (I think).  There's also the bytewalla (Java) implementation for Android that interoperates.
>>
>>                --keith
>>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of Victor lyamtsev
>> Sent: Monday, September 06, 2010 9:58 AM
>> To: [email-masked]
>> Subject: [dtn-users] dtn2 and dtn1 interoperability -??
>>
>> Hi,
>> I've been trying to send bundle from old DTN1 node ( release 0.1)  to
>> DTN2 ( with TCL). My question:
>> would that be possible at all?
>> it seems from brief examination, that dtn1 is not even using SDNV
>> encoding, did it come later?
>>
>> The reason I am looking at dtn1 at all:  i have to forward bundles
>> from "thin client" that doesn't have resources to run DTN2, but dtn1
>> runs on it.
>> Thanks,
>> -V
>> _______________________________________________
>> dtn-users mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-users
>>
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> dtn-users mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-users
>>
>>
>> End of dtn-users Digest, Vol 35, Issue 3
>> ****************************************
>>
>>     
>
> _______________________________________________
> dtn-users mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-users
>   

From: Darren Long <[email-masked]>
Date: Mon, 06 Sep 2010 22:57:32 +0100
To: Victor lyamtsev <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-users] dtn-users Digest, Vol 35, Issue 3

The magic number is part of the TCP Convergence Layer Protocol (TCP-CLP).  There's an old Internet Draft that describes it:

https://datatracker.ietf.org/doc/draft-irtf-dtnrg-tcp-clayer/

It describes how contact headers are exchanged, and how bundles are segmented for streaming over TCP connections.

Hope this helps,

Darren

On 6 Sep 2010, at 22:39, Victor lyamtsev wrote:

> Thanks for advise,
> I made up test implementation of bundle protocol, encoding "hello
> world" bundle with hardcoded eid etc. and tried to send it over tcp to
> port 4556 of dtn2 ( it configured to work with tcl only). I can see
> error message from dtn2: "missing magic number". Any idea what that
> magic number is - i didn't see anything about it in rfc5050 spec.
> Would this be a valid method of testing, or does the bundle also have
> to be serialized with oasys lib?
> ION would be the good candidate for my purpose, one problem with it is
> that it requires dozen of other processes to run every time to
> configure the node. Also, to make it interoperable with dtn2 it
> requires "proxy" exe to be linked with dtn2, e.g. it requires oasys
> and libstdc++ shared libs to be installed on the target...
> "Bitzalia" seems to be a nice job for the Android OS only.  From my
> brief  stub on it i ended up with impression that it would be more
> time efficient to write own bundle implementation than to port google
> java to any ther other java .
> Thanks again,
> -V
> 
> 
> On Mon, Sep 6, 2010 at 3:00 PM,
> <[email-masked]> wrote:
>> Send dtn-users mailing list submissions to
>>        [email-masked]
>> 
>> To subscribe or unsubscribe via the World Wide Web, visit
>>        http://maillists.intel-research.net/mailman/listinfo/dtn-users
>> or, via email, send a message with subject or body 'help' to
>>        [email-masked]
>> 
>> You can reach the person managing the list at
>>        [email-masked]
>> 
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of dtn-users digest..."
>> 
>> 
>> Today's Topics:
>> 
>>   1. dtn2 and dtn1 interoperability -?? (Victor lyamtsev)
>>   2. Re: dtn2 and dtn1 interoperability -?? (Scott, Keith L.)
>> 
>> 
>> ----------------------------------------------------------------------
>> 
>> Message: 1
>> Date: Mon, 6 Sep 2010 09:57:52 -0400
>> From: Victor lyamtsev <[email-masked]>
>> Subject: [dtn-users] dtn2 and dtn1 interoperability -??
>> To: [email-masked]
>> Message-ID:
>>        <[email-masked]>
>> Content-Type: text/plain; charset=ISO-8859-1
>> 
>> Hi,
>> I've been trying to send bundle from old DTN1 node ( release 0.1)  to
>> DTN2 ( with TCL). My question:
>> would that be possible at all?
>> it seems from brief examination, that dtn1 is not even using SDNV
>> encoding, did it come later?
>> 
>> The reason I am looking at dtn1 at all:  i have to forward bundles
>> from "thin client" that doesn't have resources to run DTN2, but dtn1
>> runs on it.
>> Thanks,
>> -V
>> 
>> 
>> ------------------------------
>> 
>> Message: 2
>> Date: Mon, 6 Sep 2010 11:04:32 -0400
>> From: "Scott, Keith L." <[email-masked]>
>> Subject: Re: [dtn-users] dtn2 and dtn1 interoperability -??
>> To: Victor lyamtsev <[email-masked]>,
>>        "[email-masked]"
>>        <[email-masked]>
>> Message-ID:
>>        <[email-masked]>
>> Content-Type: text/plain; charset="us-ascii"
>> 
>> That's correct; DTN1 uses a different header encoding.  There are other DTN2 implementations that might be better suited to your environment.  The NASA ION implementation (https://ion.ocp.ohiou.edu/) is designed to run on resource-constrained spacecraft and is RFC5050-conformant (and so interoperates with DTN2).  The dtnrg website lists a few other implementations.  There was at one time a Python implementation (ok, maybe not light) that would need some work to interoperate with DTN2 (I think).  There's also the bytewalla (Java) implementation for Android that interoperates.
>> 
>>                --keith
>> 
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of Victor lyamtsev
>> Sent: Monday, September 06, 2010 9:58 AM
>> To: [email-masked]
>> Subject: [dtn-users] dtn2 and dtn1 interoperability -??
>> 
>> Hi,
>> I've been trying to send bundle from old DTN1 node ( release 0.1)  to
>> DTN2 ( with TCL). My question:
>> would that be possible at all?
>> it seems from brief examination, that dtn1 is not even using SDNV
>> encoding, did it come later?
>> 
>> The reason I am looking at dtn1 at all:  i have to forward bundles
>> from "thin client" that doesn't have resources to run DTN2, but dtn1
>> runs on it.
>> Thanks,
>> -V
>> _______________________________________________
>> dtn-users mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-users
>> 
>> 
>> 
>> ------------------------------
>> 
>> _______________________________________________
>> dtn-users mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-users
>> 
>> 
>> End of dtn-users Digest, Vol 35, Issue 3
>> ****************************************
>> 
> 
> _______________________________________________
> dtn-users mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-users

Date: Mon, 6 Sep 2010 17:39:43 -0400
From: Victor lyamtsev <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-users] dtn-users Digest, Vol 35, Issue 3

Thanks for advise,
I made up test implementation of bundle protocol, encoding "hello
world" bundle with hardcoded eid etc. and tried to send it over tcp to
port 4556 of dtn2 ( it configured to work with tcl only). I can see
error message from dtn2: "missing magic number". Any idea what that
magic number is - i didn't see anything about it in rfc5050 spec.
Would this be a valid method of testing, or does the bundle also have
to be serialized with oasys lib?
ION would be the good candidate for my purpose, one problem with it is
that it requires dozen of other processes to run every time to
configure the node. Also, to make it interoperable with dtn2 it
requires "proxy" exe to be linked with dtn2, e.g. it requires oasys
and libstdc++ shared libs to be installed on the target...
"Bitzalia" seems to be a nice job for the Android OS only.  From my
brief  stub on it i ended up with impression that it would be more
time efficient to write own bundle implementation than to port google
java to any ther other java .
Thanks again,
-V

On Mon, Sep 6, 2010 at 3:00 PM,
<[email-masked]> wrote:
> Send dtn-users mailing list submissions to
> � � � �[email-masked]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> � � � �http://maillists.intel-research.net/mailman/listinfo/dtn-users
> or, via email, send a message with subject or body 'help' to
> � � � �[email-masked]
>
> You can reach the person managing the list at
> � � � �[email-masked]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of dtn-users digest..."
>
>
> Today's Topics:
>
> � 1. dtn2 and dtn1 interoperability -?? (Victor lyamtsev)
> � 2. Re: dtn2 and dtn1 interoperability -?? (Scott, Keith L.)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 6 Sep 2010 09:57:52 -0400
> From: Victor lyamtsev <[email-masked]>
> Subject: [dtn-users] dtn2 and dtn1 interoperability -??
> To: [email-masked]
> Message-ID:
> � � � �<[email-masked]>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi,
> I've been trying to send bundle from old DTN1 node ( release 0.1) �to
> DTN2 ( with TCL). My question:
> would that be possible at all?
> it seems from brief examination, that dtn1 is not even using SDNV
> encoding, did it come later?
>
> The reason I am looking at dtn1 at all: �i have to forward bundles
> from "thin client" that doesn't have resources to run DTN2, but dtn1
> runs on it.
> Thanks,
> -V
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 6 Sep 2010 11:04:32 -0400
> From: "Scott, Keith L." <[email-masked]>
> Subject: Re: [dtn-users] dtn2 and dtn1 interoperability -??
> To: Victor lyamtsev <[email-masked]>,
> � � � �"[email-masked]"
> � � � �<[email-masked]>
> Message-ID:
> � � � �<[email-masked]>
> Content-Type: text/plain; charset="us-ascii"
>
> That's correct; DTN1 uses a different header encoding. �There are other DTN2 implementations that might be better suited to your environment. �The NASA ION implementation (https://ion.ocp.ohiou.edu/) is designed to run on resource-constrained spacecraft and is RFC5050-conformant (and so interoperates with DTN2). �The dtnrg website lists a few other implementations. �There was at one time a Python implementation (ok, maybe not light) that would need some work to interoperate with DTN2 (I think). �There's also the bytewalla (Java) implementation for Android that interoperates.
>
> � � � � � � � �--keith
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Victor lyamtsev
> Sent: Monday, September 06, 2010 9:58 AM
> To: [email-masked]
> Subject: [dtn-users] dtn2 and dtn1 interoperability -??
>
> Hi,
> I've been trying to send bundle from old DTN1 node ( release 0.1) �to
> DTN2 ( with TCL). My question:
> would that be possible at all?
> it seems from brief examination, that dtn1 is not even using SDNV
> encoding, did it come later?
>
> The reason I am looking at dtn1 at all: �i have to forward bundles
> from "thin client" that doesn't have resources to run DTN2, but dtn1
> runs on it.
> Thanks,
> -V
> _______________________________________________
> dtn-users mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-users
>
>
>
> ------------------------------
>
> _______________________________________________
> dtn-users mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-users
>
>
> End of dtn-users Digest, Vol 35, Issue 3
> ****************************************
>

From: "Scott, Keith L." <[email-masked]>
To: Victor lyamtsev <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 6 Sep 2010 11:04:32 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-users] dtn2 and dtn1 interoperability -??

That's correct; DTN1 uses a different header encoding.  There are other DTN2 implementations that might be better suited to your environment.  The NASA ION implementation (https://ion.ocp.ohiou.edu/) is designed to run on resource-constrained spacecraft and is RFC5050-conformant (and so interoperates with DTN2).  The dtnrg website lists a few other implementations.  There was at one time a Python implementation (ok, maybe not light) that would need some work to interoperate with DTN2 (I think).  There's also the bytewalla (Java) implementation for Android that interoperates.

		--keith

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Victor lyamtsev
Sent: Monday, September 06, 2010 9:58 AM
To: [email-masked]
Subject: [dtn-users] dtn2 and dtn1 interoperability -??

Hi,
I've been trying to send bundle from old DTN1 node ( release 0.1)  to
DTN2 ( with TCL). My question:
would that be possible at all?
it seems from brief examination, that dtn1 is not even using SDNV
encoding, did it come later?

The reason I am looking at dtn1 at all:  i have to forward bundles
from "thin client" that doesn't have resources to run DTN2, but dtn1
runs on it.
Thanks,
-V
_______________________________________________
dtn-users mailing list
[email-masked]
http://maillists.intel-research.net/mailman/listinfo/dtn-users

Date: Mon, 6 Sep 2010 09:57:52 -0400
From: Victor lyamtsev <[email-masked]>
To: [email-masked]
Subject: [dtn-users] dtn2 and dtn1 interoperability -??

Hi,
I've been trying to send bundle from old DTN1 node ( release 0.1)  to
DTN2 ( with TCL). My question:
would that be possible at all?
it seems from brief examination, that dtn1 is not even using SDNV
encoding, did it come later?

The reason I am looking at dtn1 at all:  i have to forward bundles
from "thin client" that doesn't have resources to run DTN2, but dtn1
runs on it.
Thanks,
-V

Date: Thu, 2 Sep 2010 08:51:57 -0400
From: Victor lyamtsev <[email-masked]>
To: Elwyn Davies <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-users] dtn2 cross compilation problem

Yes.  Change the storage setup in dtn.conf:
> storage set type filesysdb
Thank you, that is good to know... If you run it on OpenWRT, did you
also remove TCL dependency?

On Wed, Sep 1, 2010 at 7:44 PM, Elwyn Davies <[email-masked]> wrote:
> Victor lyamtsev wrote:
>>
>> No worries, i managed to fix it . All i needed was to add path to TCL
>> libs into LDFLAGS in config script.
>> Another question: can i run bundle transfer without db support? e.g.
>> can dtn2 be used with file io as bundle storage vs. berkley db?
>>
>
> Yes. �Change the storage setup in dtn.conf:
> storage set type filesysdb
>
> See the (more or less) complete command directory in the DTN2 Functional
> Spec
> http://www.n4c.eu/Download/n4c-wp2-023-dtn-infrastructure-fs-12.pdf
> Section 411.7.15 has the Storage Commands.
>
> I don't have any experience of the file system storage system, but it
> allegedly works (we tried it on an OpenWRT build last year before getting
> the Berkeley DB installed.)
> /Elwyn
>
>> On Wed, Sep 1, 2010 at 4:56 PM, Darren Long <[email-masked]> wrote:
>>
>>>
>>> Hi,
>>>
>>> No really sensible suggestions from me, but I suppose a native build on
>>> your arm device is out of the question is it?
>>>
>>> I remember my NSLU2 (running Debian) taking about 12 hours, until I got
>>> distcc working with a cross compiler. �My sheevaplug (again running Debian)
>>> builds oasys and DTN2 in about 30 mins, IIRC.
>>>
>>> Darren
>>>
>>> On 1 Sep 2010, at 21:19, Victor lyamtsev wrote:
>>>
>>>
>>>>
>>>> I've tried that as well - no luck....
>>>>
>>>> On Wed, Sep 1, 2010 at 2:02 PM, Elwyn Davies <[email-masked]>
>>>> wrote:
>>>>
>>>>>
>>>>> �On 01/09/2010 18:41, Victor lyamtsev wrote:
>>>>>
>>>>>>
>>>>>> Hi Elwyn,
>>>>>> Again, I am working with ARM cross compilation toolchain on Intel host
>>>>>> What use can it be if add ARM binaries to load path for Intel linker?
>>>>>> I am looking how to add them for "arm-linux-ld", from command line.
>>>>>> Any idea how i can do that?
>>>>>> Thanks,
>>>>>> -V
>>>>>>
>>>>>
>>>>> Hi.
>>>>>
>>>>> You could try
>>>>> --extra-ld-flags="-L/home/arm/tcl-8.4 -L/home/arm/oasys/lib"
>>>>>
>>>>> That will tell ld to search those directories.
>>>>>
>>>>> /E
>>>>>
>>>>>>
>>>>>> On Wed, Sep 1, 2010 at 1:10 PM, Elwyn Davies <[email-masked]>
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>> �Hi.
>>>>>>>
>>>>>>> Have you told the loader (/bin/ld) that it should look in /home/arm
>>>>>>> tcl-8.4 ..
>>>>>>> and for that matter /home/arm/oasys/lib?
>>>>>>>
>>>>>>> The loader has a cache of places to look for libraries which is
>>>>>>> maintained by
>>>>>>> ldconfig (usually /sbin/ldconfig). �If the two directories are not in
>>>>>>> ld's cache
>>>>>>> then you will get the symptoms described. �make install doesn't do
>>>>>>> the cache
>>>>>>> update for you (if I remember correctly).
>>>>>>>
>>>>>>> ldconfig -p will print a list of currently known directories and the
>>>>>>> libraries
>>>>>>> it has seen there so you can check.
>>>>>>>
>>>>>>> You can add new directories with
>>>>>>> ldconfig /home/arm/tcl-8.4 ....
>>>>>>>
>>>>>>> or you can add the directory names to /etc/ld.so.config with your
>>>>>>> favourite text
>>>>>>> editor.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Elwyn
>>>>>>>
>>>>>>>
>>>>>>> On 01/09/2010 17:39, Victor lyamtsev wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> Hello,
>>>>>>>> I am trying to cross compile DTN2 on i686 Linux ( Ubuntu 8.4) for
>>>>>>>> ARM...
>>>>>>>> I managed to build tcl 8.4 and oasys 1.3 shared libs.
>>>>>>>> /home/arm/tcl-8.4 - libtcl8.4.so �libtclstub8.4.a
>>>>>>>> /home/arm/oasys/lib - liboasys-1.3.0.so �liboasyscompat.so
>>>>>>>> liboasyscompat-1.3.0.so �liboasys.so
>>>>>>>>
>>>>>>>> When i run dtn2 configuration script:
>>>>>>>> ./configure --host=arm-linux --build=i686-pc-linux-gnu
>>>>>>>> --with-tcl=/home/arm/tcl-8.4 -with-oasys=/home/arm/oasys
>>>>>>>> --prefix=/home/build/dtn2
>>>>>>>> I see the the following problem in log:
>>>>>>>> bin/ld: warning: libtcl8.4.so, needed by
>>>>>>>> /home/arm/oasys/lib/liboasys-1.3.0.so, not found (try using -rpath
>>>>>>>> or
>>>>>>>> -rpath-link)
>>>>>>>> /home/arm/oasys/lib/liboasys-1.3.0.so: undefined reference to
>>>>>>>> `Tcl_DeleteInterp'
>>>>>>>> ...
>>>>>>>>
>>>>>>>> So, it seems as problem is with linker not able to resolve
>>>>>>>> references
>>>>>>>> to tcl shared libs for oasys.
>>>>>>>>
>>>>>>>> I've tried setting of RPATH env variable, or using
>>>>>>>> --with-extra-ldflags="rpath=/home/arm/tcl-8.4/lib" Nothing seems to
>>>>>>>> work. �Any advice how to resolve this problem?
>>>>>>>> Thank you,
>>>>>>>> -V
>>>>>>>> _______________________________________________
>>>>>>>> dtn-users mailing list
>>>>>>>> [email-masked]
>>>>>>>> http://maillists.intel-research.net/mailman/listinfo/dtn-users
>>>>>>>>
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> dtn-users mailing list
>>>> [email-masked]
>>>> http://maillists.intel-research.net/mailman/listinfo/dtn-users
>>>>
>>>
>>>
>
>

Date: Thu, 02 Sep 2010 00:44:55 +0100
From: Elwyn Davies <[email-masked]>
To: Victor lyamtsev <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-users] dtn2 cross compilation problem

Victor lyamtsev wrote:
> No worries, i managed to fix it . All i needed was to add path to TCL
> libs into LDFLAGS in config script.
> Another question: can i run bundle transfer without db support? e.g.
> can dtn2 be used with file io as bundle storage vs. berkley db?
>   
Yes.  Change the storage setup in dtn.conf:
storage set type filesysdb

See the (more or less) complete command directory in the DTN2 Functional 
Spec
http://www.n4c.eu/Download/n4c-wp2-023-dtn-infrastructure-fs-12.pdf
Section 411.7.15 has the Storage Commands.

I don't have any experience of the file system storage system, but it 
allegedly works (we tried it on an OpenWRT build last year before 
getting the Berkeley DB installed.)
/Elwyn
 
> On Wed, Sep 1, 2010 at 4:56 PM, Darren Long <[email-masked]> wrote:
>   
>> Hi,
>>
>> No really sensible suggestions from me, but I suppose a native build on your arm device is out of the question is it?
>>
>> I remember my NSLU2 (running Debian) taking about 12 hours, until I got distcc working with a cross compiler.  My sheevaplug (again running Debian) builds oasys and DTN2 in about 30 mins, IIRC.
>>
>> Darren
>>
>> On 1 Sep 2010, at 21:19, Victor lyamtsev wrote:
>>
>>     
>>> I've tried that as well - no luck....
>>>
>>> On Wed, Sep 1, 2010 at 2:02 PM, Elwyn Davies <[email-masked]> wrote:
>>>       
>>>>  On 01/09/2010 18:41, Victor lyamtsev wrote:
>>>>         
>>>>> Hi Elwyn,
>>>>> Again, I am working with ARM cross compilation toolchain on Intel host
>>>>> What use can it be if add ARM binaries to load path for Intel linker?
>>>>> I am looking how to add them for "arm-linux-ld", from command line.
>>>>> Any idea how i can do that?
>>>>> Thanks,
>>>>> -V
>>>>>           
>>>> Hi.
>>>>
>>>> You could try
>>>> --extra-ld-flags="-L/home/arm/tcl-8.4 -L/home/arm/oasys/lib"
>>>>
>>>> That will tell ld to search those directories.
>>>>
>>>> /E
>>>>         
>>>>> On Wed, Sep 1, 2010 at 1:10 PM, Elwyn Davies <[email-masked]> wrote:
>>>>>           
>>>>>>  Hi.
>>>>>>
>>>>>> Have you told the loader (/bin/ld) that it should look in /home/arm tcl-8.4 ..
>>>>>> and for that matter /home/arm/oasys/lib?
>>>>>>
>>>>>> The loader has a cache of places to look for libraries which is maintained by
>>>>>> ldconfig (usually /sbin/ldconfig).  If the two directories are not in ld's cache
>>>>>> then you will get the symptoms described.  make install doesn't do the cache
>>>>>> update for you (if I remember correctly).
>>>>>>
>>>>>> ldconfig -p will print a list of currently known directories and the libraries
>>>>>> it has seen there so you can check.
>>>>>>
>>>>>> You can add new directories with
>>>>>> ldconfig /home/arm/tcl-8.4 ....
>>>>>>
>>>>>> or you can add the directory names to /etc/ld.so.config with your favourite text
>>>>>> editor.
>>>>>>
>>>>>> Regards,
>>>>>> Elwyn
>>>>>>
>>>>>>
>>>>>> On 01/09/2010 17:39, Victor lyamtsev wrote:
>>>>>>             
>>>>>>> Hello,
>>>>>>> I am trying to cross compile DTN2 on i686 Linux ( Ubuntu 8.4) for ARM...
>>>>>>> I managed to build tcl 8.4 and oasys 1.3 shared libs.
>>>>>>> /home/arm/tcl-8.4 - libtcl8.4.so  libtclstub8.4.a
>>>>>>> /home/arm/oasys/lib - liboasys-1.3.0.so  liboasyscompat.so
>>>>>>> liboasyscompat-1.3.0.so  liboasys.so
>>>>>>>
>>>>>>> When i run dtn2 configuration script:
>>>>>>> ./configure --host=arm-linux --build=i686-pc-linux-gnu
>>>>>>> --with-tcl=/home/arm/tcl-8.4 -with-oasys=/home/arm/oasys
>>>>>>> --prefix=/home/build/dtn2
>>>>>>> I see the the following problem in log:
>>>>>>> bin/ld: warning: libtcl8.4.so, needed by
>>>>>>> /home/arm/oasys/lib/liboasys-1.3.0.so, not found (try using -rpath or
>>>>>>> -rpath-link)
>>>>>>> /home/arm/oasys/lib/liboasys-1.3.0.so: undefined reference to `Tcl_DeleteInterp'
>>>>>>> ...
>>>>>>>
>>>>>>> So, it seems as problem is with linker not able to resolve references
>>>>>>> to tcl shared libs for oasys.
>>>>>>>
>>>>>>> I've tried setting of RPATH env variable, or using
>>>>>>> --with-extra-ldflags="rpath=/home/arm/tcl-8.4/lib" Nothing seems to
>>>>>>> work.  Any advice how to resolve this problem?
>>>>>>> Thank you,
>>>>>>> -V
>>>>>>> _______________________________________________
>>>>>>> dtn-users mailing list
>>>>>>> [email-masked]
>>>>>>> http://maillists.intel-research.net/mailman/listinfo/dtn-users
>>>>>>>               
>>>>         
>>> _______________________________________________
>>> dtn-users mailing list
>>> [email-masked]
>>> http://maillists.intel-research.net/mailman/listinfo/dtn-users
>>>       
>>     

Date: Wed, 1 Sep 2010 18:12:51 -0400
From: Victor lyamtsev <[email-masked]>
To: Darren Long <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-users] dtn2 cross compilation problem

No worries, i managed to fix it . All i needed was to add path to TCL
libs into LDFLAGS in config script.
Another question: can i run bundle transfer without db support? e.g.
can dtn2 be used with file io as bundle storage vs. berkley db?

On Wed, Sep 1, 2010 at 4:56 PM, Darren Long <[email-masked]> wrote:
> Hi,
>
> No really sensible suggestions from me, but I suppose a native build on your arm device is out of the question is it?
>
> I remember my NSLU2 (running Debian) taking about 12 hours, until I got distcc working with a cross compiler. �My sheevaplug (again running Debian) builds oasys and DTN2 in about 30 mins, IIRC.
>
> Darren
>
> On 1 Sep 2010, at 21:19, Victor lyamtsev wrote:
>
>> I've tried that as well - no luck....
>>
>> On Wed, Sep 1, 2010 at 2:02 PM, Elwyn Davies <[email-masked]> wrote:
>>> �On 01/09/2010 18:41, Victor lyamtsev wrote:
>>>> Hi Elwyn,
>>>> Again, I am working with ARM cross compilation toolchain on Intel host
>>>> What use can it be if add ARM binaries to load path for Intel linker?
>>>> I am looking how to add them for "arm-linux-ld", from command line.
>>>> Any idea how i can do that?
>>>> Thanks,
>>>> -V
>>> Hi.
>>>
>>> You could try
>>> --extra-ld-flags="-L/home/arm/tcl-8.4 -L/home/arm/oasys/lib"
>>>
>>> That will tell ld to search those directories.
>>>
>>> /E
>>>> On Wed, Sep 1, 2010 at 1:10 PM, Elwyn Davies <[email-masked]> wrote:
>>>>> �Hi.
>>>>>
>>>>> Have you told the loader (/bin/ld) that it should look in /home/arm tcl-8.4 ..
>>>>> and for that matter /home/arm/oasys/lib?
>>>>>
>>>>> The loader has a cache of places to look for libraries which is maintained by
>>>>> ldconfig (usually /sbin/ldconfig). �If the two directories are not in ld's cache
>>>>> then you will get the symptoms described. �make install doesn't do the cache
>>>>> update for you (if I remember correctly).
>>>>>
>>>>> ldconfig -p will print a list of currently known directories and the libraries
>>>>> it has seen there so you can check.
>>>>>
>>>>> You can add new directories with
>>>>> ldconfig /home/arm/tcl-8.4 ....
>>>>>
>>>>> or you can add the directory names to /etc/ld.so.config with your favourite text
>>>>> editor.
>>>>>
>>>>> Regards,
>>>>> Elwyn
>>>>>
>>>>>
>>>>> On 01/09/2010 17:39, Victor lyamtsev wrote:
>>>>>> Hello,
>>>>>> I am trying to cross compile DTN2 on i686 Linux ( Ubuntu 8.4) for ARM...
>>>>>> I managed to build tcl 8.4 and oasys 1.3 shared libs.
>>>>>> /home/arm/tcl-8.4 - libtcl8.4.so �libtclstub8.4.a
>>>>>> /home/arm/oasys/lib - liboasys-1.3.0.so �liboasyscompat.so
>>>>>> liboasyscompat-1.3.0.so �liboasys.so
>>>>>>
>>>>>> When i run dtn2 configuration script:
>>>>>> ./configure --host=arm-linux --build=i686-pc-linux-gnu
>>>>>> --with-tcl=/home/arm/tcl-8.4 -with-oasys=/home/arm/oasys
>>>>>> --prefix=/home/build/dtn2
>>>>>> I see the the following problem in log:
>>>>>> bin/ld: warning: libtcl8.4.so, needed by
>>>>>> /home/arm/oasys/lib/liboasys-1.3.0.so, not found (try using -rpath or
>>>>>> -rpath-link)
>>>>>> /home/arm/oasys/lib/liboasys-1.3.0.so: undefined reference to `Tcl_DeleteInterp'
>>>>>> ...
>>>>>>
>>>>>> So, it seems as problem is with linker not able to resolve references
>>>>>> to tcl shared libs for oasys.
>>>>>>
>>>>>> I've tried setting of RPATH env variable, or using
>>>>>> --with-extra-ldflags="rpath=/home/arm/tcl-8.4/lib" Nothing seems to
>>>>>> work. �Any advice how to resolve this problem?
>>>>>> Thank you,
>>>>>> -V
>>>>>> _______________________________________________
>>>>>> dtn-users mailing list
>>>>>> [email-masked]
>>>>>> http://maillists.intel-research.net/mailman/listinfo/dtn-users
>>>>>
>>>
>>>
>>
>> _______________________________________________
>> dtn-users mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-users
>
>

Date: Wed, 1 Sep 2010 14:12:40 -0700
From: Ricardo Martins <[email-masked]>
To: Darren Long <[email-masked]>
Cc: [email-masked], Victor lyamtsev <[email-masked]>
Subject: Re: [dtn-users] dtn2 cross compilation problem

Hi,

On 1 September 2010 13:56, Darren Long <[email-masked]> wrote:
> Hi,
>
> No really sensible suggestions from me, but I suppose a native build on your arm device is out of the question is it?
>
> I remember my NSLU2 (running Debian) taking about 12 hours, until I got distcc working with a cross compiler. �My sheevaplug (again running Debian) builds oasys and DTN2 in about 30 mins, IIRC.
>
> Darren
>
> On 1 Sep 2010, at 21:19, Victor lyamtsev wrote:
>
>> I've tried that as well - no luck....
Have you tried installing TCL and OASYS libraries in the same
directory ? One simple solution is to copy libtcl8.4.so to the same
directory where OASYS is installed.

>>
>> On Wed, Sep 1, 2010 at 2:02 PM, Elwyn Davies <[email-masked]> wrote:
>>> �On 01/09/2010 18:41, Victor lyamtsev wrote:
>>>> Hi Elwyn,
>>>> Again, I am working with ARM cross compilation toolchain on Intel host
>>>> What use can it be if add ARM binaries to load path for Intel linker?
>>>> I am looking how to add them for "arm-linux-ld", from command line.
>>>> Any idea how i can do that?
>>>> Thanks,
>>>> -V
>>> Hi.
>>>
>>> You could try
>>> --extra-ld-flags="-L/home/arm/tcl-8.4 -L/home/arm/oasys/lib"
>>>
>>> That will tell ld to search those directories.
>>>
>>> /E
>>>> On Wed, Sep 1, 2010 at 1:10 PM, Elwyn Davies <[email-masked]> wrote:
>>>>> �Hi.
>>>>>
>>>>> Have you told the loader (/bin/ld) that it should look in /home/arm tcl-8.4 ..
>>>>> and for that matter /home/arm/oasys/lib?
>>>>>
>>>>> The loader has a cache of places to look for libraries which is maintained by
>>>>> ldconfig (usually /sbin/ldconfig). �If the two directories are not in ld's cache
>>>>> then you will get the symptoms described. �make install doesn't do the cache
>>>>> update for you (if I remember correctly).
>>>>>
>>>>> ldconfig -p will print a list of currently known directories and the libraries
>>>>> it has seen there so you can check.
>>>>>
>>>>> You can add new directories with
>>>>> ldconfig /home/arm/tcl-8.4 ....
>>>>>
>>>>> or you can add the directory names to /etc/ld.so.config with your favourite text
>>>>> editor.
>>>>>
>>>>> Regards,
>>>>> Elwyn
>>>>>
>>>>>
>>>>> On 01/09/2010 17:39, Victor lyamtsev wrote:
>>>>>> Hello,
>>>>>> I am trying to cross compile DTN2 on i686 Linux ( Ubuntu 8.4) for ARM...
>>>>>> I managed to build tcl 8.4 and oasys 1.3 shared libs.
>>>>>> /home/arm/tcl-8.4 - libtcl8.4.so �libtclstub8.4.a
>>>>>> /home/arm/oasys/lib - liboasys-1.3.0.so �liboasyscompat.so
>>>>>> liboasyscompat-1.3.0.so �liboasys.so
>>>>>>
>>>>>> When i run dtn2 configuration script:
>>>>>> ./configure --host=arm-linux --build=i686-pc-linux-gnu
>>>>>> --with-tcl=/home/arm/tcl-8.4 -with-oasys=/home/arm/oasys
>>>>>> --prefix=/home/build/dtn2
>>>>>> I see the the following problem in log:
>>>>>> bin/ld: warning: libtcl8.4.so, needed by
>>>>>> /home/arm/oasys/lib/liboasys-1.3.0.so, not found (try using -rpath or
>>>>>> -rpath-link)
>>>>>> /home/arm/oasys/lib/liboasys-1.3.0.so: undefined reference to `Tcl_DeleteInterp'
>>>>>> ...
>>>>>>
>>>>>> So, it seems as problem is with linker not able to resolve references
>>>>>> to tcl shared libs for oasys.
>>>>>>
>>>>>> I've tried setting of RPATH env variable, or using
>>>>>> --with-extra-ldflags="rpath=/home/arm/tcl-8.4/lib" Nothing seems to
>>>>>> work. �Any advice how to resolve this problem?
>>>>>> Thank you,
>>>>>> -V
>>>>>> _______________________________________________
>>>>>> dtn-users mailing list
>>>>>> [email-masked]
>>>>>> http://maillists.intel-research.net/mailman/listinfo/dtn-users
>>>>>
>>>
>>>
>>
>> _______________________________________________
>> dtn-users mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-users
>
> _______________________________________________
> dtn-users mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-users
>

From: Darren Long <[email-masked]>
Date: Wed, 01 Sep 2010 21:56:17 +0100
To: Victor lyamtsev <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-users] dtn2 cross compilation problem

Hi,

No really sensible suggestions from me, but I suppose a native build on your arm device is out of the question is it?

I remember my NSLU2 (running Debian) taking about 12 hours, until I got distcc working with a cross compiler.  My sheevaplug (again running Debian) builds oasys and DTN2 in about 30 mins, IIRC.

Darren

On 1 Sep 2010, at 21:19, Victor lyamtsev wrote:

> I've tried that as well - no luck....
> 
> On Wed, Sep 1, 2010 at 2:02 PM, Elwyn Davies <[email-masked]> wrote:
>>  On 01/09/2010 18:41, Victor lyamtsev wrote:
>>> Hi Elwyn,
>>> Again, I am working with ARM cross compilation toolchain on Intel host
>>> What use can it be if add ARM binaries to load path for Intel linker?
>>> I am looking how to add them for "arm-linux-ld", from command line.
>>> Any idea how i can do that?
>>> Thanks,
>>> -V
>> Hi.
>> 
>> You could try
>> --extra-ld-flags="-L/home/arm/tcl-8.4 -L/home/arm/oasys/lib"
>> 
>> That will tell ld to search those directories.
>> 
>> /E
>>> On Wed, Sep 1, 2010 at 1:10 PM, Elwyn Davies <[email-masked]> wrote:
>>>>  Hi.
>>>> 
>>>> Have you told the loader (/bin/ld) that it should look in /home/arm tcl-8.4 ..
>>>> and for that matter /home/arm/oasys/lib?
>>>> 
>>>> The loader has a cache of places to look for libraries which is maintained by
>>>> ldconfig (usually /sbin/ldconfig).  If the two directories are not in ld's cache
>>>> then you will get the symptoms described.  make install doesn't do the cache
>>>> update for you (if I remember correctly).
>>>> 
>>>> ldconfig -p will print a list of currently known directories and the libraries
>>>> it has seen there so you can check.
>>>> 
>>>> You can add new directories with
>>>> ldconfig /home/arm/tcl-8.4 ....
>>>> 
>>>> or you can add the directory names to /etc/ld.so.config with your favourite text
>>>> editor.
>>>> 
>>>> Regards,
>>>> Elwyn
>>>> 
>>>> 
>>>> On 01/09/2010 17:39, Victor lyamtsev wrote:
>>>>> Hello,
>>>>> I am trying to cross compile DTN2 on i686 Linux ( Ubuntu 8.4) for ARM...
>>>>> I managed to build tcl 8.4 and oasys 1.3 shared libs.
>>>>> /home/arm/tcl-8.4 - libtcl8.4.so  libtclstub8.4.a
>>>>> /home/arm/oasys/lib - liboasys-1.3.0.so  liboasyscompat.so
>>>>> liboasyscompat-1.3.0.so  liboasys.so
>>>>> 
>>>>> When i run dtn2 configuration script:
>>>>> ./configure --host=arm-linux --build=i686-pc-linux-gnu
>>>>> --with-tcl=/home/arm/tcl-8.4 -with-oasys=/home/arm/oasys
>>>>> --prefix=/home/build/dtn2
>>>>> I see the the following problem in log:
>>>>> bin/ld: warning: libtcl8.4.so, needed by
>>>>> /home/arm/oasys/lib/liboasys-1.3.0.so, not found (try using -rpath or
>>>>> -rpath-link)
>>>>> /home/arm/oasys/lib/liboasys-1.3.0.so: undefined reference to `Tcl_DeleteInterp'
>>>>> ...
>>>>> 
>>>>> So, it seems as problem is with linker not able to resolve references
>>>>> to tcl shared libs for oasys.
>>>>> 
>>>>> I've tried setting of RPATH env variable, or using
>>>>> --with-extra-ldflags="rpath=/home/arm/tcl-8.4/lib" Nothing seems to
>>>>> work.  Any advice how to resolve this problem?
>>>>> Thank you,
>>>>> -V
>>>>> _______________________________________________
>>>>> dtn-users mailing list
>>>>> [email-masked]
>>>>> http://maillists.intel-research.net/mailman/listinfo/dtn-users
>>>> 
>> 
>> 
> 
> _______________________________________________
> dtn-users mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-users

Date: Wed, 1 Sep 2010 16:19:03 -0400
From: Victor lyamtsev <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dtn-users] dtn2 cross compilation problem

I've tried that as well - no luck....

On Wed, Sep 1, 2010 at 2:02 PM, Elwyn Davies <[email-masked]> wrote:
> �On 01/09/2010 18:41, Victor lyamtsev wrote:
>> Hi Elwyn,
>> Again, I am working with ARM cross compilation toolchain on Intel host
>> What use can it be if add ARM binaries to load path for Intel linker?
>> I am looking how to add them for "arm-linux-ld", from command line.
>> Any idea how i can do that?
>> Thanks,
>> -V
> Hi.
>
> You could try
> --extra-ld-flags="-L/home/arm/tcl-8.4 -L/home/arm/oasys/lib"
>
> That will tell ld to search those directories.
>
> /E
>> On Wed, Sep 1, 2010 at 1:10 PM, Elwyn Davies <[email-masked]> wrote:
>>> �Hi.
>>>
>>> Have you told the loader (/bin/ld) that it should look in /home/arm tcl-8.4 ..
>>> and for that matter /home/arm/oasys/lib?
>>>
>>> The loader has a cache of places to look for libraries which is maintained by
>>> ldconfig (usually /sbin/ldconfig). �If the two directories are not in ld's cache
>>> then you will get the symptoms described. �make install doesn't do the cache
>>> update for you (if I remember correctly).
>>>
>>> ldconfig -p will print a list of currently known directories and the libraries
>>> it has seen there so you can check.
>>>
>>> You can add new directories with
>>> ldconfig /home/arm/tcl-8.4 ....
>>>
>>> or you can add the directory names to /etc/ld.so.config with your favourite text
>>> editor.
>>>
>>> Regards,
>>> Elwyn
>>>
>>>
>>> On 01/09/2010 17:39, Victor lyamtsev wrote:
>>>> Hello,
>>>> I am trying to cross compile DTN2 on i686 Linux ( Ubuntu 8.4) for ARM...
>>>> I managed to build tcl 8.4 and oasys 1.3 shared libs.
>>>> /home/arm/tcl-8.4 - libtcl8.4.so �libtclstub8.4.a
>>>> /home/arm/oasys/lib - liboasys-1.3.0.so �liboasyscompat.so
>>>> liboasyscompat-1.3.0.so �liboasys.so
>>>>
>>>> When i run dtn2 configuration script:
>>>> ./configure --host=arm-linux --build=i686-pc-linux-gnu
>>>> --with-tcl=/home/arm/tcl-8.4 -with-oasys=/home/arm/oasys
>>>> --prefix=/home/build/dtn2
>>>> I see the the following problem in log:
>>>> bin/ld: warning: libtcl8.4.so, needed by
>>>> /home/arm/oasys/lib/liboasys-1.3.0.so, not found (try using -rpath or
>>>> -rpath-link)
>>>> /home/arm/oasys/lib/liboasys-1.3.0.so: undefined reference to `Tcl_DeleteInterp'
>>>> ...
>>>>
>>>> So, it seems as problem is with linker not able to resolve references
>>>> to tcl shared libs for oasys.
>>>>
>>>> I've tried setting of RPATH env variable, or using
>>>> --with-extra-ldflags="rpath=/home/arm/tcl-8.4/lib" Nothing seems to
>>>> work. �Any advice how to resolve this problem?
>>>> Thank you,
>>>> -V
>>>> _______________________________________________
>>>> dtn-users mailing list
>>>> [email-masked]
>>>> http://maillists.intel-research.net/mailman/listinfo/dtn-users
>>>
>
>

Date: Wed, 01 Sep 2010 19:02:18 +0100
From: Elwyn Davies <[email-masked]>
To: Victor lyamtsev <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-users] dtn2 cross compilation problem
Reply-To: [email-masked]

 On 01/09/2010 18:41, Victor lyamtsev wrote:
> Hi Elwyn,
> Again, I am working with ARM cross compilation toolchain on Intel host
> What use can it be if add ARM binaries to load path for Intel linker?
> I am looking how to add them for "arm-linux-ld", from command line.
> Any idea how i can do that?
> Thanks,
> -V
Hi.

You could try
--extra-ld-flags="-L/home/arm/tcl-8.4 -L/home/arm/oasys/lib"

That will tell ld to search those directories.

/E
> On Wed, Sep 1, 2010 at 1:10 PM, Elwyn Davies <[email-masked]> wrote:
>>  Hi.
>>
>> Have you told the loader (/bin/ld) that it should look in /home/arm tcl-8.4 ..
>> and for that matter /home/arm/oasys/lib?
>>
>> The loader has a cache of places to look for libraries which is maintained by
>> ldconfig (usually /sbin/ldconfig).  If the two directories are not in ld's cache
>> then you will get the symptoms described.  make install doesn't do the cache
>> update for you (if I remember correctly).
>>
>> ldconfig -p will print a list of currently known directories and the libraries
>> it has seen there so you can check.
>>
>> You can add new directories with
>> ldconfig /home/arm/tcl-8.4 ....
>>
>> or you can add the directory names to /etc/ld.so.config with your favourite text
>> editor.
>>
>> Regards,
>> Elwyn
>>
>>
>> On 01/09/2010 17:39, Victor lyamtsev wrote:
>>> Hello,
>>> I am trying to cross compile DTN2 on i686 Linux ( Ubuntu 8.4) for ARM...
>>> I managed to build tcl 8.4 and oasys 1.3 shared libs.
>>> /home/arm/tcl-8.4 - libtcl8.4.so  libtclstub8.4.a
>>> /home/arm/oasys/lib - liboasys-1.3.0.so  liboasyscompat.so
>>> liboasyscompat-1.3.0.so  liboasys.so
>>>
>>> When i run dtn2 configuration script:
>>> ./configure --host=arm-linux --build=i686-pc-linux-gnu
>>> --with-tcl=/home/arm/tcl-8.4 -with-oasys=/home/arm/oasys
>>> --prefix=/home/build/dtn2
>>> I see the the following problem in log:
>>> bin/ld: warning: libtcl8.4.so, needed by
>>> /home/arm/oasys/lib/liboasys-1.3.0.so, not found (try using -rpath or
>>> -rpath-link)
>>> /home/arm/oasys/lib/liboasys-1.3.0.so: undefined reference to `Tcl_DeleteInterp'
>>> ...
>>>
>>> So, it seems as problem is with linker not able to resolve references
>>> to tcl shared libs for oasys.
>>>
>>> I've tried setting of RPATH env variable, or using
>>> --with-extra-ldflags="rpath=/home/arm/tcl-8.4/lib" Nothing seems to
>>> work.  Any advice how to resolve this problem?
>>> Thank you,
>>> -V
>>> _______________________________________________
>>> dtn-users mailing list
>>> [email-masked]
>>> http://maillists.intel-research.net/mailman/listinfo/dtn-users
>>

Date: Wed, 1 Sep 2010 13:41:32 -0400
From: Victor lyamtsev <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-users] dtn2 cross compilation problem

Hi Elwyn,
Again, I am working with ARM cross compilation toolchain on Intel host
What use can it be if add ARM binaries to load path for Intel linker?
I am looking how to add them for "arm-linux-ld", from command line.
Any idea how i can do that?
Thanks,
-V
On Wed, Sep 1, 2010 at 1:10 PM, Elwyn Davies <[email-masked]> wrote:
> �Hi.
>
> Have you told the loader (/bin/ld) that it should look in /home/arm tcl-8.4 ..
> and for that matter /home/arm/oasys/lib?
>
> The loader has a cache of places to look for libraries which is maintained by
> ldconfig (usually /sbin/ldconfig). �If the two directories are not in ld's cache
> then you will get the symptoms described. �make install doesn't do the cache
> update for you (if I remember correctly).
>
> ldconfig -p will print a list of currently known directories and the libraries
> it has seen there so you can check.
>
> You can add new directories with
> ldconfig /home/arm/tcl-8.4 ....
>
> or you can add the directory names to /etc/ld.so.config with your favourite text
> editor.
>
> Regards,
> Elwyn
>
>
> On 01/09/2010 17:39, Victor lyamtsev wrote:
>> Hello,
>> I am trying to cross compile DTN2 on i686 Linux ( Ubuntu 8.4) for ARM...
>> I managed to build tcl 8.4 and oasys 1.3 shared libs.
>> /home/arm/tcl-8.4 - libtcl8.4.so �libtclstub8.4.a
>> /home/arm/oasys/lib - liboasys-1.3.0.so �liboasyscompat.so
>> liboasyscompat-1.3.0.so �liboasys.so
>>
>> When i run dtn2 configuration script:
>> ./configure --host=arm-linux --build=i686-pc-linux-gnu
>> --with-tcl=/home/arm/tcl-8.4 -with-oasys=/home/arm/oasys
>> --prefix=/home/build/dtn2
>> I see the the following problem in log:
>> bin/ld: warning: libtcl8.4.so, needed by
>> /home/arm/oasys/lib/liboasys-1.3.0.so, not found (try using -rpath or
>> -rpath-link)
>> /home/arm/oasys/lib/liboasys-1.3.0.so: undefined reference to `Tcl_DeleteInterp'
>> ...
>>
>> So, it seems as problem is with linker not able to resolve references
>> to tcl shared libs for oasys.
>>
>> I've tried setting of RPATH env variable, or using
>> --with-extra-ldflags="rpath=/home/arm/tcl-8.4/lib" Nothing seems to
>> work. �Any advice how to resolve this problem?
>> Thank you,
>> -V
>> _______________________________________________
>> dtn-users mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-users
>
>

Date: Wed, 01 Sep 2010 18:10:09 +0100
From: Elwyn Davies <[email-masked]>
To: Victor lyamtsev <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn-users] dtn2 cross compilation problem
Reply-To: [email-masked]

 Hi.

Have you told the loader (/bin/ld) that it should look in /home/arm tcl-8.4 ..
and for that matter /home/arm/oasys/lib?

The loader has a cache of places to look for libraries which is maintained by
ldconfig (usually /sbin/ldconfig).  If the two directories are not in ld's cache
then you will get the symptoms described.  make install doesn't do the cache
update for you (if I remember correctly). 

ldconfig -p will print a list of currently known directories and the libraries
it has seen there so you can check.

You can add new directories with
ldconfig /home/arm/tcl-8.4 ....

or you can add the directory names to /etc/ld.so.config with your favourite text
editor.

Regards,
Elwyn

On 01/09/2010 17:39, Victor lyamtsev wrote:
> Hello,
> I am trying to cross compile DTN2 on i686 Linux ( Ubuntu 8.4) for ARM...
> I managed to build tcl 8.4 and oasys 1.3 shared libs.
> /home/arm/tcl-8.4 - libtcl8.4.so  libtclstub8.4.a
> /home/arm/oasys/lib - liboasys-1.3.0.so  liboasyscompat.so
> liboasyscompat-1.3.0.so  liboasys.so
>
> When i run dtn2 configuration script:
> ./configure --host=arm-linux --build=i686-pc-linux-gnu
> --with-tcl=/home/arm/tcl-8.4 -with-oasys=/home/arm/oasys
> --prefix=/home/build/dtn2
> I see the the following problem in log:
> bin/ld: warning: libtcl8.4.so, needed by
> /home/arm/oasys/lib/liboasys-1.3.0.so, not found (try using -rpath or
> -rpath-link)
> /home/arm/oasys/lib/liboasys-1.3.0.so: undefined reference to `Tcl_DeleteInterp'
> ...
>
> So, it seems as problem is with linker not able to resolve references
> to tcl shared libs for oasys.
>
> I've tried setting of RPATH env variable, or using
> --with-extra-ldflags="rpath=/home/arm/tcl-8.4/lib" Nothing seems to
> work.  Any advice how to resolve this problem?
> Thank you,
> -V
> _______________________________________________
> dtn-users mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-users

Date: Wed, 1 Sep 2010 12:39:44 -0400
From: Victor lyamtsev <[email-masked]>
To: [email-masked]
Subject: [dtn-users] dtn2 cross compilation problem

Hello,
I am trying to cross compile DTN2 on i686 Linux ( Ubuntu 8.4) for ARM...
I managed to build tcl 8.4 and oasys 1.3 shared libs.
/home/arm/tcl-8.4 - libtcl8.4.so  libtclstub8.4.a
/home/arm/oasys/lib - liboasys-1.3.0.so  liboasyscompat.so
liboasyscompat-1.3.0.so  liboasys.so

When i run dtn2 configuration script:
./configure --host=arm-linux --build=i686-pc-linux-gnu
--with-tcl=/home/arm/tcl-8.4 -with-oasys=/home/arm/oasys
--prefix=/home/build/dtn2
I see the the following problem in log:
bin/ld: warning: libtcl8.4.so, needed by
/home/arm/oasys/lib/liboasys-1.3.0.so, not found (try using -rpath or
-rpath-link)
/home/arm/oasys/lib/liboasys-1.3.0.so: undefined reference to `Tcl_DeleteInterp'
...

So, it seems as problem is with linker not able to resolve references
to tcl shared libs for oasys.

I've tried setting of RPATH env variable, or using
--with-extra-ldflags="rpath=/home/arm/tcl-8.4/lib" Nothing seems to
work.  Any advice how to resolve this problem?
Thank you,
-V