From: David M. <mck...@gm...> - 2011-05-02 09:58:10
|
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... |
From: David M. <mck...@gm...> - 2011-05-01 08:59:27
|
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... |
From: Amitha P. <ami...@us...> - 2011-05-02 14:15:53
|
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 |
From: Brooksby, G. W (GE G. Research) <bro...@ge...> - 2011-05-02 15:36:31
|
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:ami...@us...] Sent: Monday, May 02, 2011 9:58 AM To: vxl...@li... 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...@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 |
From: David M. <mck...@gm...> - 2011-05-02 22:13:19
|
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) < bro...@ge...> 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:ami...@us...] > Sent: Monday, May 02, 2011 9:58 AM > To: vxl...@li... > 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...@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 > > > ------------------------------------------------------------------------------ > 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 > |
From: Brooksby, G. W (GE G. Research) <bro...@ge...> - 2011-06-22 21:03:25
|
David, For some reason I looked at this message and don't see that I ever replied. In the intervening time you may have answered these questions yourself, but just so you know, * I don't know what the define is for an ARM compile. If you do, I'd like to know. * 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. Sorry for the tardy reply. How is the Android build going? Glen From: David McKinnon [mailto:mck...@gm...] Sent: Monday, May 02, 2011 6:13 PM To: Brooksby, Glen W (GE Global Research) Cc: vxl...@li... 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) <bro...@ge...> 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:ami...@us...] Sent: Monday, May 02, 2011 9:58 AM To: vxl...@li... 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...@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 ------------------------------------------------------------------------ ------ 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 |
From: David M. <mck...@gm...> - 2011-06-23 03:05:23
|
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:mck...@gm...] > *Sent:* Monday, May 02, 2011 6:13 PM > *To:* Brooksby, Glen W (GE Global Research) > *Cc:* vxl...@li... > > *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) < > bro...@ge...> 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:ami...@us...] > Sent: Monday, May 02, 2011 9:58 AM > To: vxl...@li... > 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...@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 > > > ------------------------------------------------------------------------------ > 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**** > > ** ** > |
From: Brooksby, G. W (GE G. Research) <bro...@ge...> - 2011-06-23 20:46:51
|
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:mck...@gm...] Sent: Wednesday, June 22, 2011 11:05 PM To: Brooksby, Glen W (GE Global Research) Cc: vxl...@li... 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:mck...@gm...] Sent: Monday, May 02, 2011 6:13 PM To: Brooksby, Glen W (GE Global Research) Cc: vxl...@li... 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) <bro...@ge...> 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:ami...@us...] Sent: Monday, May 02, 2011 9:58 AM To: vxl...@li... 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...@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 ------------------------------------------------------------------------ ------ 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 |
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 > |
From: Amitha P. <ami...@us...> - 2011-05-03 05:40:51
|
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 > <ami...@us... > <mailto: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... > <mailto: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... <mailto:Vxl...@li...> > https://lists.sourceforge.net/lists/listinfo/vxl-users > > |
From: David M. <mck...@gm...> - 2011-05-05 04:44:49
|
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 < ami...@us...> 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 >> <ami...@us... >> <mailto: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... >> <mailto: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... <mailto: >> Vxl...@li...> >> >> https://lists.sourceforge.net/lists/listinfo/vxl-users >> >> >> > |