David,
Thanks for the explanation in your previous message. I was wrong to think that the linking method used to build Poly/ML fixes the way Poly/ML-based applications are linked. I must have been getting the gcc flags wrong when I was trying this a few years ago. Most likely, it was just the absence/presence of the dynamic libraries due to Poly/ML configure flags that actually caused what I saw.
On 15/04/13 12:17, David Matthews wrote:
On 12/04/2013 12:54, David Matthews wrote:
Based on this, I think there would be a case for setting the default for Poly/ML to be --disable-shared so that producing the dynamic version requires an explicit option.
I've now committed this change. The default is now not to build the shared library but that can be overridden with --enable-shared. Like any change in SVN it's always provisional so it can be reverted if necessary. I'd like feedback either for or against.
The main downside that I can see with this approach is that the SO files are not built or installed. Therefore, with a standard installation, it would not be possible for a Poly/ML-based application to choose whether to link dynamically or statically to the Poly/ML libs.
Now that I have had a chance to play around, dropping the SO files seems a little drastic to get polyc to link statically, so avoid the LD_LIBRARY_PATH issue. I found that replacing (both occurrences of)
-L${LIBDIR} -lpolymain -lpolyml
in polyc with
${LIBDIR}/libpolymain.a ${LIBDIR}/libpolyml.a
effected static linking even when Poly/ML was built with --enable-shared. In fact only libpolyml needs changing, i.e.
-L${LIBDIR} -lpolymain ${LIBDIR}/libpolyml.a
suffices, because libpolymain has only a static library.
Phil