From: Tucker, D. <tu...@ly...> - 2015-05-11 22:00:40
|
I have tried version 1.14 and 1.17 and both fail with similar error just at different places. I'm trying to compile on centos 6.6 (64bit). gcc -v: gcc version 4.4.7 20120313 (Red Hat 4.4.7-11) (GCC) g++ -v: gcc version 4.4.7 20120313 (Red Hat 4.4.7-11) (GCC) I unzipped the zip file. Created a bin directory as noted in the instructions at the same level as unzipped source. cd to bin. Ran: cmake -i ../vxl-1.14.0 Then ran: make This last run it got to 78% and the error is here: [ 78%] Built target bbgm_pro [ 78%] Building CXX object contrib/brl/bseg/bbgm_batch/CMakeFiles/bbgm_batch.dir/reg_bbgm.o Linking CXX shared module ../../../../lib/bbgm_batch.so /usr/bin/ld: /usr/local/lib/libpython2.7.a(intobject.o): relocation R_X86_64_32S against `PyInt_Type' can not be used when making a shared object; recompile with -fPIC /usr/local/lib/libpython2.7.a: could not read symbols: Bad value collect2: ld returned 1 exit status make[2]: *** [lib/bbgm_batch.so] Error 1 make[1]: *** [contrib/brl/bseg/bbgm_batch/CMakeFiles/bbgm_batch.dir/all] Error 2 make: *** [all] Error 2 I tried exporting CFLAGS=-fPIC and then running make clean and then make again but got the same error. Any assistance would be greatly appreciated. -- Sincerely, Doug Tucker |
From: Matthew W. <mat...@ki...> - 2015-05-12 14:27:55
|
On 2015-05-11 17:26, Tucker, Doug wrote: > I have tried version 1.14 and 1.17 and both fail with similar error just > at different places. I'm trying to compile on centos 6.6 (64bit). > > [...] > This last run it got to 78% and the error is here: > > [ 78%] Built target bbgm_pro > [ 78%] Building CXX object > contrib/brl/bseg/bbgm_batch/CMakeFiles/bbgm_batch.dir/reg_bbgm.o > Linking CXX shared module ../../../../lib/bbgm_batch.so > /usr/bin/ld: /usr/local/lib/libpython2.7.a(intobject.o): relocation > R_X86_64_32S against `PyInt_Type' can not be used when making a shared > object; recompile with -fPIC > /usr/local/lib/libpython2.7.a: could not read symbols: Bad value > collect2: ld returned 1 exit status > make[2]: *** [lib/bbgm_batch.so] Error 1 > make[1]: *** [contrib/brl/bseg/bbgm_batch/CMakeFiles/bbgm_batch.dir/all] > Error 2 > make: *** [all] Error 2 > > I tried exporting CFLAGS=-fPIC and then running make clean and then make > again but got the same error. Any assistance would be greatly appreciated. You appear to be doing a shared build of VXL (which is good; I never recommend building static libraries). Because the libraries are shared, they are automatically PIC; specifying -fPIC while building *VXL* is thus superfluous. It looks like you are having problems because your locally built *Python* libraries (/usr/local/lib/libpython2.7.a) are not PIC. Can you rebuild *those* as shared and/or with -fPIC? (Is there a reason you cannot use the distro-provided python-devel?) -- Matthew |
From: Tucker, D. <tu...@ly...> - 2015-05-12 18:28:38
|
On 05/12/2015 09:28 AM, Matthew Woehlke wrote: > On 2015-05-11 17:26, Tucker, Doug wrote: >> I have tried version 1.14 and 1.17 and both fail with similar error just >> at different places. I'm trying to compile on centos 6.6 (64bit). >> >> [...] >> This last run it got to 78% and the error is here: >> >> [ 78%] Built target bbgm_pro >> [ 78%] Building CXX object >> contrib/brl/bseg/bbgm_batch/CMakeFiles/bbgm_batch.dir/reg_bbgm.o >> Linking CXX shared module ../../../../lib/bbgm_batch.so >> /usr/bin/ld: /usr/local/lib/libpython2.7.a(intobject.o): relocation >> R_X86_64_32S against `PyInt_Type' can not be used when making a shared >> object; recompile with -fPIC >> /usr/local/lib/libpython2.7.a: could not read symbols: Bad value >> collect2: ld returned 1 exit status >> make[2]: *** [lib/bbgm_batch.so] Error 1 >> make[1]: *** [contrib/brl/bseg/bbgm_batch/CMakeFiles/bbgm_batch.dir/all] >> Error 2 >> make: *** [all] Error 2 >> >> I tried exporting CFLAGS=-fPIC and then running make clean and then make >> again but got the same error. Any assistance would be greatly appreciated. > > You appear to be doing a shared build of VXL (which is good; I never > recommend building static libraries). Because the libraries are shared, > they are automatically PIC; specifying -fPIC while building *VXL* is > thus superfluous. > > It looks like you are having problems because your locally built > *Python* libraries (/usr/local/lib/libpython2.7.a) are not PIC. Can you > rebuild *those* as shared and/or with -fPIC? (Is there a reason you > cannot use the distro-provided python-devel?) > Thank you for responding. That's my puzzlement as well, how to get this to find and use the ones installed by python-devel? They are definitely there: [root@genuse38 bin]# rpm -ql python-devel | grep libpython /usr/lib64/libpython2.6.so /usr/lib64/python2.6/config/libpython2.6.so But everytime I run make it finds the one at /usr/local/lib. Any way around that? |
From: Matthew W. <mat...@ki...> - 2015-05-12 19:18:13
|
On 2015-05-12 14:28, Tucker, Doug wrote: > On 05/12/2015 09:28 AM, Matthew Woehlke wrote: >> It looks like you are having problems because your locally built >> *Python* libraries (/usr/local/lib/libpython2.7.a) are not PIC. Can you >> rebuild *those* as shared and/or with -fPIC? (Is there a reason you >> cannot use the distro-provided python-devel?) > > Thank you for responding. That's my puzzlement as well, how to get this > to find and use the ones installed by python-devel? They are definitely > there: > > [root@genuse38 bin]# rpm -ql python-devel | grep libpython > /usr/lib64/libpython2.6.so > /usr/lib64/python2.6/config/libpython2.6.so > > But everytime I run make it finds the one at /usr/local/lib. Any way > around that? /usr/local is one of the prefixes that is searched by default; I'm not sure offhand of an environmental way to exclude that but not /usr. (Maybe 'CMAKE_PREFIX_PATH=/usr'?) That of course assumes there aren't other things in /usr/local that you *want* (or need) to take precedence. Probably the easiest thing to do is run ccmake and change PYTHON_LIBRARY and PYTHON_INCLUDE_DIR by hand (they are advanced variables; you'll need to press 't' to see them). Or try this (in your build directory; similar effect): cmake . -DPYTHON_INCLUDE_DIR:PATH=/usr/include/python2.6 \ -DPYTHON_LIBRARY:FILEPATH=/usr/lib64/libpython2.6.so ...or you could of course remove that Python installation :-). Assuming those libraries/paths actually exist, they should persist once you specify them by hand until/unless you delete those variables (or the entire CMakeCache.txt). Hope that helps! -- Matthew |
From: Tucker, D. <tu...@ly...> - 2015-05-13 13:42:45
|
Thanks Matthew, I was able to just move the library from /usr/local while I ran this and it got past that. However very shortly I ran into a similar issue except this library doesn't even exist on the system yet it acts as if it is finding it. Note: Scanning dependencies of target bbgm_batch [ 78%] Building CXX object contrib/brl/bseg/bbgm_batch/CMakeFiles/bbgm_batch.dir/reg_bbgm.o Linking CXX shared module ../../../../lib/bbgm_batch.so /usr/bin/ld: ../../../../lib/libvil_io.a(vil_io_smart_ptr+vil_memory_chunk-.o): relocation R_X86_64_32 against `.bss' can not be used when making a shared object; recompile with -fPIC ../../../../lib/libvil_io.a: could not read symbols: Bad value collect2: ld returned 1 exit status make[2]: *** [lib/bbgm_batch.so] Error 1 make[1]: *** [contrib/brl/bseg/bbgm_batch/CMakeFiles/bbgm_batch.dir/all] Error 2 make: *** [all] Error 2 I did a yum whatprovides */libvil_io.a and it came back nothing found. Any ideas? Sincerely, Doug Tucker On 05/12/2015 02:18 PM, Matthew Woehlke wrote: > On 2015-05-12 14:28, Tucker, Doug wrote: >> On 05/12/2015 09:28 AM, Matthew Woehlke wrote: >>> It looks like you are having problems because your locally built >>> *Python* libraries (/usr/local/lib/libpython2.7.a) are not PIC. Can you >>> rebuild *those* as shared and/or with -fPIC? (Is there a reason you >>> cannot use the distro-provided python-devel?) >> >> Thank you for responding. That's my puzzlement as well, how to get this >> to find and use the ones installed by python-devel? They are definitely >> there: >> >> [root@genuse38 bin]# rpm -ql python-devel | grep libpython >> /usr/lib64/libpython2.6.so >> /usr/lib64/python2.6/config/libpython2.6.so >> >> But everytime I run make it finds the one at /usr/local/lib. Any way >> around that? > > /usr/local is one of the prefixes that is searched by default; I'm not > sure offhand of an environmental way to exclude that but not /usr. > (Maybe 'CMAKE_PREFIX_PATH=/usr'?) That of course assumes there aren't > other things in /usr/local that you *want* (or need) to take precedence. > > Probably the easiest thing to do is run ccmake and change PYTHON_LIBRARY > and PYTHON_INCLUDE_DIR by hand (they are advanced variables; you'll need > to press 't' to see them). Or try this (in your build directory; similar > effect): > > cmake . -DPYTHON_INCLUDE_DIR:PATH=/usr/include/python2.6 \ > -DPYTHON_LIBRARY:FILEPATH=/usr/lib64/libpython2.6.so > > ...or you could of course remove that Python installation :-). > > Assuming those libraries/paths actually exist, they should persist once > you specify them by hand until/unless you delete those variables (or the > entire CMakeCache.txt). > > Hope that helps! > |
From: Matthew W. <mat...@ki...> - 2015-05-13 13:54:23
|
On 2015-05-13 09:42, Tucker, Doug wrote: > I did a yum whatprovides */libvil_io.a and it came back nothing found. > Any ideas? libvil_io is a VXL artifact. (I'm familiar enough with VXL to just know this offhand, but you may also notice it has the same location on disk - the relative path '../../../../lib' - as the library - bbgm_batch.so - you are trying to build.) I'd guess you have leftover build artifacts from a previous, static build. That can happen some times, as 'make clean' only removes files that it knows are built; if you make changes to your build configuration and re-run cmake before doing a 'make clean', it can miss some things. I would recommend removing everything in your build directory *except* the CMakeCache.txt. Then re-run 'cmake' and try again. -- Matthew |
From: Tucker, D. <tu...@ly...> - 2015-05-13 13:58:17
|
This is my first run at vxl, and I must say I haven't had this much difficulty trying to compile something in years. Actually, I started with a totally clean slate. I deleted everything, unzipped from scratch and started again. Sincerely, Doug Tucker On 05/13/2015 08:54 AM, Matthew Woehlke wrote: > On 2015-05-13 09:42, Tucker, Doug wrote: >> I did a yum whatprovides */libvil_io.a and it came back nothing found. >> Any ideas? > > libvil_io is a VXL artifact. (I'm familiar enough with VXL to just know > this offhand, but you may also notice it has the same location on disk - > the relative path '../../../../lib' - as the library - bbgm_batch.so - > you are trying to build.) > > I'd guess you have leftover build artifacts from a previous, static > build. That can happen some times, as 'make clean' only removes files > that it knows are built; if you make changes to your build configuration > and re-run cmake before doing a 'make clean', it can miss some things. > > I would recommend removing everything in your build directory *except* > the CMakeCache.txt. Then re-run 'cmake' and try again. > |
From: Wheeler, F. W (GE G. Research) <wh...@ge...> - 2015-05-13 15:19:00
|
Perhaps you do not need the particular library that is failing to build. You could make -k to build everything else. Fred Wheeler > -----Original Message----- > From: Matthew Woehlke [mailto:mat...@ki...] > Sent: Wednesday, May 13, 2015 11:17 AM > To: Tucker, Doug; vxl...@li... > Subject: Re: [Vxl-users] can't compile vxl > > On 2015-05-13 09:58, Tucker, Doug wrote: > > This is my first run at vxl, and I must say I haven't had this much > > difficulty trying to compile something in years. > > I'm sorry to hear that... For what it's worth, I believe your experience is > atypical. > > > Actually, I started with a totally clean slate. I deleted everything, > > unzipped from scratch and started again. > > Are you building shared (BUILD_SHARED_LIBS:BOOL=ON)? If not, I would try > that (for some reason, CMake defaults to static builds). It may be that > building static VXL is broken. > > -- > Matthew > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > Vxl-users mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-users |
From: Matthew W. <mat...@ki...> - 2015-05-13 15:28:42
|
On 2015-05-13 11:18, Wheeler, Frederick W (GE Global Research) wrote: > Perhaps you do not need the particular library that is failing to build. You could make -k to build everything else. That's a good point; some of the "peripheral" modules aren't necessarily as well maintained as the core. @Doug, I would consider turning off all of the BUILD_* that you don't expect to need. You might even try turning off *everything* except BUILD_CORE_* - which hopefully will get you to a successful build - and then turn things back on one at a time, which will help to isolate problem spots. BTW, I don't build BRL (BUILD_BRL:BOOL=OFF), so I can't speak to whether or not it works for me, either :-). (In fact, I tried turning it on just now, and it doesn't even configure... So that module may well be broken.) -- Matthew |
From: Tucker, D. <tu...@ly...> - 2015-05-13 14:51:49
|
So I downloaded the 1.17 version and it fails with this exact same error from a scratch build. I'm stumped and not sure where to go from here. Sincerely, Doug Tucker On 05/13/2015 08:54 AM, Matthew Woehlke wrote: > On 2015-05-13 09:42, Tucker, Doug wrote: >> I did a yum whatprovides */libvil_io.a and it came back nothing found. >> Any ideas? > > libvil_io is a VXL artifact. (I'm familiar enough with VXL to just know > this offhand, but you may also notice it has the same location on disk - > the relative path '../../../../lib' - as the library - bbgm_batch.so - > you are trying to build.) > > I'd guess you have leftover build artifacts from a previous, static > build. That can happen some times, as 'make clean' only removes files > that it knows are built; if you make changes to your build configuration > and re-run cmake before doing a 'make clean', it can miss some things. > > I would recommend removing everything in your build directory *except* > the CMakeCache.txt. Then re-run 'cmake' and try again. > |
From: Matthew W. <mat...@ki...> - 2015-05-13 15:16:54
|
On 2015-05-13 09:58, Tucker, Doug wrote: > This is my first run at vxl, and I must say I haven't had this much > difficulty trying to compile something in years. I'm sorry to hear that... For what it's worth, I believe your experience is atypical. > Actually, I started with a totally clean slate. I deleted everything, > unzipped from scratch and started again. Are you building shared (BUILD_SHARED_LIBS:BOOL=ON)? If not, I would try that (for some reason, CMake defaults to static builds). It may be that building static VXL is broken. -- Matthew |
From: Tucker, D. <tu...@ly...> - 2015-05-13 17:10:15
|
That did it! Thank you! Sincerely, Doug Tucker On 05/13/2015 10:16 AM, Matthew Woehlke wrote: > On 2015-05-13 09:58, Tucker, Doug wrote: >> This is my first run at vxl, and I must say I haven't had this much >> difficulty trying to compile something in years. > > I'm sorry to hear that... For what it's worth, I believe your experience > is atypical. > >> Actually, I started with a totally clean slate. I deleted everything, >> unzipped from scratch and started again. > > Are you building shared (BUILD_SHARED_LIBS:BOOL=ON)? If not, I would try > that (for some reason, CMake defaults to static builds). It may be that > building static VXL is broken. > |