Hi Amitha,
  I am implementing your suggestion for the snprintf but I have got a bit stuck with some multiple definition of `snprintf' linker errors in some of the tests.

my stanza in vcl_cstdio.h looks like

#elif defined(VCL_ANDROID)
# include "vcl_cstddef.h" // for size_t
# include "android/snprintf.h"
# define vcl_snprintf snprintf
# include "iso/vcl_cstdio.h"
...

and I have been very careful to make sure that android/snprintf.h is wrapped in

#ifndef vcl_android_snprintf_h_
#define vcl_android_snprintf_h_

// some stuff defining snprintf

#endif // vcl_android_snprintf_h_

I have searched the vxl source tree for other definitions of snprintf but I can not seem to find one anywhere.  Can you think where I might be going wrong with this?

Cheers,
David...

On Tue, May 3, 2011 at 3:40 PM, Amitha Perera <amithaperera@users.sourceforge.net> wrote:
David,

For the snprintf problem, the solution is to:
1. Add to vcl_compiler.h to add a stanza to determine your OS/compiler combination.  As Glen seems to be able to build on ARM, perhaps your issues are specific to Android?  Maybe a block like
  #if defined(_ANDROID) /* or whatever works*/
  #  define VCL_ANDROID
  #endif

2. Add a stanza to vcl_cstdio.h to implement snprintf. Maybe something like
   ...
   #elif defined(VCL_ANDROID)
   # include "impl/snprintf.h"
   # include "iso/vcl_cstdio.h"
   ...
where impl/snprintf.h has your inline implementation of vcl_snprintf. Note that the implementation must be compatible with the VXL license, so you can't just cut-n-paste code off of, say, glibc.

Feel free to post a patch for review.

Amitha.




On 05/02/2011 06:36 PM, David McKinnon wrote:
Hi Amitha,

Thanks for your enthusiasm and offer of help.

I have read up on creating and submitting dashboard reports. Looks
like I will have to find a machine at my university that can regularly
submit the cdash reports.  We also have a sizable contrib directory that
we were planning an internal dashboard for so this adds to the impetus
get this happening.  This may take a week or so.

I am really hoping that someone might be able to offers some advice
about those vcl related issues I had in the compile. I suspect this will
be the bulk of the remaining effort required to get the core building on
Android and I would not be confident in making any changes to vcl myself.

I have no feeling for whether the examples/tests will work until they
are tested. Also, I am not quite sure how to go about setting aside a
permanent Android device to run the tests to submit and whether having
one machine submit build info and another submit the test info is even
possible.  Remembering that any binaries that are built will have to be
copied to a Android device run externally (probably over ssh) with the
results of the tests gathered from the device to the build platform.

David...

On Mon, May 2, 2011 at 11:58 PM, Amitha Perera
<amithaperera@users.sourceforge.net
<mailto:amithaperera@users.sourceforge.net>> wrote:

   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
   <mailto: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 <mailto:Vxl-users@lists.sourceforge.net>