Does the linker on t2 mix names up?

[Simon King]

Hi!

This is the summary of a discussion that David Kirkby and I had off
list.

I tried to build the optional p_group_cohomology package on t2 -
successful, so it first seemed (it built with no error). The package
includes a Cython wrapper for the Aachen C-MeatAxe. When I created a
matrix and wanted to extract a row, a segfault occured. Sage's "last
words" stated that there was a wrong type in "matextract".

"matextract" is a function of the C-MeatAxe. The error message did not
state if the error is in the function body or in the function
arguments. But I soon found it was the latter. Strange, since the
first argument was a cdef attribute of a Cython object (and definitely
has the right type), while the other two arguments were of type <long>
(and Cython should automatically cast Sage integers to long, if
necessary). Shouldn't this kind of error occur at compile time? And
why did it not occur, say, on bsd.math (neither 32 nor 64 bit)?

Eventually, I was able to solve the problem: It sufficed to *rename*
the function. If it is called "_matextract" then things work fine (and
I can even compute group cohomology on t2).

But what went wrong?

Could it be that somewhere another "matextract" is defined (this can
only be outside the package) and the linker confuses the two? I this
was the case, then the problem may be related with trac ticket #1396,
where rumours state that the linker mixes Singular's variable
"mu" (which fortunately got renamed "Kstd1_mu" in Singular 3-1-1) with
another mu.

Best regards,
Simon

[Simon King]

PS:

On 6 Aug., 20:45, Simon King <simon.k...@nuigalway.ie> wrote:
> ... includes a Cython wrapper for the Aachen C-MeatAxe. When I created a
> matrix ...

By "matrix", I referred to a wrapped C-MeatAxe matrix.

[John H Palmieri]

On Aug 6, 11:45 am, Simon King <simon.k...@nuigalway.ie> wrote:
> Hi!
>
> This is the summary of a discussion that David Kirkby and I had off
> list.
>
> I tried to build the optional p_group_cohomology package on t2 -
> successful, so it first seemed (it built with no error). The package
> includes a Cython wrapper for the Aachen C-MeatAxe. When I created a
> matrix and wanted to extract a row, a segfault occured. Sage's "last
> words" stated that there was a wrong type in "matextract".
>
> "matextract" is a function of the C-MeatAxe. The error message did not
> state if the error is in the function body or in the function
> arguments. But I soon found it was the latter. Strange, since the
> first argument was a cdef attribute of a Cython object (and definitely
> has the right type), while the other two arguments were of type <long>
> (and Cython should automatically cast Sage integers to long, if
> necessary). Shouldn't this kind of error occur at compile time? And
> why did it not occur, say, on bsd.math (neither 32 nor 64 bit)?
>
> Eventually, I was able to solve the problem: It sufficed to *rename*
> the function. If it is called "_matextract" then things work fine (and
> I can even compute group cohomology on t2).
>
> But what went wrong?
>
> Could it be that somewhere another "matextract" is defined (this can
> only be outside the package) and the linker confuses the two?

I don't know the answer about what the linker is doing, but matextract
is also in

SAGE_ROOT/local/include/pari/paridecl.h

(found by using grep and find -- I really hate the find command, it
always takes me half an hour to work out the syntax to use).

--
John

[Dr. David Kirkby]

On 08/ 6/10 08:21 PM, John H Palmieri wrote:

> I don't know the answer about what the linker is doing, but matextract
> is also in
>
> SAGE_ROOT/local/include/pari/paridecl.h
>
> (found by using grep and find -- I really hate the find command, it
> always takes me half an hour to work out the syntax to use).
>
> --
> John

John, without knowing exactly what you were doing, I don't know how to suggest
you use find, though I agree its not the easiest command.

However, I suspect the -R (recursive) option to GNU grep would have done what I
suspect you wanted.

Note, in that below. I've not shown all the output - it is taking ages, but I
think you can see how you can search files like this quickly.

