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
_______________________________________________
polyml mailing list
[email protected]
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
