From: YULianqing <yu...@li...> - 2012-06-05 16:42:57
|
Dear all, I'm glad to introduce the second release candidate (RC2) of VXL 1.17.0 for you to test. The main change to RC2 compared to RC1 is the inclusion of dcrispell's fix to remove cyclic dependency issue in the case of shared libary build. Please feel free to give me comments and suggestions. regards,Lianqing Yu |
From: Mathieu M. <mat...@gm...> - 2012-06-05 17:24:32
|
Here are 3 easy ones: 1. /usr/bin/c++ -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wl,--as-needed CMakeFiles/mcal_test_all.dir/test_driver.o CMakeFiles/mcal_test_all.dir/test_pca.o CMakeFiles/mcal_test_all.dir/test_trivial_ca.o CMakeFiles/mcal_test_all.dir/test_general_ca.o -o mcal_test_all -rdynamic -lmul_mcal ../../../../lib/libvnl.so.1.14.0 ../../../../lib/libtestlib.so.1.14.0 ../../../../lib/libvcl.so.1.14.0 -lm -Wl,-rpath,/home/mathieu/debian/debian-med/trunk/packages/vxl/trunk/vxl-1.17.0/obj-x86_64-linux-gnu/lib /usr/bin/ld: CMakeFiles/mcal_test_all.dir/test_pca.o: undefined reference to symbol '_Z22vsl_delete_all_loadersv' /usr/bin/ld: note: '_Z22vsl_delete_all_loadersv' is defined in DSO /home/mathieu/debian/debian-med/trunk/packages/vxl/trunk/vxl-1.17.0/obj-x86_64-linux-gnu/lib/libvsl.so.1.14 so try adding it to the linker command line 2. /home/mathieu/debian/debian-med/trunk/packages/vxl/trunk/vxl-1.17.0/contrib/brl/bbas/baio/baio_unix.cxx: In member function 'void baio::close_file()': /home/mathieu/debian/debian-med/trunk/packages/vxl/trunk/vxl-1.17.0/contrib/brl/bbas/baio/baio_unix.cxx:103:35: error: 'close' was not declared in this scopemake[2]: [contrib/brl/bbas/baio/CMakeFiles/baio.dir/baio_unix.o] Error 1 (ignored) Linking CXX shared library ../../../../lib/libbaio.so 3. /usr/bin/c++ -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wl,--as-needed CMakeFiles/icam_test_all.dir/test_driver.o CMakeFiles/icam_test_all.dir/test_minimizer.o CMakeFiles/icam_test_all.dir/test_icam_transform.o CMakeFiles/icam_test_all.dir/test_rotation_only.o -o icam_test_all -rdynamic ../../../../../../lib/libicam.so ../../../../../../lib/libvgl_algo.so.1.14.0 ../../../../../../lib/libvgl.so.1.14.0 ../../../../../../lib/libvnl.so.1.14.0 ../../../../../../lib/libvil.so.1.14.0 ../../../../../../lib/libvul.so.1.14.0 ../../../../../../lib/libtestlib.so.1.14.0 ../../../../../../lib/libvsph.so ../../../../../../lib/libbpgl_algo.so ../../../../../../lib/libbpgl.so ../../../../../../lib/libbrip.so.1.14.0 ../../../../../../lib/libgevd.so.1.14.0 ../../../../../../lib/libvtol.so.1.14.0 ../../../../../../lib/libvdgl.so.1.14.0 ../../../../../../lib/libbsta.so.1.14.0 ../../../../../../lib/libbsol.so.1.14.0 ../../../../../../lib/libvil1.so.1.14.0 ../../../../../../lib/libbil_algo.so.1.14.0 ../../../../../../lib/libvsol.so.1.14.0 ../../../../../../lib/librrel.so ../../../../../../lib/libvpgl_io.so ../../../../../../lib/libvnl_io.so.1.14.0 ../../../../../../lib/libvpgl_algo.so ../../../../../../lib/libvpgl_file_formats.so ../../../../../../lib/libvpgl.so ../../../../../../lib/libvgl_algo.so.1.14.0 ../../../../../../lib/libvul.so.1.14.0 ../../../../../../lib/libvil_algo.so.1.14.0 ../../../../../../lib/libvil.so.1.14.0 -ljpeg -ltiff -lgeotiff -lpng ../../../../../../lib/libdcmtk.so.1.14.0 -lz ../../../../../../lib/libopenjpeg2.so.2.0.0 ../../../../../../lib/libvnl_algo.so.1.14.0 ../../../../../../lib/libvnl.so.1.14.0 ../../../../../../lib/libnetlib.so.1.14.0 ../../../../../../lib/libv3p_netlib.so.1.14.0 ../../../../../../lib/libvgl_io.so.1.14.0 ../../../../../../lib/libvgl.so.1.14.0 ../../../../../../lib/libvbl_io.so.1.14.0 ../../../../../../lib/libvsl.so.1.14.0 ../../../../../../lib/libvbl.so.1.14.0 ../../../../../../lib/libvcl.so.1.14.0 -lm -Wl,-rpath,/home/mathieu/debian/debian-med/trunk/packages/vxl/trunk/vxl-1.17.0/obj-x86_64-linux-gnu/lib ../../../../../../lib/libicam.so: undefined reference to `vnl_numeric_traits<double>::maxval' collect2: error: ld returned 1 exit status make[2]: [contrib/brl/bbas/bpgl/icam/tests/icam_test_all] Error 1 (ignored) Thanks On Tue, Jun 5, 2012 at 6:42 PM, YULianqing <yu...@li...> wrote: > Dear all, > > I'm glad to introduce the second release candidate (RC2) of VXL 1.17.0 for > you to test. The main change to RC2 compared to RC1 is the inclusion of > dcrispell's fix to remove cyclic dependency issue in the case of shared > libary build. Please feel free to give me comments and suggestions. > > regards, > Lianqing Yu > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > -- Mathieu |
From: YULianqing <yu...@li...> - 2012-06-07 14:56:37
|
Hi Mathieu, I'm sorry that there are build issues of VXL 1.17.0 RC2 in your configuration. To be frankly, given the fact that more than half of VXL nightly builds are submitted from Linux machines, I did not expect such issues. Our machines run CentOS 5.x and I have successfully build RC2 on two machines, covering the combinations of static/shared library, x86_64/i386. Unfortunately, we have no debian machines on hand and cannot replicate your errors for now. The exact Linux distribution cannot be determined by the build names on VXL dashboard and I hope there are debian machines out there. Some maintainers on this list are also kind enough and may come in and help fix this error.I also take a look at source file core/vnl/vnl_numeric_traits.h and core/vnl/vnl_numeric_traits.cxx, and do not find anything wrong with the definition of maxval. I guess the issue may result from CMake configuration and it is may be of help if you post your CMakeCache.txt to this list. Lianqing Yu> From: mat...@gm... > Date: Tue, 5 Jun 2012 19:24:05 +0200 > Subject: Re: [Vxl-maintainers] VXL 1.17.0 Release Candicate 2 is available > To: yu...@li... > CC: vxl...@li...; vxl...@li... > > Here are 3 easy ones: > > 1. > /usr/bin/c++ -g -O2 -fstack-protector --param=ssp-buffer-size=4 > -Wformat -Werror=format-security -Wl,--as-needed > CMakeFiles/mcal_test_all.dir/test_driver.o > CMakeFiles/mcal_test_all.dir/test_pca.o > CMakeFiles/mcal_test_all.dir/test_trivial_ca.o > CMakeFiles/mcal_test_all.dir/test_general_ca.o -o mcal_test_all > -rdynamic -lmul_mcal ../../../../lib/libvnl.so.1.14.0 > ../../../../lib/libtestlib.so.1.14.0 ../../../../lib/libvcl.so.1.14.0 > -lm -Wl,-rpath,/home/mathieu/debian/debian-med/trunk/packages/vxl/trunk/vxl-1.17.0/obj-x86_64-linux-gnu/lib > /usr/bin/ld: CMakeFiles/mcal_test_all.dir/test_pca.o: undefined > reference to symbol '_Z22vsl_delete_all_loadersv' > /usr/bin/ld: note: '_Z22vsl_delete_all_loadersv' is defined in DSO > /home/mathieu/debian/debian-med/trunk/packages/vxl/trunk/vxl-1.17.0/obj-x86_64-linux-gnu/lib/libvsl.so.1.14 > so try adding it to the linker command line > > > 2. > /home/mathieu/debian/debian-med/trunk/packages/vxl/trunk/vxl-1.17.0/contrib/brl/bbas/baio/baio_unix.cxx: > In member function 'void baio::close_file()': > /home/mathieu/debian/debian-med/trunk/packages/vxl/trunk/vxl-1.17.0/contrib/brl/bbas/baio/baio_unix.cxx:103:35: > error: 'close' was not declared in this scopemake[2]: > [contrib/brl/bbas/baio/CMakeFiles/baio.dir/baio_unix.o] Error 1 > (ignored) > Linking CXX shared library ../../../../lib/libbaio.so > > 3. > /usr/bin/c++ -g -O2 -fstack-protector --param=ssp-buffer-size=4 > -Wformat -Werror=format-security -Wl,--as-needed > CMakeFiles/icam_test_all.dir/test_driver.o > CMakeFiles/icam_test_all.dir/test_minimizer.o > CMakeFiles/icam_test_all.dir/test_icam_transform.o > CMakeFiles/icam_test_all.dir/test_rotation_only.o -o icam_test_all > -rdynamic ../../../../../../lib/libicam.so > ../../../../../../lib/libvgl_algo.so.1.14.0 > ../../../../../../lib/libvgl.so.1.14.0 > ../../../../../../lib/libvnl.so.1.14.0 > ../../../../../../lib/libvil.so.1.14.0 > ../../../../../../lib/libvul.so.1.14.0 > ../../../../../../lib/libtestlib.so.1.14.0 > ../../../../../../lib/libvsph.so ../../../../../../lib/libbpgl_algo.so > ../../../../../../lib/libbpgl.so > ../../../../../../lib/libbrip.so.1.14.0 > ../../../../../../lib/libgevd.so.1.14.0 > ../../../../../../lib/libvtol.so.1.14.0 > ../../../../../../lib/libvdgl.so.1.14.0 > ../../../../../../lib/libbsta.so.1.14.0 > ../../../../../../lib/libbsol.so.1.14.0 > ../../../../../../lib/libvil1.so.1.14.0 > ../../../../../../lib/libbil_algo.so.1.14.0 > ../../../../../../lib/libvsol.so.1.14.0 > ../../../../../../lib/librrel.so ../../../../../../lib/libvpgl_io.so > ../../../../../../lib/libvnl_io.so.1.14.0 > ../../../../../../lib/libvpgl_algo.so > ../../../../../../lib/libvpgl_file_formats.so > ../../../../../../lib/libvpgl.so > ../../../../../../lib/libvgl_algo.so.1.14.0 > ../../../../../../lib/libvul.so.1.14.0 > ../../../../../../lib/libvil_algo.so.1.14.0 > ../../../../../../lib/libvil.so.1.14.0 -ljpeg -ltiff -lgeotiff -lpng > ../../../../../../lib/libdcmtk.so.1.14.0 -lz > ../../../../../../lib/libopenjpeg2.so.2.0.0 > ../../../../../../lib/libvnl_algo.so.1.14.0 > ../../../../../../lib/libvnl.so.1.14.0 > ../../../../../../lib/libnetlib.so.1.14.0 > ../../../../../../lib/libv3p_netlib.so.1.14.0 > ../../../../../../lib/libvgl_io.so.1.14.0 > ../../../../../../lib/libvgl.so.1.14.0 > ../../../../../../lib/libvbl_io.so.1.14.0 > ../../../../../../lib/libvsl.so.1.14.0 > ../../../../../../lib/libvbl.so.1.14.0 > ../../../../../../lib/libvcl.so.1.14.0 -lm > -Wl,-rpath,/home/mathieu/debian/debian-med/trunk/packages/vxl/trunk/vxl-1.17.0/obj-x86_64-linux-gnu/lib > ../../../../../../lib/libicam.so: undefined reference to > `vnl_numeric_traits<double>::maxval' > collect2: error: ld returned 1 exit status > make[2]: [contrib/brl/bbas/bpgl/icam/tests/icam_test_all] Error 1 (ignored) > > > Thanks > > On Tue, Jun 5, 2012 at 6:42 PM, YULianqing <yu...@li...> wrote: > > Dear all, > > > > I'm glad to introduce the second release candidate (RC2) of VXL 1.17.0 for > > you to test. The main change to RC2 compared to RC1 is the inclusion of > > dcrispell's fix to remove cyclic dependency issue in the case of shared > > libary build. Please feel free to give me comments and suggestions. > > > > regards, > > Lianqing Yu > > > > ------------------------------------------------------------------------------ > > Live Security Virtual Conference > > Exclusive live event will cover all the ways today's security and > > threat landscape has changed and how IT managers can respond. Discussions > > will include endpoint security, mobile security and the latest in malware > > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > _______________________________________________ > > Vxl-maintainers mailing list > > Vxl...@li... > > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > > > > > > -- > Mathieu |
From: Sean M. <se...@ro...> - 2012-06-05 19:04:06
|
On Wed, 6 Jun 2012 00:42:51 +0800, YULianqing said: >Dear all, I'm glad to introduce the second release candidate (RC2) of >VXL 1.17.0 for you to test. The main change to RC2 compared to RC1 is >the inclusion of dcrispell's fix to remove cyclic dependency issue in >the case of shared libary build. Please feel free to give me comments >and suggestions. URL? -- ____________________________________________________________ Sean McBride, B. Eng se...@ro... Rogue Research www.rogue-research.com Mac Software Developer Montréal, Québec, Canada |
From: YULianqing <yu...@li...> - 2012-06-06 22:38:55
|
It's here: http://sourceforge.net/projects/vxl/files/vxl/1.17b/. > From: se...@ro... > To: yu...@li...; vxl...@li...; vxl...@li... > Subject: Re: [Vxl-users] VXL 1.17.0 Release Candicate 2 is available > Date: Tue, 5 Jun 2012 15:03:51 -0400 > > On Wed, 6 Jun 2012 00:42:51 +0800, YULianqing said: > > >Dear all, I'm glad to introduce the second release candidate (RC2) of > >VXL 1.17.0 for you to test. The main change to RC2 compared to RC1 is > >the inclusion of dcrispell's fix to remove cyclic dependency issue in > >the case of shared libary build. Please feel free to give me comments > >and suggestions. > > URL? > > -- > ____________________________________________________________ > Sean McBride, B. Eng se...@ro... > Rogue Research www.rogue-research.com > Mac Software Developer Montréal, Québec, Canada > > |
From: Mathieu M. <mat...@gm...> - 2012-06-06 14:08:54
|
On Tue, Jun 5, 2012 at 6:42 PM, YULianqing <yu...@li...> wrote: > I'm glad to introduce the second release candidate (RC2) of VXL 1.17.0 for > you to test. The main change to RC2 compared to RC1 is the inclusion of > dcrispell's fix to remove cyclic dependency issue in the case of shared > libary build. Please feel free to give me comments and suggestions. I cannot run 'make Experimental'. It seems one of the test take so much memory it even kills ctest itself: [...] -gnu/lib/libvsol.so.1.17.0 2b152fb41000-2b152fbcd000 r-xp 00000000 00:10 15880610 /home/mathieu/debian/debian-med/trunk/packages/vxl/trunk/vxl-1.17.0/obj-x86_64-linux-gnu/lib/libvgl_algo.so.1.17.0790/901 Test #790: bvxm_pro_test_create_local_rpc_process ...............***Exception: Other 0.02 sec Start 791: bvxm_pro_test_create_synth_lidar_data_process 791/901 Test #791: bvxm_pro_test_create_synth_lidar_data_process ........ Passed 0.04 sec Start 792: bvxm_pro_test_update_lidar_process 792/901 Test #792: bvxm_pro_test_update_lidar_process ................... Passed 0.83 sec Start 793: bvxm_algo_test_merge_mog 793/901 Test #793: bvxm_algo_test_merge_mog ............................. Passed 0.39 sec Start 794: bvxm_algo_test_mog_norm 794/901 Test #794: bvxm_algo_test_mog_norm .............................. Passed 0.02 sec Start 795: bvxm_algo_test_boxm_scene_to_bvxm_grid terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc make[3]: *** [CMakeFiles/Experimental] Aborted make[3]: Leaving directory `/home/mathieu/debian/debian-med/trunk/packages/vxl/trunk/vxl-1.17.0/obj-x86_64-linux-gnu' make[2]: *** [CMakeFiles/Experimental.dir/all] Error 2 make[2]: Leaving directory `/home/mathieu/debian/debian-med/trunk/packages/vxl/trunk/vxl-1.17.0/obj-x86_64-linux-gnu' make[1]: *** [CMakeFiles/Experimental.dir/rule] Error 2 make[1]: Leaving directory `/home/mathieu/debian/debian-med/trunk/packages/vxl/trunk/vxl-1.17.0/obj-x86_64-linux-gnu' make: *** [Experimental] Error 2 [...] I cannot see my desktop 'lirispat' showing up on the dashboard page. Thanks -- Mathieu |
From: Ian S. <sc...@im...> - 2012-06-06 15:39:06
|
On 05/06/2012 18:24, Mathieu Malaterre wrote: > Here are 3 easy ones: > > 1. > /usr/bin/c++ -g -O2 -fstack-protector --param=ssp-buffer-size=4 > -Wformat -Werror=format-security -Wl,--as-needed > CMakeFiles/mcal_test_all.dir/test_driver.o > CMakeFiles/mcal_test_all.dir/test_pca.o > CMakeFiles/mcal_test_all.dir/test_trivial_ca.o > CMakeFiles/mcal_test_all.dir/test_general_ca.o -o mcal_test_all > -rdynamic -lmul_mcal ../../../../lib/libvnl.so.1.14.0 > ../../../../lib/libtestlib.so.1.14.0 ../../../../lib/libvcl.so.1.14.0 > -lm -Wl,-rpath,/home/mathieu/debian/debian-med/trunk/packages/vxl/trunk/vxl-1.17.0/obj-x86_64-linux-gnu/lib > /usr/bin/ld: CMakeFiles/mcal_test_all.dir/test_pca.o: undefined > reference to symbol '_Z22vsl_delete_all_loadersv' > /usr/bin/ld: note: '_Z22vsl_delete_all_loadersv' is defined in DSO > /home/mathieu/debian/debian-med/trunk/packages/vxl/trunk/vxl-1.17.0/obj-x86_64-linux-gnu/lib/libvsl.so.1.14 > so try adding it to the linker command line Well, I don't know about easy - I can't even replicate it. However, looking at the CMakeLists.txt files for several contrib/mul libraries, I found some unnecessary and potentially confounding TARGET_LINK_LIBRARIES dependency entries. I have removed these and committed as revision Matthieu, if you can check this fixes your problem before Lianqing attempts another RC, then I'm sure he would be grateful. Regards, Ian. |
From: Mathieu M. <mat...@gm...> - 2012-06-06 15:51:21
Attachments:
run.sh
trunk.patch
|
Hi Ian, On Wed, Jun 6, 2012 at 5:12 PM, Ian Scott <sc...@im...> wrote: > Well, I don't know about easy - I can't even replicate it. > However, looking at the CMakeLists.txt files for several contrib/mul > libraries, I found some unnecessary and potentially confounding > TARGET_LINK_LIBRARIES dependency entries. I have removed these and committed > as revision > > Matthieu, if you can check this fixes your problem before Lianqing attempts > another RC, then I'm sure he would be grateful. If you get your hand on a debian/sid system - the major difference from another linux system will be the use of gcc-4.7 as default compiler -, you then apply trunk.patch. You can now run 'run.sh'. You should get to: make[2]: Entering directory `/home/mathieu/debian/debian-med/trunk/packages/vxl/trunk/vxl/bin' Linking CXX executable icam_test_all cd /home/mathieu/debian/debian-med/trunk/packages/vxl/trunk/vxl/bin/contrib/brl/bbas/bpgl/icam/tests && /usr/bin/cmake -E cmake_link_script CMakeFiles/icam_test_all.dir/link.txt --verbose=1 /usr/bin/c++ -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wl,--as-needed CMakeFiles/icam_test_all.dir/test_driver.o CMakeFiles/icam_test_all.dir/test_minimizer.o CMakeFiles/icam_test_all.dir/test_icam_transform.o CMakeFiles/icam_test_all.dir/test_rotation_only.o -o icam_test_all -rdynamic ../../../../../../lib/libicam.so ../../../../../../lib/libvgl_algo.so ../../../../../../lib/libvgl.so ../../../../../../lib/libvnl.so ../../../../../../lib/libvil.so ../../../../../../lib/libvul.so ../../../../../../lib/libtestlib.so ../../../../../../lib/libvsph.so ../../../../../../lib/libbpgl_algo.so ../../../../../../lib/libbpgl.so ../../../../../../lib/libbrip.so ../../../../../../lib/libgevd.so ../../../../../../lib/libvtol.so ../../../../../../lib/libvdgl.so ../../../../../../lib/libbsta.so ../../../../../../lib/libbsol.so ../../../../../../lib/libvil1.so ../../../../../../lib/libbil_algo.so ../../../../../../lib/libvsol.so ../../../../../../lib/librrel.so ../../../../../../lib/libvpgl_io.so ../../../../../../lib/libvnl_io.so ../../../../../../lib/libvpgl_algo.so ../../../../../../lib/libvpgl_file_formats.so ../../../../../../lib/libvpgl.so ../../../../../../lib/libvgl_algo.so ../../../../../../lib/libvul.so ../../../../../../lib/libvil_algo.so ../../../../../../lib/libvil.so -ljpeg -ltiff -lgeotiff -lpng ../../../../../../lib/libdcmtk.so -lz ../../../../../../lib/libopenjpeg2.so.2.0.0 ../../../../../../lib/libvnl_algo.so ../../../../../../lib/libvnl.so ../../../../../../lib/libnetlib.so ../../../../../../lib/libv3p_netlib.so ../../../../../../lib/libvgl_io.so ../../../../../../lib/libvgl.so ../../../../../../lib/libvbl_io.so ../../../../../../lib/libvsl.so ../../../../../../lib/libvbl.so ../../../../../../lib/libvcl.so -lm -Wl,-rpath,/home/mathieu/debian/debian-med/trunk/packages/vxl/trunk/vxl/bin/lib ../../../../../../lib/libicam.so: undefined reference to `vnl_numeric_traits<double>::maxval' collect2: error: ld returned 1 exit status make[2]: *** [contrib/brl/bbas/bpgl/icam/tests/icam_test_all] Error 1 make[2]: Leaving directory `/home/mathieu/debian/debian-med/trunk/packages/vxl/trunk/vxl/bin' make[1]: *** [contrib/brl/bbas/bpgl/icam/tests/CMakeFiles/icam_test_all.dir/all] Error 2 make[1]: Leaving directory `/home/mathieu/debian/debian-med/trunk/packages/vxl/trunk/vxl/bin' make: *** [all] Error 2 HTH -- Mathieu |
From: Ian S. <sc...@im...> - 2012-06-06 16:12:11
|
On 06/06/2012 16:50, Mathieu Malaterre wrote: > Hi Ian, > > On Wed, Jun 6, 2012 at 5:12 PM, Ian Scott<sc...@im...> wrote: >> Well, I don't know about easy - I can't even replicate it. >> However, looking at the CMakeLists.txt files for several contrib/mul >> libraries, I found some unnecessary and potentially confounding >> TARGET_LINK_LIBRARIES dependency entries. I have removed these and committed >> as revision >> >> Matthieu, if you can check this fixes your problem before Lianqing attempts >> another RC, then I'm sure he would be grateful. > > If you get your hand on a debian/sid system - the major difference > from another linux system will be the use of gcc-4.7 as default > compiler -, you then apply trunk.patch. You can now run 'run.sh'. You > should get to: Matthieu, I don't have time to set up a debian system (virtual or otherwise) - and gcc 4.7 is not one of my standard compilers. It isn't my code - I was just offering a possible fix. Sorry. Ian. |
From: Antonio G. C. <A.G...@de...> - 2012-06-08 07:42:59
|
Hi Matthieu, I dont have a gcc-4.7 compiler, and I am not sure about where is this error coming from, but my two cents: When I have found these problems in vxl, the error was related to compiling with std-c++11. (in your compiler, with -std=c++0x) If you see the definition of VCL_CAN_STATIC_CONST_INIT_FLOAT, you will found that the definition depends on the compiler, and in debian, depends on the version of gnu-c++. Note that in c++-03, this work fine because the object is defined and initialized in the cxx file (http://www2.research.att.com/~bs/bs_faq2.html#in-class), but in case of c++11, any static member of ||const literal type can have an initialiser in the class definition (if you do not use the "adress" of the object), then the object could be defined in the cxx file, while is initialized in the class. When could you find this error? For example, if you compile a library with stdc++11 option on, then, VCL_CAN_STATIC_CONST_INIT_FLOAT will be compiled such that in the cxx file (translation unit) you have only the definition and not the initialization. Then, your programs must be compiled with the same option, in order to include that initialization in the class, to let the compiler to use directly the value inline. Is this your source of errors? I don't know, but it could help to understand what is wrong. Antonio. El 06/06/12 18:12, Ian Scott escribió: > On 06/06/2012 16:50, Mathieu Malaterre wrote: >> Hi Ian, >> >> On Wed, Jun 6, 2012 at 5:12 PM, Ian Scott<sc...@im...> wrote: >>> Well, I don't know about easy - I can't even replicate it. >>> However, looking at the CMakeLists.txt files for several contrib/mul >>> libraries, I found some unnecessary and potentially confounding >>> TARGET_LINK_LIBRARIES dependency entries. I have removed these and committed >>> as revision >>> >>> Matthieu, if you can check this fixes your problem before Lianqing attempts >>> another RC, then I'm sure he would be grateful. >> If you get your hand on a debian/sid system - the major difference >> from another linux system will be the use of gcc-4.7 as default >> compiler -, you then apply trunk.patch. You can now run 'run.sh'. You >> should get to: > Matthieu, > > I don't have time to set up a debian system (virtual or otherwise) - and > gcc 4.7 is not one of my standard compilers. It isn't my code - I was > just offering a possible fix. Sorry. > > Ian. > > > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers |
From: Brooksby, G. W (GE G. Research) <bro...@ge...> - 2012-06-08 19:27:16
|
Lianqing, thanks for your efforts in assembling the next VXL release (candidate). Is there a target date for releasing v1.17.0? The latest release available on sourceforge is 1.14.0. There are some significant changes between v1.14.0 and v1.17.0 which will entail changes to our internal code base and we want to plan for the change. Thanks, Glen Brooksby From: YULianqing [mailto:yu...@li...] Sent: Tuesday, June 05, 2012 12:43 PM To: vxl...@li...; vxl...@li... Subject: [Vxl-users] VXL 1.17.0 Release Candicate 2 is available Dear all, I'm glad to introduce the second release candidate (RC2) of VXL 1.17.0 for you to test. The main change to RC2 compared to RC1 is the inclusion of dcrispell's fix to remove cyclic dependency issue in the case of shared libary build. Please feel free to give me comments and suggestions. regards, Lianqing Yu |
From: YULianqing <yu...@li...> - 2012-06-08 23:17:18
|
Hi Glen, We planned to make a new release before this June, but took too much time to remove the dashboard build errors. So the planned date is actually put off. As you can see from this post, a couple of testers report build errors in RC2, even if there is no build errors in all submissions in the dashboard. Nonetheless, we tried to make a new release before the end of this month. Given the help from the warm-hearted maintainers of this list, I hope we can acomplish this goal. Best regards,Lianqing YuSubject: RE: [Vxl-users] VXL 1.17.0 Release Candicate 2 is available Date: Fri, 8 Jun 2012 15:26:06 -0400 From: bro...@ge... To: yu...@li...; vxl...@li...; vxl...@li... Lianqing, thanks for your efforts in assembling the next VXL release (candidate).Is there a target date for releasing v1.17.0? The latest release available on sourceforge is 1.14.0. There are some significant changes between v1.14.0 and v1.17.0 which will entail changes to our internal code base and we want to plan for the change. Thanks, Glen Brooksby From: YULianqing [mailto:yu...@li...] Sent: Tuesday, June 05, 2012 12:43 PM To: vxl...@li...; vxl...@li... Subject: [Vxl-users] VXL 1.17.0 Release Candicate 2 is available Dear all, I'm glad to introduce the second release candidate (RC2) of VXL 1.17.0 for you to test. The main change to RC2 compared to RC1 is the inclusion of dcrispell's fix to remove cyclic dependency issue in the case of shared libary build. Please feel free to give me comments and suggestions. regards, Lianqing Yu |
From: Sean M. <se...@ro...> - 2012-06-08 19:38:06
|
On Wed, 6 Jun 2012 00:42:51 +0800, YULianqing said: >Dear all, I'm glad to introduce the second release candidate (RC2) of >VXL 1.17.0 for you to test. The main change to RC2 compared to RC1 is >the inclusion of dcrispell's fix to remove cyclic dependency issue in >the case of shared libary build. Please feel free to give me comments >and suggestions. So I downloaded and tried to use cmake to do an out-of-source build. After I 'configure', with default options, it gives an error: "bvpl_octree using pthreads". That's not a very helpful message... What does it mean? Nevertheless, I proceeded to 'generate' and compile (with clang). I get a million warnings like this: warning: in-class initializer for static data member of type 'const double' is a GNU extension [-Wgnu] Eventually I hit a compiler error: In file included from /Users/sean/Downloads/vxl-1.17.0/contrib/brl/bbas/bvgl/bvgl_labelme_parser.cxx:5: /Volumes/Leopard/Users/sean/Downloads/vxl-1.17.0/contrib/brl/bbas/bvgl/bvgl_labelme_parser.h:84:20: error: implicit instantiation of undefined template 'std::basic_stringstream<char, std::char_traits<char>, std::allocator<char> >' vcl_stringstream strm(t); ^ /usr/include/c++/4.2.1/iosfwd:82:11: note: template is declared here class basic_stringstream; ^ hth, -- ____________________________________________________________ Sean McBride, B. Eng se...@ro... Rogue Research www.rogue-research.com Mac Software Developer Montréal, Québec, Canada |
From: Gehua Y. <yan...@gm...> - 2012-06-08 20:56:12
|
I also had the same warnings with clang in the past. The way I resolved it was to add "-Werror=gnu" to the c++ compiler flags **and** set VXL_UPDATE_CONFIGURATION to true following by re-running cmake. With this flag, the try-compile test will fail and set VCL_CAN_STATIC_CONST_INIT_FLOAT to 0, which eliminates all of these warnings. Regards, Gehua Yang. On Fri, Jun 8, 2012 at 3:38 PM, Sean McBride <se...@ro...>wrote: > On Wed, 6 Jun 2012 00:42:51 +0800, YULianqing said: > > >Dear all, I'm glad to introduce the second release candidate (RC2) of > >VXL 1.17.0 for you to test. The main change to RC2 compared to RC1 is > >the inclusion of dcrispell's fix to remove cyclic dependency issue in > >the case of shared libary build. Please feel free to give me comments > >and suggestions. > > So I downloaded and tried to use cmake to do an out-of-source build. > After I 'configure', with default options, it gives an error: "bvpl_octree > using pthreads". That's not a very helpful message... What does it mean? > > Nevertheless, I proceeded to 'generate' and compile (with clang). > > I get a million warnings like this: > > warning: in-class initializer for static data member of type 'const > double' is a GNU extension > [-Wgnu] > > |
From: YULianqing <yu...@li...> - 2012-06-08 23:17:18
|
Hi Gehua and Sean, First of all, thanks for Gehua's help. Does Gehua's method fix your issue, Sean? I notice there are two submissions from Rogue Research and both of them are error-free. So I wonder whether there is difference between checkouted source code and exported source code. If Gehua's method works, do you think it's necessary to submit a patch to vxl repository for this issue? Regards, Lianqing Yu Date: Fri, 8 Jun 2012 16:56:05 -0400 Subject: Re: [Vxl-maintainers] [Vxl-users] VXL 1.17.0 Release Candicate 2 is available From: yan...@gm... To: se...@ro... CC: yu...@li...; vxl...@li...; vxl...@li... I also had the same warnings with clang in the past. The way I resolved it was to add "-Werror=gnu" to the c++ compiler flags **and** set VXL_UPDATE_CONFIGURATION to true following by re-running cmake. With this flag, the try-compile test will fail and set VCL_CAN_STATIC_CONST_INIT_FLOAT to 0, which eliminates all of these warnings. Regards, Gehua Yang. On Fri, Jun 8, 2012 at 3:38 PM, Sean McBride <se...@ro...> wrote: On Wed, 6 Jun 2012 00:42:51 +0800, YULianqing said: >Dear all, I'm glad to introduce the second release candidate (RC2) of >VXL 1.17.0 for you to test. The main change to RC2 compared to RC1 is >the inclusion of dcrispell's fix to remove cyclic dependency issue in >the case of shared libary build. Please feel free to give me comments >and suggestions. So I downloaded and tried to use cmake to do an out-of-source build. After I 'configure', with default options, it gives an error: "bvpl_octree using pthreads". That's not a very helpful message... What does it mean? Nevertheless, I proceeded to 'generate' and compile (with clang). I get a million warnings like this: warning: in-class initializer for static data member of type 'const double' is a GNU extension [-Wgnu] |
From: Sean M. <se...@ro...> - 2012-06-08 23:17:17
|
On Sat, 9 Jun 2012 06:58:05 +0800, YULianqing said: >Hi Gehua and Sean, First of all, thanks for Gehua's help. Does Gehua's >method fix your issue, Sean? I notice there are two submissions from >Rogue Research and both of them are error-free. Yes, because I've disabled those warnings. >If Gehua's method works, do you think it's necessary to submit a >patch to vxl repository for this issue? I believe the ITK folks have fixed these warnings. Has anyone looked ITK's version of vxl? There are likely many useful fixes to merge. Cheers, -- ____________________________________________________________ Sean McBride, B. Eng se...@ro... Rogue Research www.rogue-research.com Mac Software Developer Montréal, Québec, Canada |
From: YULianqing <yu...@li...> - 2012-06-08 23:20:03
|
Then what about the compiler error you mentioned in your mails. Is it fixed? I have no Mac machine and cannot replicate your errors. I notice the Mac-lang builds on VXL dashboard are OK. Is there any difference between the checkouted source and exported source? Lianqing Yu > From: se...@ro... > To: yu...@li...; yan...@gm... > CC: vxl...@li...; vxl...@li... > Subject: Re: [Vxl-maintainers] [Vxl-users] VXL 1.17.0 Release Candicate 2 is available > Date: Fri, 8 Jun 2012 19:08:52 -0400 > > On Sat, 9 Jun 2012 06:58:05 +0800, YULianqing said: > > >Hi Gehua and Sean, First of all, thanks for Gehua's help. Does Gehua's > >method fix your issue, Sean? I notice there are two submissions from > >Rogue Research and both of them are error-free. > > Yes, because I've disabled those warnings. > > >If Gehua's method works, do you think it's necessary to submit a > >patch to vxl repository for this issue? > > I believe the ITK folks have fixed these warnings. Has anyone looked ITK's version of vxl? There are likely many useful fixes to merge. > > Cheers, > > -- > ____________________________________________________________ > Sean McBride, B. Eng se...@ro... > Rogue Research www.rogue-research.com > Mac Software Developer Montréal, Québec, Canada > > |
From: Isabel R. <mar...@br...> - 2012-06-09 14:14:57
|
Lianqing, I have committed a fix for Sean's error on Mac OS. I'll try to add my Mac OS machine to the dashboard by the end of the weekend. The reason why the other current Mac builds on the dashboard don't report errors is because CMake doesn't find all required libraries to build BRL. Since, I'm a BRL developer, my machine will build those libraries. Isabel On Jun 8, 2012, at 7:19 PM, YULianqing wrote: > Then what about the compiler error you mentioned in your mails. Is it fixed? I have no Mac machine and cannot replicate your errors. I notice the Mac-lang builds on VXL dashboard are OK. Is there any difference between the checkouted source and exported source? > > Lianqing Yu > > From: se...@ro... > > To: yu...@li...; yan...@gm... > > CC: vxl...@li...; vxl...@li... > > Subject: Re: [Vxl-maintainers] [Vxl-users] VXL 1.17.0 Release Candicate 2 is available > > Date: Fri, 8 Jun 2012 19:08:52 -0400 > > > > On Sat, 9 Jun 2012 06:58:05 +0800, YULianqing said: > > > > >Hi Gehua and Sean, First of all, thanks for Gehua's help. Does Gehua's > > >method fix your issue, Sean? I notice there are two submissions from > > >Rogue Research and both of them are error-free. > > > > Yes, because I've disabled those warnings. > > > > >If Gehua's method works, do you think it's necessary to submit a > > >patch to vxl repository for this issue? > > > > I believe the ITK folks have fixed these warnings. Has anyone looked ITK's version of vxl? There are likely many useful fixes to merge. > > > > Cheers, > > > > -- > > ____________________________________________________________ > > Sean McBride, B. Eng se...@ro... > > Rogue Research www.rogue-research.com > > Mac Software Developer Montréal, Québec, Canada > > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers |
From: Mathieu M. <mat...@gm...> - 2012-06-09 16:26:11
|
On Wed, Jun 6, 2012 at 6:12 PM, Ian Scott <sc...@im...> wrote: > On 06/06/2012 16:50, Mathieu Malaterre wrote: >> >> Hi Ian, >> >> On Wed, Jun 6, 2012 at 5:12 PM, Ian Scott<sc...@im...> wrote: >>> >>> Well, I don't know about easy - I can't even replicate it. >>> However, looking at the CMakeLists.txt files for several contrib/mul >>> libraries, I found some unnecessary and potentially confounding >>> TARGET_LINK_LIBRARIES dependency entries. I have removed these and >>> committed >>> as revision >>> >>> Matthieu, if you can check this fixes your problem before Lianqing >>> attempts >>> another RC, then I'm sure he would be grateful. >> >> >> If you get your hand on a debian/sid system - the major difference >> from another linux system will be the use of gcc-4.7 as default >> compiler -, you then apply trunk.patch. You can now run 'run.sh'. You >> should get to: > > > Matthieu, > > I don't have time to set up a debian system (virtual or otherwise) - and gcc > 4.7 is not one of my standard compilers. It isn't my code - I was just > offering a possible fix. Sorry. Ian, The problem can be easily reproduce on any linux and with gcc-4.4. Using 4.4 I still get: $ ldd -r ./lib/libicam.so >/dev/null [...] undefined symbol: _ZN18vnl_numeric_traitsIdE6maxvalE (./lib/libicam.so) See here for tools to track underlinking issues: http://wiki.mandriva.com/en/Underlinking_issues_in_packaging Even during a very simply static build (absolutely no options passed to cmake) I get: $ nm lib/libicam.a| grep vnl_num|c++filt U vnl_numeric_traits<double>::maxval U vnl_numeric_traits<double>::maxval -- Mathieu |
From: Peter V. <pet...@ya...> - 2012-06-09 18:24:46
|
Mathieu Malaterre <mat...@gm...> wrote: > Even during a very simply static build (absolutely no options passed to cmake) I get: > $ nm lib/libicam.a| grep vnl_num|c++filt > U vnl_numeric_traits<double>::maxval > U vnl_numeric_traits<double>::maxval Mathieu, I get the same, but that doesn't mean that there would be a problem: $ nm lib/libicam.a|c++filt| grep 'vnl_numeric_traits<double>' U vnl_numeric_traits<double>::maxval U vnl_numeric_traits<double>::maxval $ nm lib/libvnl.a|c++filt| grep 'vnl_numeric_traits<double>' 000000a0 R vnl_numeric_traits<double>::one 00000080 R vnl_numeric_traits<double>::zero 000000c0 R vnl_numeric_traits<double>::maxval -- Peter. -- |
From: Ian S. <sc...@im...> - 2012-06-11 11:35:32
|
Mathieu, > The problem can be easily reproduce on any linux and with gcc-4.4. > Using 4.4 I still get: > > $ ldd -r ./lib/libicam.so>/dev/null > [...] > undefined symbol: _ZN18vnl_numeric_traitsIdE6maxvalE (./lib/libicam.so) My fix was for the problem related to _Z22vsl_delete_all_loadersv. I have no information regard errors in BRL nor am I ever likely to - I don't build brl. Also, I'm still on gcc 4.1 and I don't get any of these errors. If you don't want to try my suggestion yourself, that's fine. I've stated clearly that I have no plans to attempt to replicate your bug myself. I am grateful for all the work that various VXL maintainers have put into this release and I'm sorry I can't contribute any further right now. Ian. |
From: YULianqing <yu...@li...> - 2012-06-17 15:54:34
|
Hi Mathieu, I've managed to borrow a Linux server with RHEL 6 and GCC 4.4.6. I'll build VXL on it to see if those errors can be replicated. Regards,Lianqing> From: mat...@gm... > Date: Sat, 9 Jun 2012 18:25:43 +0200 > To: sc...@im... > CC: vxl...@li... > Subject: Re: [Vxl-maintainers] [Vxl-users] VXL 1.17.0 Release Candicate 2 is available > > On Wed, Jun 6, 2012 at 6:12 PM, Ian Scott <sc...@im...> wrote: > > On 06/06/2012 16:50, Mathieu Malaterre wrote: > >> > >> Hi Ian, > >> > >> On Wed, Jun 6, 2012 at 5:12 PM, Ian Scott<sc...@im...> wrote: > >>> > >>> Well, I don't know about easy - I can't even replicate it. > >>> However, looking at the CMakeLists.txt files for several contrib/mul > >>> libraries, I found some unnecessary and potentially confounding > >>> TARGET_LINK_LIBRARIES dependency entries. I have removed these and > >>> committed > >>> as revision > >>> > >>> Matthieu, if you can check this fixes your problem before Lianqing > >>> attempts > >>> another RC, then I'm sure he would be grateful. > >> > >> > >> If you get your hand on a debian/sid system - the major difference > >> from another linux system will be the use of gcc-4.7 as default > >> compiler -, you then apply trunk.patch. You can now run 'run.sh'. You > >> should get to: > > > > > > Matthieu, > > > > I don't have time to set up a debian system (virtual or otherwise) - and gcc > > 4.7 is not one of my standard compilers. It isn't my code - I was just > > offering a possible fix. Sorry. > > Ian, > > The problem can be easily reproduce on any linux and with gcc-4.4. > Using 4.4 I still get: > > $ ldd -r ./lib/libicam.so >/dev/null > [...] > undefined symbol: _ZN18vnl_numeric_traitsIdE6maxvalE (./lib/libicam.so) > > See here for tools to track underlinking issues: > http://wiki.mandriva.com/en/Underlinking_issues_in_packaging > > Even during a very simply static build (absolutely no options passed > to cmake) I get: > > $ nm lib/libicam.a| grep vnl_num|c++filt > U vnl_numeric_traits<double>::maxval > U vnl_numeric_traits<double>::maxval > > > -- > Mathieu > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers |
From: YULianqing <yu...@li...> - 2012-06-18 13:11:05
|
Hi Mathieu, I tried VXL-1.17.0 RC2 on a RHEL 6 (GCC 4.4.6) server and did not found any build errors. I tried both static library and shared library build, and both of them are successful. I did not turn on VGUI build as the gtkglext package is not available and I do not have the privillege to install any package on this mission-critical server. The only change in CMake configuration process is to add 'fPIC' to CMAKE_CXX_FLAGS and CMAKE_C_FLAGS.My experience contradicts your assertion that the build problem can be easily reproduced on any linux and with gcc-4.4. I am not sure if this is Debian-specific issue, or has something to do with CMake configurations. Regards,LianqingFrom: yu...@li... To: mat...@gm... Date: Sun, 17 Jun 2012 23:54:27 +0800 CC: vxl...@li... Subject: Re: [Vxl-maintainers] [Vxl-users] VXL 1.17.0 Release Candicate 2 is available Hi Mathieu, I've managed to borrow a Linux server with RHEL 6 and GCC 4.4.6. I'll build VXL on it to see if those errors can be replicated. Regards, Lianqing > From: mat...@gm... > Date: Sat, 9 Jun 2012 18:25:43 +0200 > To: sc...@im... > CC: vxl...@li... > Subject: Re: [Vxl-maintainers] [Vxl-users] VXL 1.17.0 Release Candicate 2 is available > > On Wed, Jun 6, 2012 at 6:12 PM, Ian Scott <sc...@im...> wrote: > > On 06/06/2012 16:50, Mathieu Malaterre wrote: > >> > >> Hi Ian, > >> > >> On Wed, Jun 6, 2012 at 5:12 PM, Ian Scott<sc...@im...> wrote: > >>> > >>> Well, I don't know about easy - I can't even replicate it. > >>> However, looking at the CMakeLists.txt files for several contrib/mul > >>> libraries, I found some unnecessary and potentially confounding > >>> TARGET_LINK_LIBRARIES dependency entries. I have removed these and > >>> committed > >>> as revision > >>> > >>> Matthieu, if you can check this fixes your problem before Lianqing > >>> attempts > >>> another RC, then I'm sure he would be grateful. > >> > >> > >> If you get your hand on a debian/sid system - the major difference > >> from another linux system will be the use of gcc-4.7 as default > >> compiler -, you then apply trunk.patch. You can now run 'run.sh'. You > >> should get to: > > > > > > Matthieu, > > > > I don't have time to set up a debian system (virtual or otherwise) - and gcc > > 4.7 is not one of my standard compilers. It isn't my code - I was just > > offering a possible fix. Sorry. > > Ian, > > The problem can be easily reproduce on any linux and with gcc-4.4. > Using 4.4 I still get: > > $ ldd -r ./lib/libicam.so >/dev/null > [...] > undefined symbol: _ZN18vnl_numeric_traitsIdE6maxvalE (./lib/libicam.so) > > See here for tools to track underlinking issues: > http://wiki.mandriva.com/en/Underlinking_issues_in_packaging > > Even during a very simply static build (absolutely no options passed > to cmake) I get: > > $ nm lib/libicam.a| grep vnl_num|c++filt > U vnl_numeric_traits<double>::maxval > U vnl_numeric_traits<double>::maxval > > > -- > Mathieu > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Vxl-maintainers mailing list Vxl...@li... https://lists.sourceforge.net/lists/listinfo/vxl-maintainers |
From: Mathieu M. <mat...@gm...> - 2012-06-18 13:14:51
|
On Mon, Jun 18, 2012 at 3:10 PM, YULianqing <yu...@li...> wrote: > My experience contradicts your assertion that the build problem can be > easily reproduced on any linux and with gcc-4.4. I am not sure if this is > Debian-specific issue, or has something to do with CMake configurations. You have used the handy run.sh script I sent to the list right ? The only step you have to reproduce explicitly the issue is simply: $ export LDFLAGS='-Wl,--as-needed' $ cmake /path/to/vxl Or manually as said before you can check it directly: $ nm lib/libicam.a|c++filt| grep 'vnl_numeric_traits<double>' U vnl_numeric_traits<double>::maxval U vnl_numeric_traits<double>::maxval Thanks, -- Mathieu |
From: YULianqing <yu...@li...> - 2012-06-18 13:21:22
|
I did not use the script 'run.sh' you sent to the list, nor did I set LDFLAGS. What I did was issue the commands:$ tar xzf vxl-1.17.0-b2.tar.gz -C ${VXLROOT}$ cd ${VXLROOT}$ mkdir bin$ cd bin$ ccmake ../vxl-1.17.0 $ make> From: mat...@gm... > Date: Mon, 18 Jun 2012 15:14:23 +0200 > Subject: Re: [Vxl-maintainers] [Vxl-users] VXL 1.17.0 Release Candicate 2 is available > To: yu...@li... > CC: vxl...@li... > > On Mon, Jun 18, 2012 at 3:10 PM, YULianqing <yu...@li...> wrote: > > My experience contradicts your assertion that the build problem can be > > easily reproduced on any linux and with gcc-4.4. I am not sure if this is > > Debian-specific issue, or has something to do with CMake configurations. > > You have used the handy run.sh script I sent to the list right ? > The only step you have to reproduce explicitly the issue is simply: > > $ export LDFLAGS='-Wl,--as-needed' > $ cmake /path/to/vxl > > Or manually as said before you can check it directly: > > $ nm lib/libicam.a|c++filt| grep 'vnl_numeric_traits<double>' > U vnl_numeric_traits<double>::maxval > U vnl_numeric_traits<double>::maxval > > Thanks, > -- > Mathieu |