Volker Braun wrote: > On Sunday, August 7, 2016 at 5:26:56 PM UTC+2, Simon King wrote: > > - My cohomology code (Python/Cython) cimports from sage.libs.modres, > sage.libs.meataxe and sage.matrix.matrix_gfpn_dense. > I build all these extension modules with > libraries = ['mtx', 'modres'] > in module_list.py. Is that a mistake, i.e., can I drop mtx from the > list? > > > No, you can't. > > 1. Drop upstream's choice and build libmtx as a shared library. > > > IMHO thats the way to go if you are building other C-level shared > libraries anyways. Besides the pain points with globals, you'll never > get yourself confused whether some shared library included an old or a > new version of libmtx...
But no short-term solution. Building a shared instead of a static library doesn't solve problems but only shifts them (and may introduce even more), if the library isn't prepared. Writing a good library [interface] (as opposed to some module(s) you simply link in) is one thing; preparing a given library to be used as a shared library is another step. As is, I'd say MeatAxe isn't very suited, and it may for example be better to keep at least the MeatAxe programs statically linked to libmtx. (They'll get rebuilt on upgrade anyway.) But the main problem, from what I've seen, seems to be its weird handling of file(name)s. If I'm not mistaken, there are rather static files which get generated once (e.g. at build/installation time), afterwards only read, and which should be located somewhere in SAGE_LOCAL/share/..., but MeatAxe (at least by default) uses the *same* folder also for "scratch" files, and user-generated persistent files. And it doesn't determine the location of a file specified by the user by absolute vs. relative [path]name (or simply basename), but expects *every* file <foo> to be located in MtxLibDir/<foo>, leading to the need to continually change MtxLibDir (which I think wasn't intended by the original authors) just to read or write any file which isn't supposed to be located in MeatAxe's "static" LibDir. So I'd start by improving that. If there's no need to change MtxLibDir, but perhaps only set some "private" MtxWorkDir (and possibly MtxUserLibDir), the problems would already get smaller. (Ideally, the whole context would be passed in each call. But adding that to a few functions operating on files, especially those that create/write to files, might be sufficient.) Another, orthogonal thing to do is to properly prefix any [global] symbols, and optionally also let the user specify the (or an additional) prefix when building and using the library. That way you could even include two different versions of libmtx in the same binary, likewise easily link to two or more libraries which use different instances of libmtx (which I'm not suggesting, but potentially useful as a simple work-around). -leif -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
