Checking library binary compatibility with respect to compile time options
I was pondering how to event or at least warn users when they use a .a compiled with a set of define with an application compiled with divergent options (like having different -D that may cause ODR violation). On IRC, I was linked to this page for MSVC 10: http://msdn.microsoft.com/en-us/library/ee956429.aspx That defiens some pragma that exactly do that. However, it's MSVC 10 specific. After a few brainstorming, we ended up with a simple solution to emulate this. The code source is here: http://dl.dropbox.com/u/3819406/lib_check.tar.gz Here is a use case: g++ -c foo.cpp -o foo.o -I/usr/local/include/boost-1_43 -DGOOD_LIB g++ -c main.cpp -o bmain.o -I/usr/local/include/boost-1_43 -DBAD_LIB -I./ g++ -c main.cpp -o gmain.o -I/usr/local/include/boost-1_43 -DGOOD_LIB -I./ Here, we compiel foo with some settings and try to link it with two different setup for main.o The gcc output, showing the divergence in option is detected: g++ bmain.o foo.o -o bmain bmain.o: In function `__static_initialization_and_destruction_0(int, int)': main.cpp:(.text+0x2a): undefined reference to `boost::config::test_library_version_mismatch_with_version_being_2()' collect2: ld returned 1 exit status Of course, when you link the good pair of .o : g++ gmain.o foo.o -o gmain Nothing happens I guess some details need to be hammered out like visibility and such but could this be a valuable addition to boost (liek boost config for example) or have I overengineered something useless ? Regards
joel falcou wrote:
I was pondering how to event or at least warn users when they use a .a compiled with a set of define with an application compiled with divergent options (like having different -D that may cause ODR violation).
On IRC, I was linked to this page for MSVC 10:
http://msdn.microsoft.com/en-us/library/ee956429.aspx
That defiens some pragma that exactly do that. However, it's MSVC 10 specific.
After a few brainstorming, we ended up with a simple solution to emulate this. The code source is here:
http://dl.dropbox.com/u/3819406/lib_check.tar.gz
Here is a use case:
g++ -c foo.cpp -o foo.o -I/usr/local/include/boost-1_43 -DGOOD_LIB g++ -c main.cpp -o bmain.o -I/usr/local/include/boost-1_43 -DBAD_LIB -I./ g++ -c main.cpp -o gmain.o -I/usr/local/include/boost-1_43 -DGOOD_LIB -I./ Here, we compiel foo with some settings and try to link it with two different setup for main.o The gcc output, showing the divergence in option is detected:
g++ bmain.o foo.o -o bmain bmain.o: In function `__static_initialization_and_destruction_0(int, int)': main.cpp:(.text+0x2a): undefined reference to `boost::config::test_library_version_mismatch_with_version_being_2()' collect2: ld returned 1 exit status
Of course, when you link the good pair of .o : g++ gmain.o foo.o -o gmain
Nothing happens
I guess some details need to be hammered out like visibility and such but could this be a valuable addition to boost (liek boost config for example) or have I overengineered something useless ?
I think this might be related to an idea I posted last may: http://lists.boost.org/Archives/boost/2010/05/166356.php I'm not sure if this is the same or different Robert Ramey
Sounds very useful to me! -- Dave Abrahams (mobile) BoostPro Computing http://www.boostpro.com On Aug 4, 2010, at 5:04 PM, joel falcou <joel.falcou@lri.fr> wrote:
I guess some details need to be hammered out like visibility and such but could this be a valuable addition to boost (liek boost config for example) or have I overengineered something useless ?
In message <4C59D5CE.9010208@lri.fr>, joel falcou <joel.falcou@lri.fr> writes
I was pondering how to event or at least warn users when they use a .a compiled with a set of define with an application compiled with divergent options (like having different -D that may cause ODR violation).
... It might be worth mentioning the --detect-odr-violations option of the gcc gold linker here. No? -- Alec Ross
On 05/08/10 11:44, Alec Ross wrote:
It might be worth mentioning the --detect-odr-violations option of the gcc gold linker here. No? Yup but it can't detect major version chaneg in ABI or other misconfiguration I guess ? Here's a gist with updated file includign symbol visibility and a more complex use case.
http://gist.github.com/509783 You can compile foo.cpp into foo.a with either no feature, feature A and/or B. Then compile main with same/different set of feature and try to link.
participants (4)
-
Alec Ross -
Dave Abrahams -
joel falcou -
Robert Ramey