Menu
▾
▴
Re: [Vxl-users] Android Port
|
From: David M. <mck...@gm...> - 2011-05-02 22:36:26
|
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 <
ami...@us...> 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...@li...
> > 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...@li...
> https://lists.sourceforge.net/lists/listinfo/vxl-users
>
|