David,

 

I’m not planning on a dashboard build at this point.  I’m just contemplating an Android build.  It would be great to have your changes, so I don’t have to retread the ground you’ve covered. If your changes won’t break the current builds (Windows, *nix, etc.), would it be safe to check them in and worry about the dashboard build later?

 

Glen

 

 

From: David McKinnon [mailto:mckinnondavid@gmail.com]
Sent: Wednesday, June 22, 2011 11:05 PM
To: Brooksby, Glen W (GE Global Research)
Cc: vxl-users@lists.sourceforge.net
Subject: Re: [Vxl-users] Android Port

 

Hi Glen,

·         I don’t know what the define is for an ARM compile.  If you do, I’d like to know.

I never managed to work that out I left off with the rather unsatisfying solution of assuming arm if it didn't conform to the hardware types.

 

·         Also, I mentioned that there was a problem in vil_round.h where assembler was being inserted where it shouldn’t for ARM.  This problem also occurs in vnl_math.h as well.

I found a bunch of instances of such problems and fixed them up in the source.

 

Sorry for the tardy reply.  How is the Android build going?

 

I have completed the build but baulked at submitting the changes back because I cannot think of a good way to do the test machines build chain for the dashboard.  Android requires binaries to be packaged in java executable apk files, obviously it would not be feasible to make one of these for each binary in the build chain so I am bit stuck as to how the test machine would work.

 

One idea that occurred to me was if it was possible to assume that valid arm binaries will always work with Android, you could just install an ARM emulator on any machine and have that execute the tests to make sure the nightly build is still OK.  I haven't made it too far with this idea yet though.

 

Were you planning on making an arm dashboard target?  If so I could look into what assumptions are valid as far as whether this implies that an Android wrap of these binaries would work.

 

David...

 

 

Glen

 

From: David McKinnon [mailto:mckinnondavid@gmail.com]
Sent: Monday, May 02, 2011 6:13 PM
To: Brooksby, Glen W (GE Global Research)
Cc: vxl-users@lists.sourceforge.net


Subject: Re: [Vxl-users] Android Port

 

Hi Glen,

  thanks for pointing that out, do you know what the define is for an ARM compile?

 

This could be used to further constrain the conditions here such as !define(??ARM??).

 

Hopefully as you have indicated this is the only instance of straight assembly code to worry about I will keep my eye out for this issue once I get the other problems resolved.

 

Thanks,

David...

On Tue, May 3, 2011 at 1:35 AM, Brooksby, Glen W (GE Global Research) <brooksby@ge.com> wrote:

David,

I have built VXL on an ARM platform. In fact it's re-building as I type.
I'm doing my compilation natively on the ARM under Ubuntu. The only
problem I've run into is in core/vil/vil_round.h. There is code that
attempts to insert a speedup using assembler.  Around line 30 of this
file there is a stanza like this:

#if defined(__GNUC__) && (!defined(__APPLE__)  || !defined(__ppc__) )
# define GCC_USE_FAST_IMPL 1
#else
# define GCC_USE_FAST_IMPL 0
#endif

This implies that if the compiler is GCC and the platform is not Apple
or PowerPC, then it must be Intel and the assembler code is inserted.
This is obviously a bad assumption and in my opinion should be fixed.
My local patch was to never define GCC_USE_FAST_IMPL as 1.

Other than that, the compilation went fine, though very slow since it's
being done natively. I have not seen the errors you cite, perhaps
because I'm not running Android. You may run into the one I cite,
however, as you get further along.

Glen



-----Original Message-----
From: Amitha Perera [mailto:amithaperera@users.sourceforge.net]
Sent: Monday, May 02, 2011 9:58 AM
To: vxl-users@lists.sourceforge.net
Subject: Re: [Vxl-users] Android Port

David,

I'd be happy to help out as I can with this port.  I think it's a cool
effort!

Can you get a dashboard submission going?  That'll allow us to make sure
(1) we fix the issues, and (2) we don't break it in future.

Thanks,
Amitha.



