Thanks for the feedback Amitha and Gehua.  I'm not too familiar with the issue, but I have also read that -fPIC is not needed on x86 platforms in the past.   Unfortunately I don't have a 32 bit platform to test on at the moment, but I will create a virtual machine and try it out when I get a chance.   In the meantime, I have pushed my changes to the sourceforge repository, with the cmake message altered to be less confusing (per Amitha's suggestion).

Thanks,
Dan
 


On Thu, Jul 18, 2013 at 11:09 AM, Gehua Yang <yanggehua@gmail.com> wrote:
Hi Amitha and Daniel,

I am not sure adding "-fPIC" to x86 build is a good idea.  Though I
have not dig deep into this issue, I know most Linux distributions do
not use "-fPIC" in their i586/i686 compilation.  A Google search on
this topic also turned out an interesting article:
http://www.bailopan.net/blog/?p=50

According to the article, x86 has no concept of PC-relative
addressing.  Adding "-fPIC" to x86 build would actually hurt code
performance.

Best,
Gehua.





On Thu, Jul 18, 2013 at 12:05 AM, Amitha Perera <amitha@thepereras.org> wrote:
> I don't think there should be a dependency on x64, since the same issue
> holds for x86: code in dynamically loaded libraries should have -fPIC
> enabled.
>
> I would edit the comment for the new variable to say "Generate position
> dependent code (i.e. code cannot be used in a shared library)".
>
> Amitha.
>
>
>
> On 7/17/2013 6:12 PM, Daniel Crispell wrote:
>
> Thanks all for the suggestions.  I have added some code in the
> CMakeLists.txt of the base directory which seems to do the trick.  The
> "BUILD_POSITION_DEPENDENT_CODE" variable will be added and defaulted to
> "OFF" if UNIX, x86_64, and BUILD_SHARED_LIBS is false.  The shared python
> modules are only built if BUILD_POSITION_DEPENDENT_CODE is not set.  I
> decided not to take advantage of the CMAKE_POSITION_INDEPENDENT_CODE target
> property for now, given that our minimum version required is currently set
> at 2.4.5.  The base directory CMakeLists.txt diff is pasted below - I will
> push the changes tomorrow if there are no objections.
>
> Thanks,
> Dan
>
> diff --git a/CMakeLists.txt b/CMakeLists.txt
> index b8aa944..133b21a 100644
> --- a/CMakeLists.txt
> +++ b/CMakeLists.txt
> @@ -141,6 +141,21 @@ ELSE(WIN32)
>    SET(VXL_USE_WIN_WCHAR_T 0)
>  ENDIF(WIN32)
>
> +# In order to be able to link vxl libraries into shared libraries on 64 bit
> linux, the -fPIC
> +# compiler flag must be added.  Only do this if we are on a x86_64 *nix
> platform, we're building
> +# static libraries, and the user has not explicitly requested position
> dependent code.
> +IF(UNIX)
> +  IF(NOT BUILD_SHARED_LIBS AND CMAKE_SYSTEM_PROCESSOR MATCHES "x86_64")
> +    OPTION(BUILD_POSITION_DEPENDENT_CODE "Generate position dependent code
> (PIC is needed for linking to shared libraries)" OFF)
> +    MARK_AS_ADVANCED(BUILD_POSITION_DEPENDENT_CODE)
> +    IF (NOT BUILD_POSITION_DEPENDENT_CODE)
> +      message(STATUS "Adding -fPIC compiler flag to generate position
> independent code.")
> +      SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}-fPIC")
> +      SET(CMAKE_C_FLAGS "${CMAKE_C_FLAGS}-fPIC")
> +    ENDIF(NOT BUILD_POSITION_DEPENDENT_CODE)
> +  ENDIF(NOT BUILD_SHARED_LIBS AND CMAKE_SYSTEM_PROCESSOR MATCHES "x86_64")
> +ENDIF(UNIX)
> +
>  # Build the core vxl + support libraries
>  SUBDIRS(vcl v3p core)
>
>
>
>
>
>
>
>
> On Wed, Jul 17, 2013 at 10:45 AM, Brad King <brad.king@kitware.com> wrote:
>>
>> On 7/17/2013 9:11 AM, Gehua Yang wrote:
>> > I just want to be clear, the "-fPIC" option shall be added if the
>> > option is true, "UNIX" is  true, *and* it is 64-bit build.  I would
>> > suggest also add status message output when this flag is being added.
>>
>> FYI, CMake 2.8.9 and later support a POSITION_INDEPENDENT_CODE target
>> property that adds corresponding flags for each toolchain and platform.
>> One can add
>>
>>  set(CMAKE_POSITION_INDEPENDENT_CODE 1)
>>
>> to activate it by default for all subsequently-added targets (but only
>> for CMake >= 2.8.9).
>>
>> -Brad
>>
>>
>> ------------------------------------------------------------------------------
>> See everything from the browser to the database with AppDynamics
>> Get end-to-end visibility with application monitoring from AppDynamics
>> Isolate bottlenecks and diagnose root cause in seconds.
>> Start your free trial of AppDynamics Pro today!
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Vxl-maintainers mailing list
>> Vxl-maintainers@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/vxl-maintainers
>
>
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>
>
>
> _______________________________________________
> Vxl-maintainers mailing list
> Vxl-maintainers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/vxl-maintainers
>
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Vxl-maintainers mailing list
> Vxl-maintainers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/vxl-maintainers
>