> > outputdir/%.o: %.cpp > $(CXX) $(CXXFLAGS) -I/path/for/includes -std=c++0x -c -o $@ $< > > CXXFLAGS should probably include -fPIC and -shared. Otherwise, you can > have problems in library constructors and destructors. > > Also, when linking an archive in the final executable, you will want to > link with -Wl,--exclude-libs,ALL. Otherwise, you can get violations of > the One Definition Rule (ODR) *if* two different libraries each include > the archive. The symptom is often (from my experience) a glibc crash > due to a double free triggered by the destructors during unload. Jeff, Sorry for the confusion. My examples were excerpts from the build system. The archive part of the build must be a static compilation, thus, the absence of the -fPIC option and -shared. However, all of the objects that wrap this functionality, and are "directly" included into the *.so are built with -fPIC. I read in the gcc manual that -shared is supposed to be used for the generation of *.so files. Thus, the build line for the *.so file does have both -fPIC and -shared. This other item you mention is quite interesting. Presently, the only thing I'm building which includes this archive is this one shared library. I think that with the -Wl,--whole-archive ... -Wl,--no-whole-archive option to gcc is the ticket for me. Thus far, my unit tests show no destruction/garbage collection errors from python. Thank you for this information though because I'm sure some ingenious consumer of our library will try doing this at some point. Knowing this just prepares me to contend for that possibility. Andy