On 05/02/2011 05:58 AM, David McKinnon wrote:
> Hi,
> I have started an Android port, I am using android-cmake which seems
> to allow VXL to build for the most part with the proper arm
> architecture switches straight out of the box.
>
> I have run into four problems so far, solving two of them and the
> remaining two are unsolved.
>
> Firstly, as you are building for a remote platform is not clear to
> your build architecture what the endian type is.  I have added the
> following lines to the root level CMakeLists.txt around line 33
>
> OPTION(VXL_CHECK_ENDIAN "Check for target platform endian type?" YES)
> IF(NOT VXL_CHECK_ENDIAN) OPTION(VXL_IS_BIG_ENDIAN "Whether the target
> platform endian type is big?" YES)
> IF(VXL_IS_BIG_ENDIAN)
> SET(VXL_BIG_ENDIAN 1)
> SET(VXL_LITTLE_ENDIAN 0)
> ELSE(VXL_IS_BIG_ENDIAN)
> SET(VXL_BIG_ENDIAN 0)
> SET(VXL_LITTLE_ENDIAN 1)
> ENDIF(VXL_IS_BIG_ENDIAN)
> ENDIF(NOT VXL_CHECK_ENDIAN)
>
> The idea here is that if you know the endian type of the remote
> platform you can just set it as a cmake option, the naming of these
> variable may not be ideal...
>
> Secondly the file search.h does not exist in the Android NDK
> consequently there are problems when building tiff support. Due to
> this the following edits are made to v3p/tiff/tif_config.h
>
> /* Define to 1 if you have the <search.h> header file. */ #ifndef
> ANDROID #define HAVE_SEARCH_H 1 #endif // ANDROID
>
> There are two further problems that I have hit that I have not been
> able to get around yet mostly because they will require some changes
> to vcl and more specifically the support of std C functions within.
> There is an absence of snprintf (from vul_url) and the function
> __errno_location
> (vil_nitf2_typed_field_formatter.cxx) for the Android platform.
>
> A fix to the snprintf would be to provide this definition somewhere :
>
> *int*
> snprintf(*char*  *str,size_t  n,*const*  *char*  *fmt, ...)
> *{*
>    va_list  ap;
>       *int*  ret;
>       *char*  dummy;
>       FILE  f;
>       *struct*  __sfileext  fext;
>
>       /* While snprintf(3) specifies size_t stdio uses an int
internally */
>       *if*  (n  >  INT_MAX)
>               n  =  INT_MAX;
>       /* Stdio internals do not deal correctly with zero length buffer
*/
>       *if*  (n  ==  0)  *{*
>               str  =  &dummy;
>               n  =  1;
>       *}*
>       _FILEEXT_SETUP(&f,&fext);
>       f._file  =  -1;
>       f._flags  =  __SWR  |  __SSTR;
>       f._bf._base  =  f._p  =  (*unsigned*  *char*  *)str;
>       f._bf._size  =  f._w  =  n  -  1;
>       va_start(ap,fmt);
>       ret  =  vfprintf(&f,fmt,ap);
>    va_end(ap);
>       *f._p  =  '\0';
>       *return*  (ret);
> *}*
>
>
> Another issue I have read about is the packing of bytes in structs
>
> struct {
> unsigned char something;
> int else
> };
>
> Would result in a sizeof() = 8 not 5 on a typical system, I don't know

> if this is problematic or not.
>
> As far as I can tell these are the only issues in the core libraries
> and I suspect that there are probably some straight forward solutions
> for those of you that understand vcl adequately.
>
> Does anyone have some ideas about solutions?  Or is there any general
> interest in adding in these support fixes to the SVN?
>
> Cheers,
> David McKinnon...
>
>
>
> ----------------------------------------------------------------------
> -------- WhatsUp Gold - Download Free Network Management Software The
> most intuitive, comprehensive, and cost-effective network management
> toolset available today.  Delivers lowest initial acquisition cost and

> overall TCO of any competing solution.
> http://p.sf.net/sfu/whatsupgold-sd
>
>
>
> _______________________________________________
> Vxl-users mailing list
> Vxl-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/vxl-users


------------------------------------------------------------------------
------
WhatsUp Gold - Download Free Network Management Software The most
intuitive, comprehensive, and cost-effective network management toolset
available today.  Delivers lowest initial acquisition cost and overall
TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
Vxl-users mailing list
Vxl-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/vxl-users

------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today.  Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
Vxl-users mailing list
Vxl-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/vxl-users