kirkby@t2:[~/sage-4.5.2.alpha1] $ /usr/sfw/bin/ggrep -R matextract *
data/extcode/pari/cremona/ell_baby.gp:m=factorback(matextract(fm,concat("^",Str(j)))~);
Binary file data/extcode/genus2reduction/core matches
devel/sage/sage/libs/pari/decl.pxi: GEN matextract(GEN x, GEN l1, GEN l2)
devel/sage-main/sage/libs/pari/decl.pxi: GEN matextract(GEN x, GEN l1,
GEN l2)
ggrep: local/lib/python2.6/python2.6: Number of symbolic links encountered
during path name traversal exceeds MAXSYMLINKS
Binary file local/lib/libpari.so matches
ggrep: local/lib/python/python2.6: Number of symbolic links encountered during
path name traversal exceeds MAXSYMLINKS
Binary file local/lib/libpari-gmp.so.2 matches
Binary file local/lib/libpari.a matches
Binary file local/lib/libpari-gmp.so.2.3.5 matches
local/include/pari/paridecl.h:GEN matextract(GEN x, GEN l1, GEN l2);
ggrep: local/LIB/python2.6/python2.6: Number of symbolic links encountered
during path name traversal exceeds MAXSYMLINKS
Binary file local/LIB/libpari.so matches
ggrep: local/LIB/python/python2.6: Number of symbolic links encountered during
path name traversal exceeds MAXSYMLINKS
Binary file local/LIB/libpari-gmp.so.2 matches
Binary file local/LIB/libpari.a matches
Binary file local/LIB/libpari-gmp.so.2.3.5 matches

[Simon King]

Dear John,

On 6 Aug., 21:21, John H Palmieri <jhpalmier...@gmail.com> wrote:
> > Could it be that somewhere another "matextract" is defined (this can
> > only be outside the package) and the linker confuses the two?
>
> I don't know the answer about what the linker is doing, but matextract
> is also in
>
>   SAGE_ROOT/local/include/pari/paridecl.h

That's interesting. If I remember correctly, the problem with
Singular's mu (now: Kstd1_mu) also used to be a mu in pari.
Could be coincidence, of course, and I have no idea why a linker would
use a symbol that is defined in a header file which is not included
(if this is really what is happening here).

Anyway, I know enough to work around...

Cheers,
Simon

[Simon King]

Hi!

On 17 Aug., 21:36, Simon King <simon.k...@nuigalway.ie> wrote:
> That's interesting. If I remember correctly, the problem with
> Singular's mu (now: Kstd1_mu) also used to be a mu in pari.
> Could be coincidence, of course, and I have no idea why a linker would
> use a symbol that is defined in a header file which is not included
> (if this is really what is happening here).

It happened again: There is a function named "matid" in CMeatAxe (part
of my cohomology package) which did not work on t2. It did work when
renaming it into "MTXmatid".

With "grep matid -R SAGE_ROOT/spkg/", I found
./logs/pari-2.3.5.p2.log:pari-2.3.5.p2/src/src/functions/
linear_algebra/matid

So, for the third(!) time, there is a collision of a name in pari with
stuff in different spkgs. I still wonder why the linker would use
stuff from pari when a program refers to a symbol in another specific
file.

For building my extension modules, I use
include_dirs = [SAGE_ROOT+"/local/include/csage/", SAGE_ROOT+"/devel/
sage/", SAGE_ROOT+"/devel/sage/c_lib", SAGE_ROOT+"/devel/sage/sage/
ext", <the source folders of my code>]

Are the include_dirs "polluted" by pari?

Cheers,
Simon

[David Kirkby]

I know there is at some point (I think in the Sage library) where a
file paripriv.h gets included. That caused a hassle on Solaris and
William said he was not surprised, as it was supposed to be a private
file for Pari (hence the "priv") but for some reason it has been
included. So it does not in the least surprise me if definitions from
Pari are colliding with others when a Pari header file gets included.
A similar issue happens on OS X with paripriv.h, and the hack is to
just comment out the lines causing the problem.

I don't understand why a private file is included.

Of course, paripriv.h may be totally unrelated.

Dave

[Simon King]

Hi David,

On 5 Sep., 17:03, David Kirkby <david.kir...@onetel.net> wrote:
> ...

> A similar issue happens on OS X with paripriv.h, and the hack is to
> just comment out the lines causing the problem.

So, renaming the function seems to be a valid solution.

Thanks for the background info!
Simon

[Dr. David Kirkby]

On 09/ 5/10 04:25 PM, Simon King wrote:
> Hi David,
>
> On 5 Sep., 17:03, David Kirkby<david.kir...@onetel.net> wrote:
>> ...
>> A similar issue happens on OS X with paripriv.h, and the hack is to
>> just comment out the lines causing the problem.
>
> So, renaming the function seems to be a valid solution.

Yes, I think so.

I'd certainly look at paripriv.h and avoid anything declared in there.

> Thanks for the background info!
> Simon
>

No problem. I'm not saying that is the cause, but exposing to Sage a lot of
internal stuff of Pari seems a bit unwise.

Dave