From: Brendan M. <bre...@gm...> - 2010-03-08 05:03:37
|
G'day Maintainers, I've packaged up a beta release for vxl 1.14. I have tested it on a 64 bit linux machine (running Fedora 8) with the following results: 98% tests passed, 13 tests failed out of 817 The following tests FAILED: 104 - vnl_test_sparse_matrix (SEGFAULT) 651 - bsta_test_parzen_sphere (Failed) 659 - bsta_test_beta (Failed) 662 - bsta_algo_test_mean_shift (Failed) 664 - bsta_algo_test_von_mises_update (Failed) 665 - bsta_algo_test_beta_updater (Failed) 702 - brip_test_mask (Failed) 704 - brip_test_extrema (OTHER_FAULT) 725 - bvxm_test_rpc_registration_process (Failed) 739 - bmdl_classify_process (SEGFAULT) 750 - brec_test_part_hierarchy_learner (Failed) 753 - brec_test_hierarchy_detector2 (SEGFAULT) 781 - test_octree_kernel_operator (Failed) Errors while running CTest The main concern for me is test 104 failing, although I have a vague feeling we have discussed this issue before (couldn't find it in the archives though). It seems to be a persistent failure on the dashboard too. I'm not sure if we want to do anything about it. Could someone download and test the release candidate please (especially on a Windows machine). -- Cheers, Brendan |
From: Wheeler, F. W (G. Research) <wh...@ge...> - 2010-03-08 14:40:28
|
On a MSVC 8.0 XP build of 1.14b1 I get a few errors in clsfy_random_forest_builder.cxx. These are the only errors. The same errors appeared on this dashboard build from about 4 days ago: http://www.cdash.org/CDash/viewBuildError.php?buildid=554720 Test results ... 96% tests passed, 33 tests failed out of 814 Total Test time (real) = 155.05 sec The following tests FAILED: 395 - clsfy_test_binary_hyperplane (Not Run) 396 - clsfy_test_binary_pdf_classifier (Not Run) 397 - clsfy_test_k_nearest_neighbour (Not Run) 398 - clsfy_test_smo_1 (Not Run) 399 - clsfy_test_rbf_svm_smo (Not Run) 400 - clsfy_test_adaboost (Not Run) 401 - clsfy_test_direct_boost (Not Run) 402 - clsfy_test_binary_threshold_1d (Not Run) 403 - clsfy_test_mean_square_1d (Not Run) 404 - clsfy_test_logit_loss_function (Not Run) 405 - clsfy_test_binary_hyperplane_logit (Not Run) 406 - clsfy_test_binary_1d_wrapper (Not Run) 407 - clsfy_test_binary_tree (Not Run) 408 - clsfy_test_random_forest (Not Run) 493 - mfpf_test_edge_finder (Not Run) 494 - mfpf_test_norm_corr1d (Not Run) 495 - mfpf_test_norm_corr2d (Not Run) 496 - mfpf_test_profile_pdf (Not Run) 497 - mfpf_test_region_pdf (Not Run) 498 - mfpf_test_region_finder (Not Run) 499 - mfpf_test_pose (Not Run) 500 - mfpf_test_mr_point_finder (Not Run) 501 - mfpf_test_patch_data (Not Run) 502 - mfpf_test_dp_snake (Not Run) 503 - mfpf_test_pose_predictor (Not Run) 647 - bsta_test_parzen_sphere (Failed) 655 - bsta_test_beta (Failed) 660 - bsta_algo_test_von_mises_update (Failed) 661 - bsta_algo_test_beta_updater (Failed) 699 - brip_test_mask (Failed) 722 - bvxm_test_rpc_registration_process (Failed) 747 - brec_test_part_hierarchy_learner (Failed) 778 - test_octree_kernel_operator (Failed) Errors while running CTest NMAKE : fatal error U1077: '"C:\Program Files\CMake 2.8\bin\ctest.exe"' : return code '0x8' Stop. > -----Original Message----- > From: Brendan McCane [mailto:bre...@gm...] > Sent: Monday, March 08, 2010 12:04 AM > To: Vxl-maintainers > Subject: [Vxl-maintainers] vxl 1.14 beta 1 > > G'day Maintainers, > > I've packaged up a beta release for vxl 1.14. I have tested it on a 64 > bit linux machine (running Fedora 8) with the following results: > > 98% tests passed, 13 tests failed out of 817 > > The following tests FAILED: > 104 - vnl_test_sparse_matrix (SEGFAULT) > 651 - bsta_test_parzen_sphere (Failed) > 659 - bsta_test_beta (Failed) > 662 - bsta_algo_test_mean_shift (Failed) > 664 - bsta_algo_test_von_mises_update (Failed) > 665 - bsta_algo_test_beta_updater (Failed) > 702 - brip_test_mask (Failed) > 704 - brip_test_extrema (OTHER_FAULT) > 725 - bvxm_test_rpc_registration_process (Failed) > 739 - bmdl_classify_process (SEGFAULT) > 750 - brec_test_part_hierarchy_learner (Failed) > 753 - brec_test_hierarchy_detector2 (SEGFAULT) > 781 - test_octree_kernel_operator (Failed) > Errors while running CTest > > The main concern for me is test 104 failing, although I have a vague > feeling we have discussed this issue before (couldn't find it in the > archives though). It seems to be a persistent failure on the dashboard > too. I'm not sure if we want to do anything about it. > > Could someone download and test the release candidate please > (especially on a Windows machine). > > -- > Cheers, > > Brendan > > -------------------------------------------------------------- > ---------------- > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > |
From: Brendan M. <bre...@gm...> - 2010-03-08 20:23:55
|
Urk. By errors I assume you mean build errors? If so, that is bad. Is someone working on fixing those errors? Or have they already been fixed? On 9 March 2010 03:40, Wheeler, Frederick W (GE, Research) <wh...@ge...> wrote: > > On a MSVC 8.0 XP build of 1.14b1 I get a few errors in > clsfy_random_forest_builder.cxx. These are the only errors. The same > errors appeared on this dashboard build from about 4 days ago: > > http://www.cdash.org/CDash/viewBuildError.php?buildid=554720 > > Test results ... > > 96% tests passed, 33 tests failed out of 814 > > Total Test time (real) = 155.05 sec > > The following tests FAILED: > 395 - clsfy_test_binary_hyperplane (Not Run) > 396 - clsfy_test_binary_pdf_classifier (Not Run) > 397 - clsfy_test_k_nearest_neighbour (Not Run) > 398 - clsfy_test_smo_1 (Not Run) > 399 - clsfy_test_rbf_svm_smo (Not Run) > 400 - clsfy_test_adaboost (Not Run) > 401 - clsfy_test_direct_boost (Not Run) > 402 - clsfy_test_binary_threshold_1d (Not Run) > 403 - clsfy_test_mean_square_1d (Not Run) > 404 - clsfy_test_logit_loss_function (Not Run) > 405 - clsfy_test_binary_hyperplane_logit (Not Run) > 406 - clsfy_test_binary_1d_wrapper (Not Run) > 407 - clsfy_test_binary_tree (Not Run) > 408 - clsfy_test_random_forest (Not Run) > 493 - mfpf_test_edge_finder (Not Run) > 494 - mfpf_test_norm_corr1d (Not Run) > 495 - mfpf_test_norm_corr2d (Not Run) > 496 - mfpf_test_profile_pdf (Not Run) > 497 - mfpf_test_region_pdf (Not Run) > 498 - mfpf_test_region_finder (Not Run) > 499 - mfpf_test_pose (Not Run) > 500 - mfpf_test_mr_point_finder (Not Run) > 501 - mfpf_test_patch_data (Not Run) > 502 - mfpf_test_dp_snake (Not Run) > 503 - mfpf_test_pose_predictor (Not Run) > 647 - bsta_test_parzen_sphere (Failed) > 655 - bsta_test_beta (Failed) > 660 - bsta_algo_test_von_mises_update (Failed) > 661 - bsta_algo_test_beta_updater (Failed) > 699 - brip_test_mask (Failed) > 722 - bvxm_test_rpc_registration_process (Failed) > 747 - brec_test_part_hierarchy_learner (Failed) > 778 - test_octree_kernel_operator (Failed) > Errors while running CTest > NMAKE : fatal error U1077: '"C:\Program Files\CMake 2.8\bin\ctest.exe"' > : return code '0x8' > Stop. > > > >> -----Original Message----- >> From: Brendan McCane [mailto:bre...@gm...] >> Sent: Monday, March 08, 2010 12:04 AM >> To: Vxl-maintainers >> Subject: [Vxl-maintainers] vxl 1.14 beta 1 >> >> G'day Maintainers, >> >> I've packaged up a beta release for vxl 1.14. I have tested it on a 64 >> bit linux machine (running Fedora 8) with the following results: >> >> 98% tests passed, 13 tests failed out of 817 >> >> The following tests FAILED: >> 104 - vnl_test_sparse_matrix (SEGFAULT) >> 651 - bsta_test_parzen_sphere (Failed) >> 659 - bsta_test_beta (Failed) >> 662 - bsta_algo_test_mean_shift (Failed) >> 664 - bsta_algo_test_von_mises_update (Failed) >> 665 - bsta_algo_test_beta_updater (Failed) >> 702 - brip_test_mask (Failed) >> 704 - brip_test_extrema (OTHER_FAULT) >> 725 - bvxm_test_rpc_registration_process (Failed) >> 739 - bmdl_classify_process (SEGFAULT) >> 750 - brec_test_part_hierarchy_learner (Failed) >> 753 - brec_test_hierarchy_detector2 (SEGFAULT) >> 781 - test_octree_kernel_operator (Failed) >> Errors while running CTest >> >> The main concern for me is test 104 failing, although I have a vague >> feeling we have discussed this issue before (couldn't find it in the >> archives though). It seems to be a persistent failure on the dashboard >> too. I'm not sure if we want to do anything about it. >> >> Could someone download and test the release candidate please >> (especially on a Windows machine). >> >> -- >> Cheers, >> >> Brendan >> >> -------------------------------------------------------------- >> ---------------- >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> _______________________________________________ >> Vxl-maintainers mailing list >> Vxl...@li... >> https://lists.sourceforge.net/lists/listinfo/vxl-maintainers >> > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > -- Cheers, Brendan |
From: Wheeler, F. W (G. Research) <wh...@ge...> - 2010-03-08 20:26:15
|
Yes, I mean build errors. Looks like they have already been fixed. I did not see them in later dashboard builds. In a few minutes I'll send another email about a Linux/gcc test build. Fred > -----Original Message----- > From: Brendan McCane [mailto:bre...@gm...] > Sent: Monday, March 08, 2010 3:24 PM > To: Wheeler, Frederick W (GE, Research) > Cc: Vxl-maintainers > Subject: Re: [Vxl-maintainers] vxl 1.14 beta 1 - MSVS 8.0 XP > test build > > Urk. By errors I assume you mean build errors? If so, that is bad. Is > someone working on fixing those errors? Or have they already been > fixed? > > On 9 March 2010 03:40, Wheeler, Frederick W (GE, Research) > <wh...@ge...> wrote: > > > > On a MSVC 8.0 XP build of 1.14b1 I get a few errors in > > clsfy_random_forest_builder.cxx. These are the only > errors. The same > > errors appeared on this dashboard build from about 4 days ago: > > > > http://www.cdash.org/CDash/viewBuildError.php?buildid=554720 > > > > Test results ... > > > > 96% tests passed, 33 tests failed out of 814 > > > > Total Test time (real) = 155.05 sec > > > > The following tests FAILED: > > 395 - clsfy_test_binary_hyperplane (Not Run) > > 396 - clsfy_test_binary_pdf_classifier (Not Run) > > 397 - clsfy_test_k_nearest_neighbour (Not Run) > > 398 - clsfy_test_smo_1 (Not Run) > > 399 - clsfy_test_rbf_svm_smo (Not Run) > > 400 - clsfy_test_adaboost (Not Run) > > 401 - clsfy_test_direct_boost (Not Run) > > 402 - clsfy_test_binary_threshold_1d (Not Run) > > 403 - clsfy_test_mean_square_1d (Not Run) > > 404 - clsfy_test_logit_loss_function (Not Run) > > 405 - clsfy_test_binary_hyperplane_logit (Not Run) > > 406 - clsfy_test_binary_1d_wrapper (Not Run) > > 407 - clsfy_test_binary_tree (Not Run) > > 408 - clsfy_test_random_forest (Not Run) > > 493 - mfpf_test_edge_finder (Not Run) > > 494 - mfpf_test_norm_corr1d (Not Run) > > 495 - mfpf_test_norm_corr2d (Not Run) > > 496 - mfpf_test_profile_pdf (Not Run) > > 497 - mfpf_test_region_pdf (Not Run) > > 498 - mfpf_test_region_finder (Not Run) > > 499 - mfpf_test_pose (Not Run) > > 500 - mfpf_test_mr_point_finder (Not Run) > > 501 - mfpf_test_patch_data (Not Run) > > 502 - mfpf_test_dp_snake (Not Run) > > 503 - mfpf_test_pose_predictor (Not Run) > > 647 - bsta_test_parzen_sphere (Failed) > > 655 - bsta_test_beta (Failed) > > 660 - bsta_algo_test_von_mises_update (Failed) > > 661 - bsta_algo_test_beta_updater (Failed) > > 699 - brip_test_mask (Failed) > > 722 - bvxm_test_rpc_registration_process (Failed) > > 747 - brec_test_part_hierarchy_learner (Failed) > > 778 - test_octree_kernel_operator (Failed) > > Errors while running CTest > > NMAKE : fatal error U1077: '"C:\Program Files\CMake > 2.8\bin\ctest.exe"' > > : return code '0x8' > > Stop. > > > > > > > >> -----Original Message----- > >> From: Brendan McCane [mailto:bre...@gm...] > >> Sent: Monday, March 08, 2010 12:04 AM > >> To: Vxl-maintainers > >> Subject: [Vxl-maintainers] vxl 1.14 beta 1 > >> > >> G'day Maintainers, > >> > >> I've packaged up a beta release for vxl 1.14. I have > tested it on a 64 > >> bit linux machine (running Fedora 8) with the following results: > >> > >> 98% tests passed, 13 tests failed out of 817 > >> > >> The following tests FAILED: > >> 104 - vnl_test_sparse_matrix (SEGFAULT) > >> 651 - bsta_test_parzen_sphere (Failed) > >> 659 - bsta_test_beta (Failed) > >> 662 - bsta_algo_test_mean_shift (Failed) > >> 664 - bsta_algo_test_von_mises_update (Failed) > >> 665 - bsta_algo_test_beta_updater (Failed) > >> 702 - brip_test_mask (Failed) > >> 704 - brip_test_extrema (OTHER_FAULT) > >> 725 - bvxm_test_rpc_registration_process (Failed) > >> 739 - bmdl_classify_process (SEGFAULT) > >> 750 - brec_test_part_hierarchy_learner (Failed) > >> 753 - brec_test_hierarchy_detector2 (SEGFAULT) > >> 781 - test_octree_kernel_operator (Failed) > >> Errors while running CTest > >> > >> The main concern for me is test 104 failing, although I > have a vague > >> feeling we have discussed this issue before (couldn't find > it in the > >> archives though). It seems to be a persistent failure on > the dashboard > >> too. I'm not sure if we want to do anything about it. > >> > >> Could someone download and test the release candidate please > >> (especially on a Windows machine). > >> > >> -- > >> Cheers, > >> > >> Brendan > >> > >> -------------------------------------------------------------- > >> ---------------- > >> Download Intel® Parallel Studio Eval > >> Try the new software tools for yourself. Speed compiling, find bugs > >> proactively, and fine-tune applications for parallel performance. > >> See why Intel Parallel Studio got high marks during beta. > >> http://p.sf.net/sfu/intel-sw-dev > >> _______________________________________________ > >> Vxl-maintainers mailing list > >> Vxl...@li... > >> https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > >> > > > > > -------------------------------------------------------------- > ---------------- > > Download Intel® Parallel Studio Eval > > Try the new software tools for yourself. Speed compiling, find bugs > > proactively, and fine-tune applications for parallel performance. > > See why Intel Parallel Studio got high marks during beta. > > http://p.sf.net/sfu/intel-sw-dev > > _______________________________________________ > > Vxl-maintainers mailing list > > Vxl...@li... > > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > > > > > > -- > Cheers, > > Brendan > |
From: Wheeler, F. W (G. Research) <wh...@ge...> - 2010-03-08 20:32:27
|
On this 64 bit linux system: % gcc --version gcc (GCC) 4.4.3 % uname -a Linux goliath5 2.6.9-89.0.9.ELsmp #1 SMP Wed Aug 19 08:06:10 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux I get a build error like this about four times building 1.14b1: 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 `a local symbol' 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 This exact same error, and others like it are seen on this dashboard build: http://www.cdash.org/CDash/viewBuildError.php?buildid=557176 I do not know whether this counts as a VXL bug. Perhaps it must simply be a requirement that when compiling with gcc, the -fPIC option must be used because even for a build with static libs, since some shared libs are also built. Here are the test run results for this machine: 98% tests passed, 14 tests failed out of 813 Total Test time (real) = 196.15 sec The following tests FAILED: 104 - vnl_test_sparse_matrix (SEGFAULT) 646 - bsta_test_parzen_sphere (Failed) 654 - bsta_test_beta (Failed) 659 - bsta_algo_test_von_mises_update (Failed) 660 - bsta_algo_test_beta_updater (Failed) 698 - brip_test_mask (Failed) 700 - brip_test_extrema (SEGFAULT) 721 - bvxm_test_rpc_registration_process (Failed) 735 - bmdl_classify_process (SEGFAULT) 746 - brec_test_part_hierarchy_learner (Failed) 749 - brec_test_hierarchy_detector2 (SEGFAULT) 764 - boxm_test_update (SEGFAULT) 765 - boxm_test_update_multi_bin (SEGFAULT) 777 - test_octree_kernel_operator (Failed) Errors while running Ctest Now, when I build on this same machine, with the -fPIC option, I get much better results: no build errors and these test results: 98% tests passed, 15 tests failed out of 813 Total Test time (real) = 191.40 sec The following tests FAILED: 104 - vnl_test_sparse_matrix (SEGFAULT) 532 - rgrl_estimator (SEGFAULT) 646 - bsta_test_parzen_sphere (Failed) 654 - bsta_test_beta (Failed) 659 - bsta_algo_test_von_mises_update (Failed) 660 - bsta_algo_test_beta_updater (Failed) 698 - brip_test_mask (Failed) 700 - brip_test_extrema (SEGFAULT) 721 - bvxm_test_rpc_registration_process (Failed) 735 - bmdl_classify_process (SEGFAULT) 746 - brec_test_part_hierarchy_learner (Failed) 749 - brec_test_hierarchy_detector2 (SEGFAULT) 764 - boxm_test_update (SEGFAULT) 765 - boxm_test_update_multi_bin (SEGFAULT) 777 - test_octree_kernel_operator (Failed) Errors while running CTest Fred > -----Original Message----- > From: Brendan McCane [mailto:bre...@gm...] > Sent: Monday, March 08, 2010 12:04 AM > To: Vxl-maintainers > Subject: [Vxl-maintainers] vxl 1.14 beta 1 > > G'day Maintainers, > > I've packaged up a beta release for vxl 1.14. I have tested it on a 64 > bit linux machine (running Fedora 8) with the following results: > > 98% tests passed, 13 tests failed out of 817 > > The following tests FAILED: > 104 - vnl_test_sparse_matrix (SEGFAULT) > 651 - bsta_test_parzen_sphere (Failed) > 659 - bsta_test_beta (Failed) > 662 - bsta_algo_test_mean_shift (Failed) > 664 - bsta_algo_test_von_mises_update (Failed) > 665 - bsta_algo_test_beta_updater (Failed) > 702 - brip_test_mask (Failed) > 704 - brip_test_extrema (OTHER_FAULT) > 725 - bvxm_test_rpc_registration_process (Failed) > 739 - bmdl_classify_process (SEGFAULT) > 750 - brec_test_part_hierarchy_learner (Failed) > 753 - brec_test_hierarchy_detector2 (SEGFAULT) > 781 - test_octree_kernel_operator (Failed) > Errors while running CTest > > The main concern for me is test 104 failing, although I have a vague > feeling we have discussed this issue before (couldn't find it in the > archives though). It seems to be a persistent failure on the dashboard > too. I'm not sure if we want to do anything about it. > > Could someone download and test the release candidate please > (especially on a Windows machine). > > -- > Cheers, > > Brendan > > -------------------------------------------------------------- > ---------------- > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > |
From: Matt L. <mat...@ki...> - 2010-03-08 21:15:09
|
Wheeler, Frederick W (GE, Research) wrote: > I get a build error like this about four times building 1.14b1: > > 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 `a local symbol' 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 > > This exact same error, and others like it are seen on this dashboard > build: > > http://www.cdash.org/CDash/viewBuildError.php?buildid=557176 > > I do not know whether this counts as a VXL bug. Perhaps it must simply > be a requirement that when compiling with gcc, the -fPIC option must be > used because even for a build with static libs, since some shared libs > are also built I'm also wondering if -fPIC should be considered a standard option for compiling VXL with gcc on 64-bit systems. The issue is that we occasionally want to compile parts of VXL into dynamic libraries. In the case of those Brown libraries the goal is to wrap the code into a Python module. There is no problem doing this on 32-bit systems, but -fPIC is required on 64-bit systems. Is there a good reason not to enable -fPIC by default? I remember reading somewhere that it may have an impact on code optimization, but I don't know the details. Some people might not build brl nor care about dynamic linking, so they could potentially benefit from not using -fPIC. Is this benefit significant enough to matter? Matt |
From: Brendan M. <bre...@gm...> - 2010-03-08 22:21:04
|
G'day All, I would vote for -fPIC as default. My simplistic understanding of the situation is: - It appears that fPIC will cause one extra instruction for each function global/static variable and each function call. - This is offset by quicker start-up times and more potential sharing of code in memory (apparently, without fPIC, each process essentially gets a copy of the library, so it isn't actually shared). - it looks like x86 is a bit different (see Chuck's comments) Having said that, it's pretty easy to add fPIC as needed ... so I'm not concerned too much if we stick with the status quo. -- Cheers, Brendan |
From: Wheeler, F. W (G. Research) <wh...@ge...> - 2010-03-09 11:34:36
|
I think Chuck said there is a performance hit for using -fPIC on 32 bit systems. If that is the case I do not think it should be automatically added as an option. Where the brl lib in question is built, perhaps we just need to check whether this (1) is a gcc build, (2) is a static lib build and (3) the -fPIC option has been used. Then, the lib only gets built if ( NOT (1) ) OR ( (1) AND NOT (2) ) OR ( (1) AND (2) AND (3) ). If' sure that logic could be simplified. Maybe there should be a new variable named VXL_CAN_LINK_SPECIAL_SHARED that encapsulates this. Fred > -----Original Message----- > From: Brendan McCane [mailto:bre...@gm...] > Sent: Monday, March 08, 2010 5:21 PM > To: Matt Leotta > Cc: Wheeler, Frederick W (GE, Research); Vxl-maintainers > Subject: Re: [Vxl-maintainers] vxl 1.14 beta 1 - linux with > gcc test build > > G'day All, > > I would vote for -fPIC as default. > > My simplistic understanding of the situation is: > - It appears that fPIC will cause one extra instruction for each > function global/static variable and each function call. > - This is offset by quicker start-up times and more potential sharing > of code in memory (apparently, without fPIC, each process essentially > gets a copy of the library, so it isn't actually shared). > - it looks like x86 is a bit different (see Chuck's comments) > > Having said that, it's pretty easy to add fPIC as needed ... so I'm > not concerned too much if we stick with the status quo. > > -- > Cheers, > > Brendan > |
From: Matt L. <mat...@ki...> - 2010-03-09 13:34:48
|
Wheeler, Frederick W (GE, Research) wrote: > I think Chuck said there is a performance hit for using -fPIC on 32 bit > systems. If that is the case I do not think it should be automatically > added as an option. > As far as I understand, -fPIC is not needed for shared libraries on 32-bit systems. > Where the brl lib in question is built, perhaps we just need to check > whether this (1) is a gcc build, (2) is a static lib build and (3) the > -fPIC option has been used. Then, the lib only gets built if ( NOT (1) > ) OR ( (1) AND NOT (2) ) OR ( (1) AND (2) AND (3) ). If' sure that > logic could be simplified. Maybe there should be a new variable named > VXL_CAN_LINK_SPECIAL_SHARED that encapsulates this. > > I'm more in favor of an explicit option to the user that only appears when needed. On 32-bit gcc and non gcc builds this option would not show up and -fPIC would not be used. However, if using gcc on a 64-bit system then an ALLOW_SHARED_LINKING option would appear and default to ON. Such an option would add -fPIC to the build flags and be required to enable building of any shared module in VXL. If we had a VXL_CAN_LINK_SPECIAL_SHARED variable that is automatically is set that might confuse users. The shared modules would appear to just not build on 64-bit gcc without any indication that you could enable them by adding -fPIC to the build flags. Thoughts? Matt |
From: Wheeler, F. W (G. Research) <wh...@ge...> - 2010-03-09 13:45:55
|
> Matt said: > As far as I understand, -fPIC is not needed for shared libraries on > 32-bit systems. As long as this is true, then I'm fine with using -fPIC whenever needed, by default. > I'm more in favor of an explicit option to the user that only appears > when needed. On 32-bit gcc and non gcc builds this option would not > show up and -fPIC would not be used. However, if using gcc > on a 64-bit > system then an ALLOW_SHARED_LINKING option would appear and > default to > ON. Such an option would add -fPIC to the build flags and be > required > to enable building of any shared module in VXL. OK. I think this is fine also. > If we had a VXL_CAN_LINK_SPECIAL_SHARED variable that is > automatically > is set that might confuse users. The shared modules would appear to > just not build on 64-bit gcc without any indication that you could > enable them by adding -fPIC to the build flags. > > Thoughts? Makes sense. We could still use something like VXL_CAN_LINK_SPECIAL_SHARED (or a better name, maybe VXL_LINK_EXPLICIT_SHARED_ENABLED or _ALLOWED ) internally to control whether we build libs that explicitly forced to SHARED. This brl-python case might be the only one now. That could change. I do not think this issue should hold up the release. The other MSVS build errors probably should. Fred |
From: Matt L. <mat...@ki...> - 2010-03-09 14:01:34
|
Wheeler, Frederick W (GE, Research) wrote: > We could still use something like > VXL_CAN_LINK_SPECIAL_SHARED (or a better name, maybe > VXL_LINK_EXPLICIT_SHARED_ENABLED or _ALLOWED ) internally to control > whether we build libs that explicitly forced to SHARED. We could still have a try-compile test to set such a variable, but I'm not sure why that is really necessary. > This brl-python > case might be the only one now. That could change. > It already goes beyond python modules in brl. As a VXL user, if I want to create my own shared libraries (outside of the VXL tree), I can't link these to VXL libraries without building VXL with -fPIC on 64-bit gcc. > I do not think this issue should hold up the release. The other MSVS > build errors probably should. > > agreed. Matt |
From: Wheeler, F. W (G. Research) <wh...@ge...> - 2010-03-09 15:43:42
|
> From: Matt Leotta [mailto:mat...@ki...] > Wheeler, Frederick W (GE, Research) wrote: > > We could still use something like > > VXL_CAN_LINK_SPECIAL_SHARED (or a better name, maybe > > VXL_LINK_EXPLICIT_SHARED_ENABLED or _ALLOWED ) internally to control > > whether we build libs that explicitly forced to SHARED. > We could still have a try-compile test to set such a > variable, but I'm > not sure why that is really necessary. I also think a try-compile is overkill. All I am trying to suggest is that whatever logic is used to determine whether the brl shared lib in question is compiled could be used to set VXL_LINK_EXPLICIT_SHARED_ENABLED (or _ALLOWED or whatever) so that it can easily be used elsewhere when needed. Something like this ... # only use ADD_LIBRARY( ... SHARED ... ) if this is true VXL_LINK_EXPLICIT_SHARED_ENABLED=TRUE IF using GCC IF on a 64-bit-system create the ALLOW_SHARED_LINKING option, defaulting to TRUE IF not ALLOW_SHARED_LINKING VXL_LINK_EXPLICIT_SHARED_ENABLED=FALSE ENDIF ENDIF ENDIF So this can be done ... IF( VXL_LINK_EXPLICIT_SHARED_ENABLED ) ADD_LIBRARY(brec_batch SHARED ${brec_batch_sources}) ENDIF() Fred |
From: Matt L. <mat...@ki...> - 2010-03-09 16:15:16
|
Okay, I misunderstood. What you proposed (below) is exactly what I had in mind. Matt Wheeler, Frederick W (GE, Research) wrote: > Something like this ... > > # only use ADD_LIBRARY( ... SHARED ... ) if this is true > VXL_LINK_EXPLICIT_SHARED_ENABLED=TRUE > IF using GCC > IF on a 64-bit-system > create the ALLOW_SHARED_LINKING option, defaulting to TRUE > IF not ALLOW_SHARED_LINKING > VXL_LINK_EXPLICIT_SHARED_ENABLED=FALSE > ENDIF > ENDIF > ENDIF > > So this can be done ... > > IF( VXL_LINK_EXPLICIT_SHARED_ENABLED ) > ADD_LIBRARY(brec_batch SHARED ${brec_batch_sources}) > ENDIF() > > Fred > |
From: Chuck A. <chu...@ki...> - 2010-03-08 22:29:29
|
The problem actually extends back through the entire dependency chain as well as forward. Basically any code that you want to be part of a shared library needs to be built with -fPIC as well. So even if you're not building any vxl shared libraries and leaving them all static, in order for the static vxl libraries to be linked into future shared libraries as dependencies, they must be built with -fPIC. From a usability standpoint this may lead one to want to always build with -fPIC. On x64 there is very little penalty for this since there are a few additional instructions in the instruction set that assist in the position independent code (PIC) activities. The resulting code will often only be one or two additional instructions rather than without -fPIC. On x86, however, these additional instructions are not available and the compiler will often generate an additional branch to retrieve the necessary information needed for the PIC. I don't know how this translates though to other architectures. I definitely think it should be used with a bit of caution and remain as an "opt in" sort of option instead of an "opt out". But that's just my 2 cents. Chuck Atkins R&D Engineer Kitware, Inc. -- "Mathematicians are tools for turning coffee grounds into formulas.", Paul Erdos On Mon, Mar 8, 2010 at 3:47 PM, Matt Leotta <mat...@ki...> wrote: > Wheeler, Frederick W (GE, Research) wrote: > > I get a build error like this about four times building 1.14b1: > > > > 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 `a local symbol' 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 > > > > This exact same error, and others like it are seen on this dashboard > > build: > > > > http://www.cdash.org/CDash/viewBuildError.php?buildid=557176 > > > > I do not know whether this counts as a VXL bug. Perhaps it must simply > > be a requirement that when compiling with gcc, the -fPIC option must be > > used because even for a build with static libs, since some shared libs > > are also built > I'm also wondering if -fPIC should be considered a standard option for > compiling VXL with gcc on 64-bit systems. The issue is that we > occasionally want to compile parts of VXL into dynamic libraries. In > the case of those Brown libraries the goal is to wrap the code into a > Python module. There is no problem doing this on 32-bit systems, but > -fPIC is required on 64-bit systems. > > Is there a good reason not to enable -fPIC by default? I remember > reading somewhere that it may have an impact on code optimization, but I > don't know the details. Some people might not build brl nor care about > dynamic linking, so they could potentially benefit from not using > -fPIC. Is this benefit significant enough to matter? > > Matt > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > |
From: Matt L. <mat...@ki...> - 2010-03-08 22:08:50
|
Either way, the opt-in or opt-out should probably become a CMake option. This option can be required to build shared libraries within VXL (like bbgm_batch.so). That way if don't use -fPIC the dynamic libraries are not compiled and you don't get build errors. I supposed this option should only appear when CMake detects a 64-bit gcc build. Does anyone know if there a similar situation on 64-bit Windows or other non-gcc compilers? Matt Chuck Atkins wrote: > The problem actually extends back through the entire dependency chain > as well as forward. Basically any code that you want to be part of a > shared library needs to be built with -fPIC as well. So even if > you're not building any vxl shared libraries and leaving them all > static, in order for the static vxl libraries to be linked into future > shared libraries as dependencies, they must be built with -fPIC. From > a usability standpoint this may lead one to want to always build with > -fPIC. On x64 there is very little penalty for this since there are a > few additional instructions in the instruction set that assist in the > position independent code (PIC) activities. The resulting code will > often only be one or two additional instructions rather than without > -fPIC. On x86, however, these additional instructions are not > available and the compiler will often generate an additional branch to > retrieve the necessary information needed for the PIC. I don't know > how this translates though to other architectures. I definitely think > it should be used with a bit of caution and remain as an "opt in" sort > of option instead of an "opt out". But that's just my 2 cents. > > Chuck Atkins > R&D Engineer > Kitware, Inc. > > -- "Mathematicians are tools for turning coffee grounds into > formulas.", Paul Erdos > > > On Mon, Mar 8, 2010 at 3:47 PM, Matt Leotta <mat...@ki... > <mailto:mat...@ki...>> wrote: > > Wheeler, Frederick W (GE, Research) wrote: > > I get a build error like this about four times building 1.14b1: > > > > 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 `a local symbol' 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 > > > > This exact same error, and others like it are seen on this dashboard > > build: > > > > http://www.cdash.org/CDash/viewBuildError.php?buildid=557176 > > > > I do not know whether this counts as a VXL bug. Perhaps it must > simply > > be a requirement that when compiling with gcc, the -fPIC option > must be > > used because even for a build with static libs, since some > shared libs > > are also built > I'm also wondering if -fPIC should be considered a standard option for > compiling VXL with gcc on 64-bit systems. The issue is that we > occasionally want to compile parts of VXL into dynamic libraries. In > the case of those Brown libraries the goal is to wrap the code into a > Python module. There is no problem doing this on 32-bit systems, but > -fPIC is required on 64-bit systems. > > Is there a good reason not to enable -fPIC by default? I remember > reading somewhere that it may have an impact on code optimization, > but I > don't know the details. Some people might not build brl nor care > about > dynamic linking, so they could potentially benefit from not using > -fPIC. Is this benefit significant enough to matter? > > Matt > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Vxl-maintainers mailing list > Vxl...@li... > <mailto:Vxl...@li...> > https://lists.sourceforge.net/lists/listinfo/vxl-maintainers > > |
From: Brendan M. <bre...@gm...> - 2010-03-09 22:51:10
|
Hi Fred, What you suggest is a good idea, except for two factors: 1. I tried this previously and it had pretty much no effect on check in behaviour. 2. Unfortunately, I'm so busy, I can't easily predict two weeks in advance whether I will get a chance to do it (btw, if anyone is keen on becoming the release maintainer, I'd be happy to relinquish the role:-). If I thought the code lock-down would work, it would be worth my while setting aside a time. But we'd need an agreement from all those with check-in privileges (actually, even then, if it's different to people's normal work-flow, then I think it highly likely that people will accidentally check new code in). What say you developers? On 10 March 2010 00:38, Wheeler, Frederick W (GE, Research) <wh...@ge...> wrote: > Brendan, > > Many thanks for making the releases. There might be some advantages to > announcing your intention to cut a release in advance. You could email > that you plan to cut a release on a certain date, say, two weeks ahead > of time. That might get people to fix up the dashboard. Folks might > then delay checking in code that is not quite ready for a release and > might add compilation errors. This might make things easier for you, > because there would be a higher chance of the first beta release being > good to go. > > Just my two cents. > > Best, > Fred > -- Cheers, Brendan |
From: Peter V. <pet...@ya...> - 2010-03-10 07:34:35
|
--- Brendan McCane <bre...@gm...> wrote: > Hi Fred, > What you suggest is a good idea, except for two factors: > 1. I tried this previously and it had pretty much no > effect on check in behaviour. > [...] > Wheeler, Frederick W <wh...@ge...> wrote: > [...] That might get people to fix up the dashboard. [...] It's also my impression that the dashboard is not so green as it was until about a year ago. A deadline for a release should *not* make a difference to whether a check-in is compiling or not! I would urge all developers to at least *always* check the dashboard *after* a check-in, and (in case of increasing # errors or warnings) look at them *and immediately check in a fix* if the error (or severe warning) is caused by their check-in! Verifying *before* a check-in is of course much better; that is; recompiling *the whole of* vxl, and not just the file that was changed!!! I've the impression that recently even this kind of verification is not always performed... -- Peter. __________________________________________________ Använder du Yahoo!? Är du trött på spam? Yahoo! E-post har det bästa spamskyddet som finns http://se.mail.yahoo.com |
From: Miguel A. Figueroa-V. <mi...@ie...> - 2010-03-09 23:14:39
|
On Tue, Mar 9, 2010 at 6:51 PM, Brendan McCane wrote: [...] > If I thought the code lock-down would work, it would be worth my while > setting aside a time. But we'd need an agreement from all those with > check-in privileges (actually, even then, if it's different to > people's normal work-flow, then I think it highly likely that people > will accidentally check new code in). What say you developers? I might be commenting naively (since I haven't really cut a release before), but isn't it possible to look back at a greener dashboard and then just use that revision to tag it as a release? --Miguel |
From: Brendan M. <bre...@gm...> - 2010-03-10 04:10:13
|
I guess so. Although I'm not sure there's any way of making sure that all the dashboards have used the same revision (presumably, they update at different times?), other than manually going through the changed file list to check. I could certainly try that though. What I really don't understand though, is why so many compile errors end up on the dashboard. Is it because of the quirks of different compilers? Or do developers some times/often check in as a matter of course regardless of compile errors? On 10 March 2010 12:14, Miguel A. Figueroa-Villanueva <mi...@ie...> wrote: > On Tue, Mar 9, 2010 at 6:51 PM, Brendan McCane wrote: > [...] >> If I thought the code lock-down would work, it would be worth my while >> setting aside a time. But we'd need an agreement from all those with >> check-in privileges (actually, even then, if it's different to >> people's normal work-flow, then I think it highly likely that people >> will accidentally check new code in). What say you developers? > > I might be commenting naively (since I haven't really cut a release > before), but isn't it possible to look back at a greener dashboard and > then just use that revision to tag it as a release? > > --Miguel > -- Cheers, Brendan |
From: Miguel A. Figueroa-V. <mi...@ie...> - 2010-03-10 04:51:34
|
On Wed, Mar 10, 2010 at 12:10 AM, Brendan McCane wrote: > I guess so. Although I'm not sure there's any way of making sure that > all the dashboards have used the same revision (presumably, they > update at different times?), other than manually going through the > changed file list to check. I could certainly try that though. Well, I haven't paid too much attention to the dashboard, but I was thinking it was supposed to be green most of the time. So, I was thinking that going back and picking a revision in the greener days would do. > What I really don't understand though, is why so many compile errors > end up on the dashboard. Is it because of the quirks of different > compilers? Or do developers some times/often check in as a matter of > course regardless of compile errors? I hope not, as this is certainly not appropriate. To make a commit one should check that everything is compiling and all test passing in one's own platform. However, I do understand that doing cross-platform has it quirks, so it is easy to break other platforms. --Miguel |