I don't think there is a huge cost to having -fPIC be default, for most of the modern use cases. (Someone correct me if I'm wrong.)  Maybe a flag "BUILD_POSITION_DEPENDENT_CODE", defaulting to "off" would be better?  Then the python modules won't be built if this flag is on.  This could be an advanced variable, since most people probably don't care about the difference, but it would allow someone who cared to build position dependent code.


On 7/17/2013 8:25 AM, Daniel Crispell wrote:
By the way, I have added a build to the dashboard (http://open.cdash.org/viewBuildError.php?buildid=2968511) which is currently affected by the issue in question. 



On Tue, Jul 16, 2013 at 9:00 AM, Daniel Crispell <dancrispell@gmail.com> wrote:
There currently exist a handful of libraries (python modules) within contrib/brl that are built as shared, even if "BUILD_SHARED_LIBS" is set to "off".   On Linux, this requires adding "-fPIC" to the compiler flags, since it is not possible (as far as I know) to link static libraries with position dependent code into a shared library.  (If the "-fPIC" flag is not manually added, the user will get linker errors when building the shared modules.)

In order to avoid the user having to manually add these flags, I was thinking of adding a new cmake option (BUILD_SHARED_PYTHON_MODULES?), which would automatically add the -fPIC option to CMAKE_CXX_FLAGS and CMAKE_C_FLAGS when enabled, and "UNIX" is true. 

I wanted to run this idea by the collective mind of the list before I went ahead with it because there may be implications of adding the -fPIC flag to static builds that I'm not aware of, or possibly a better way of accomplishing this that I haven't thought of.  Any thoughts?


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!

Vxl-maintainers mailing list