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