xalloc/omalloc.h tries to include omalloc/omConfig.h which does not exist

[Jean-Pierre Flori]

Removing the offending include seems to fix the problem.

Best,
JP

[Jean-Pierre Flori]

On Monday, September 5, 2016 at 1:20:05 PM UTC+2, Jean-Pierre Flori wrote:

Removing the offending include seems to fix the problem.

But then leads to other errors.
Maybe adding a
nodist_libomalloc_include_HEADERS = omConfig.h
in xalloc/configure.ac is a the solution if omConfig.h is actually needed.

[Jean-Pierre Flori]

I meant in xalloc/Makefile.am.
And it indeed seems to be a correct solution.

By the way, it would be handy to run autoreconf in the xalloc folder when making dits tarballs.
That way, it is sufficient to replace the omalloc folder by the xalloc one to use xalloc in place of omalloc (and one does not need to have autotools installed).

[han...@mathematik.uni-kl.de]

On Tue, Sep 06, 2016 at 03:47:44AM -0700, Jean-Pierre Flori wrote:
> On Monday, September 5, 2016 at 6:19:49 PM UTC+2, Jean-Pierre Flori wrote:
>
> On Monday, September 5, 2016 at 1:20:05 PM UTC+2, Jean-Pierre Flori
> wrote:
>
> Removing the offending include seems to fix the problem.
>
> But then leads to other errors.
> Maybe adding a
> nodist_libomalloc_include_HEADERS = omConfig.h
> in xalloc/configure.ac is a the solution if omConfig.h is actually
> needed.
>
> I meant in xalloc/Makefile.am.
> And it indeed seems to be a correct solution.

omConfig is not really needed, it can be easliy removed:
see
http://www.singular.uni-kl.de:8002/trac/changeset/bebd5a0361ed499fa0769cad9424e1bb193acd7c/git

[Jean-Pierre Flori]

Hum, my firewall does not like high ports (that's why I report issues here rather than on the bug tracker).
I'll have a look on github.

[Jean-Pierre Flori]

My maybe naive questoin is then: is it necessary for omalloc at build and runtime? or just at build time?

[han...@mathematik.uni-kl.de]

On Thu, Sep 08, 2016 at 07:08:19AM -0700, Jean-Pierre Flori wrote:
> My maybe naive questoin is then: is it necessary for omalloc at build and
> runtime? or just at build time?

xalloc is an alternative to omalloc: one can use either, but not both
- not at compile time, and not at runtime.

The original purpose of xalloc was to find bugs/memory leaks with
valgrind. It is also used in environments which do not allow the use
of omalloc (mainly: omalloc is currently not thread safe).
Otherwise xalloc should not be used: it is slower
und consumes more memory.

[han...@mathematik.uni-kl.de]

> http://www.singular.uni-kl.de:8002/trac/changeset/bebd5a0361ed499fa0769cad9424e1bb193acd7c/git
>
> Hum, my firewall does not like high ports (that's why I report issues here
> rather than on the bug tracker).
> I'll have a look on github.

https://github.com/Singular/Sources/commit/bebd5a0361ed499fa0769cad9424e1bb193acd7c

[Jean-Pierre Flori]

Sure, I was not speaking of using xalloc and omalloc at the same time.
I was thinking of the runtime need to have omConfig.h for a omalloc compiled Singular.

[han...@mathematik.uni-kl.de]

On Thu, Sep 08, 2016 at 08:29:53AM -0700, Jean-Pierre Flori wrote:
> Sure, I was not speaking of using xalloc and omalloc at the same time.
> I was thinking of the runtime need to have omConfig.h for a omalloc
> compiled Singular.

It is necessary at compile time: it contains the result of configure:
not only properties of os and libc, but also of the architecture:
sizeof(long) and sizeof(void*) are important to omalloc,
xalloc relies on malloc and the sizeof operator.
At runtime it is not needed (unless you want to build dynamic modules,
but then all headers are needed).

[Jean-Pierre Flori]

Another xmalloc related issue:
it does not install a .pc file which might lead to failures when linking.
Here is the patch Sage now uses:
https://git.sagemath.org/sage.git/tree/build/pkgs/singular/patches/src/xalloc.pc.patch?id=8a992952b7ec660423ca06e0aa3d3931435bf7ba

Best,
JP

[Francois Bissey]

I should add that my patch (linked to by Jean-Pierre) is not particularly pretty.

One of the main point compared to malloc, is that " -DOM_NDEBUG” is
not added to CFLAGS. The other point is that I had to
explicitly put “-lomalloc” in Libs since leaving @PACKAGE@ as
in omalloc.pc.in leads to
“-lxalloc”
in Libs instead. But a more elegant solution would probably involve
a considerable rewrite.

François

> --
> You received this message because you are subscribed to the Google Groups "libsingular-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to libsingular-de...@googlegroups.com.
> To post to this group, send email to libsingu...@googlegroups.com.
> Visit this group at https://groups.google.com/group/libsingular-devel.
> For more options, visit https://groups.google.com/d/optout.

[han...@mathematik.uni-kl.de]

On Mon, Sep 12, 2016 at 01:38:20AM -0700, Jean-Pierre Flori wrote:
> Another xmalloc related issue:
> it does not install a .pc file which might lead to failures when linking.

Thanks, merged it, with the difference of setting the pacakage name to
omalloc.
(https://github.com/Singular/Sources/commit/58543e3f682941d3b62b869286d766749a9a385b)

[han...@mathematik.uni-kl.de]

On Mon, Sep 12, 2016 at 08:52:44AM +0000, Francois Bissey wrote:
> One of the main point compared to malloc, is that " -DOM_NDEBUG” is
> not added to CFLAGS. The other point is that I had to
> explicitly put “-lomalloc” in Libs since leaving @PACKAGE@ as
> in omalloc.pc.in leads to
> “-lxalloc”

This should be solved by the now created omalloc.pc
and a define of OM_NDEBUG in omalloc.h

I do not want to put too much effort into xalloc as we use it only for
exotic debugging stuff.