David,
I think I would expect `pkg-config --libs polyml` to provide the linker
flags required to create an executable, i.e. I wouldn't expect to have
to specify -lpolymain additionally. I can't think of any other use
cases of pkg-config because Poly/ML can't be used to produce a library.
Even if it could, I don't believe adding -lpolymain would cause
overlinking because only an archive version of libpolymain is available
(and should always be available) and this shouldn't be included by the
linker if there is no reference to the symbol "main".
For Poly/ML built with --disable-shared, Libs still has all the linker
flags, as I would expect, except for -lpolymain. If -lpolymain is
added, it appears that it would need to be added _before_ -lpolyml
(where it used to be), at least for my Linux distribution.
On a separate note, for Poly/ML built with --enable-shared, I believe
that the flags recently removed to avoid overlinking should still be
produced if `pkg-config --static ...` is used, so should appear in
Libs.private. However, it looks like this is only useful in the unusual
case where all dependencies are to be statically linked. Most
distributions don't supply archives for all libraries so that isn't
usually possible. For Poly/ML built with --enable-shared, static
linking of the Poly/ML library but not its dependencies is possible, e.g.
gcc file.o \
-Wl,-Bstatic \
-L/tmp/polyml/lib -lpolymain -lpolyml \
-Wl,-Bdynamic \
-lpthread -lffi -lgmp -lm -ldl -lstdc++ -lgcc_s -lgcc
but `pkg-config --static ...` can't produce such commands. Such a
command could be produced with some shell trickery to get static-only
dependencies, so perhaps it is worth supporting --static.
Finally, I note that libffi has its own PC file, so when Poly/ML is
built with --with-system-libffi, instead of adding -lffi to
Libs/Libs.private, libffi could be added to Requires/Requires.private,
respectively.
Phil
On 18/12/17 15:47, David Matthews wrote:
Phil,
I'm not exactly clear how pkg-config is supposed to be used. It's
certainly possible to add -lpolymain explicitly to the libraries in
polyml.pc.
David
On 17/12/2017 21:57, Phil Clayton wrote:
David,
On Fedora 25, polyc still appears to work for shared poly with this
change. However, there is an issue for pkg-config because the libs
section in polyml.pc no longer includes the flag -lpolymain causing a
link error:
/usr/lib/gcc/x86_64-redhat-linux/6.4.1/../../../../lib64/crt1.o: In
function `_start':
(.text+0x20): undefined reference to `main'
collect2: error: ld returned 1 exit status
Regards,
Phil
On 12/12/17 13:14, David Matthews wrote:
The polyc script has been developed mainly to simplify the linking of
an exported ML function and in particular to try to capture the
libraries that need to be included. I've been having another look at
this because of an issue that was reported a while back. Up till now
the linking step has included all the libraries that were needed in
order to link libpolyml itself. That was extracted by the configure
script. It turns out that this is right if libpolyml is compiled as
a static library but has a problem if libpolyml is a dynamic library.
Object files exported by PolyML.export make reference to external
symbols from libpolyml but do not directly reference anything else.
If libpolyml is a dynamic library it exports these symbols but all
the other dependencies are satisfied by loading the appropriate
libraries dynamically.
The issue was reported in the Fedora distribution but may also affect
other distributions that package up Poly/ML and have separate
packages for libraries (e.g. libgmp and libffi) and development
packages. They were building libpolyml as a shared library but
because polyc included the dependencies of libpolyml itself polyc was
including -lgmp -lffi in the link step. This meant that it needed
the development versions of these libraries even though they were not
actually used.
I've now modified the configure script so that polyc only includes
the dependent libraries if libpolyml has been built with shared
libraries disabled and at the same time changed the default so that
it builds a shared library unless --disable-shared is given.
Hopefully this hasn't broken anything but I'd appreciate any reports
of problems.
David
_______________________________________________
polyml mailing list
polyml@inf.ed.ac.uk
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
_______________________________________________
polyml mailing list
polyml@inf.ed.ac.uk
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
_______________________________________________
polyml mailing list
polyml@inf.ed.ac.uk
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
_______________________________________________
polyml mailing list
polyml@inf.ed.ac.uk
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
