libfricas.al compilation and ulimit -s and segfault at LODOF2

[Ralf Hemmecke]

Concerning the already merged pull request

https://github.com/fricas/fricas/pull/212

I've now found something.

On my laptop my script sets "ulimit -s unlimited".

In fact there is a slightly different behaviour between
commit 86435d86eca35969dc5a2c806e86e1b90c16efe9 and
commit e765daddde4da190de0aae181d68c368d7513c6a when
you enter "ulimit -s 4096" before compiling the fricas-aldor interface.
At least on my laptop it will fail with Peter's patch but still succeed
without it.

For "ulimit -s 8192" it will go through in both cases.

Maybe that is not a very big problem nowadays.
However, I wanted to mention it here on the mailing list.

============================
...
Segmentation fault
rm libfricas_LODOF2.al
...
ar: creating al/libfricas.al
ar: ao/LODOF2.ao: No such file or directory
make[1]: *** [Makefile2:235: al/libfricas.al] Error 1
make[1]: Leaving directory '/dev/shm/hemmecke/fricas/b/src/aldor'
make: *** [Makefile:441: al/libfricas.al] Error 2

============================

[Waldek Hebisch]

On Thu, Mar 05, 2026 at 05:36:57PM +0100, 'Ralf Hemmecke' via FriCAS - computer algebra system wrote:
> Concerning the already merged pull request
>
> https://github.com/fricas/fricas/pull/212
>
> I've now found something.
>
> On my laptop my script sets "ulimit -s unlimited".
>
> In fact there is a slightly different behaviour between
> commit 86435d86eca35969dc5a2c806e86e1b90c16efe9 and
> commit e765daddde4da190de0aae181d68c368d7513c6a when
> you enter "ulimit -s 4096" before compiling the fricas-aldor interface.
> At least on my laptop it will fail with Peter's patch but still succeed
> without it.
>
> For "ulimit -s 8192" it will go through in both cases.
>
> Maybe that is not a very big problem nowadays.
> However, I wanted to mention it here on the mailing list.

I general we try to avoid large stack space use. But IMO in this
case disk space use is more problematic than stack space use,
so I think we can postpone solving this.

More important question is if there is any undesirable change to
libfricas.al? With default stack setting the interface builds
and on my machine I get bit-identical libfricas.al, so for me
it looks that there is no problem.

--
Waldek Hebisch

[Ralf Hemmecke]

> More important question is if there is any undesirable change to
> libfricas.al? With default stack setting the interface builds
> and on my machine I get bit-identical libfricas.al, so for me
> it looks that there is no problem.

Right. I am OK with Peter's patch.
Release can happen.

Ralf