Re: [polyml] polyc and libraries

[David Matthews]

Phil,
I've now added -lpolymain to polyml.pc.in so that should handle your 
specific problem.  Can you check it?  I'd be happy if you could produce 
an improved version of this.  It's not something I use or have any 
familiarity with.

Regards,
David

On 19/12/2017 21:47, Phil Clayton wrote:

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

Re: [polyml] Assertion failure in scanaddrs

[Ramana Kumar]

Oh you're right - thanks David.
(I think this is because 5.6 is the stable Debian package for the
regression machines. On my personal machine I use 5.7.1)

On 15 Jan 2018 20:35, "David Matthews" 
wrote:

> Are you running an old version of Poly/ML?  This looks familiar and the
> location of the assertion fault would suggest that it's 5.6.  There have
> been two releases since then.
>
> Regards,
> David
>
> On 15/01/2018 07:47, Ramana Kumar wrote:
>
>> I got this error building the CakeML regression test (
>> https://cakeml.org/regression.cgi/job/152):
>>
>> scanaddrs.cpp:218: void ScanAddress::ScanAddressesInRegion(PolyWord*,
>> PolyWord*): Assertion `obj->ContainsNormalLengthWord()' failed.
>>
>> Is this worth further investigation? I presume it's somehow due to high
>> memory pressure, though it'd be nice to be more robust to that with a
>> graceful fail.
>>
>>
>>
>> ___
>> 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

Re: [polyml] Assertion failure in scanaddrs

[David Matthews]

Are you running an old version of Poly/ML?  This looks familiar and the 
location of the assertion fault would suggest that it's 5.6.  There have 
been two releases since then.


Regards,
David

On 15/01/2018 07:47, Ramana Kumar wrote:

I got this error building the CakeML regression test (
https://cakeml.org/regression.cgi/job/152):

scanaddrs.cpp:218: void ScanAddress::ScanAddressesInRegion(PolyWord*,
PolyWord*): Assertion `obj->ContainsNormalLengthWord()' failed.

Is this worth further investigation? I presume it's somehow due to high
memory pressure, though it'd be nice to be more robust to that with a
graceful fail.



___
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