[gecode-users] Compiling statically

[Lars Kotthoff]

> One  problem with the current build system is that if you've built dynamic
> libs before and they're still in the directory, they will be used for
> linking.  If you --enable-static --disable-dynamic in a fresh source
> directory, the executables should be linked against the static Gecode  libs.

./configure --enable-static --disable-dynamic && make
in a clean source directory builds the static and dynamic libs (by which I mean
the .a and .so files) and links the example binaries dynamically, e.g.

[larsko at akiba:~/gecode-3.2.1]0 $ ldd examples/golomb-ruler
	linux-gate.so.1 =>  (0xb7f8b000)
	libgecodeflatzinc.so.19 (0xb7f3d000)
	libgecodedriver.so.19 (0xb7f31000)
	libgecodesearch.so.19 (0xb7f1c000)
	libgecodescheduling.so.19 (0xb7edf000)
	libgecodegraph.so.19 (0xb7ed3000)
	libgecodeminimodel.so.19 (0xb7ec5000)
	libgecodeset.so.19 (0xb7b08000)
	libgecodeint.so.19 (0xb767d000)
	libgecodekernel.so.19 (0xb7674000)
	libgecodesupport.so.19 (0xb7670000)
	libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7564000)
	libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb753e000)
	libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7520000)
	libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb7507000)
	libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb73bf000)
	/lib/ld-linux.so.2 (0xb7f8c000)

> Another question is whether they should be  linked fully statically  
> after configuring with --enable-static, or just use the static Gecode  
> libs but still link libstdc++ dynamically.  No idea what's more useful  
> there - but I guess we could add -static to the linker options.

I think they should be completely static to avoid problems with different
versions of libstdc++ on different systems, especially since this library is not
strictly required.

Lars