Problems building a Mandriva rpm

13 views
Skip to first unread message

pcpa

unread,
Jan 13, 2011, 11:07:19 AM1/13/11
to freemat-devel
Hi,

I am working on a mandriva freemat rpm, but so far was not able to
get a functional package.
Sources are at http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/freemat/current/
After building the package I searched a bit to attempt to check if
others would have found
the same issue, but the archlinux patch does not correct all issues.

Example of issue, attempting to run some of the examples in the
Online Help, e.g. entry
for acos:

--> t = linspace(-1,1);
In /home/share/FreeMat/toolbox/array/linspace.m(linspace) at line 21
In docli(builtin) at line 1
In base(base)
In base()
In global()
Error: Undefined function or variable len

or basic ones:
--> 1
ans =
1
--> 1+1
ans =
[]

--> i
ans =
0,0000 + 1,0000i
--> i+1
Error: out of range
--> abs([1])
ans =
[]
--> abs([1,2])
ans =
1 2
--> abs([1,2,3])
ans =
1 2 3
--> abs([1,-2,3])
ans =
1 3

I also tried building static libraries, instead of dynamically linking
to the
freemat libraries, but same results (cmake -
DBUILD_SHARED_LIBS:BOOL=OFF).

Input also appears to be broken as I cannot type a single quote ('),
as
it prints what appears to be a dead-acute character in the console,
and, it does not like arguments for functions that require a string,
as
it apparently does not correctly read single quotes from files also.

Any ideas about what may be wrong?

Thanks,
Paulo

Eugene

unread,
Jan 13, 2011, 1:27:53 PM1/13/11
to freema...@googlegroups.com
Dear Paulo,

I think I know what the problem is. Could you try running freemat
from
command prompt using the following

LC_NUMERIC="en_US.UTF-8" FreeMat &

If you feel up to the challenge it would be great if you could build
from current svn source - that should work without the command line
variable.

Either way, you should use "." as decimal separator.
Eugene

Paulo César Pereira de Andrade

unread,
Jan 13, 2011, 3:21:52 PM1/13/11
to freema...@googlegroups.com
2011/1/13 Eugene <gen...@gmail.com>:
> Dear Paulo,

Many Thanks Eugene, the svn version indeed corrected the issues,
and also built cleanly with llvm-2.8 (but I did not make much tests).

> I think I know what the problem is. Could you try running freemat
> from
> command prompt using the following
>
> LC_NUMERIC="en_US.UTF-8" FreeMat &

I tried that also, but it would show the same problems.

> If you feel up to the challenge it would be great if you could build
> from current svn source - that should work without the command line
> variable.

Actually, it was quite easier compared to making the 4.0 tarball
work with latest upstream versions, as in Mandriva Cooker :-)

The rpm spec should be quite simpler now also.

Probably major issues in my packaging of a checkout of svn trunk
should be:

o missing symbols in the lapack generated library, but maybe now
it would work, I did not test it after changing (back) to not generate
dynamic libraries and installing them
o may need to regenerate the documentation or it fails in make
install due to .pdf filename change

I should update the mandriva svn for Freemat soon, and also soon,
a package should be made available.

> Either way, you should use "." as decimal separator.
> Eugene

Thanks Again,
Paulo

Paulo César Pereira de Andrade

unread,
Jan 14, 2011, 11:43:31 AM1/14/11
to freema...@googlegroups.com
2011/1/13 Eugene <gen...@gmail.com>:

> Dear Paulo,
>
> I think I know what the problem is. Could you try running freemat
> from
> command prompt using the following
>
> LC_NUMERIC="en_US.UTF-8" FreeMat &
>
> If you feel up to the challenge it would be great if you could build
> from current svn source - that should work without the command line
> variable.

BTW, do you have any suggestions to changes in the spec file,
for example, summary or description, or requirements for splitting
the package, etc?
(http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/freemat/current/)

Also, what would be a proper procedure (preferably automated) to
run tests to ensure the package is fully functional?

> Either way, you should use "." as decimal separator.

I had some related problems in the sagemath package I
also maintain, e.g. writing a file using pt_BR-UTF8 locale,
and reading it expecting another LC_NUMERIC, or python
code checking for untranslated errors messages, instead
of checking error codes...

> Eugene

Thanks,
Paulo

Reply all
Reply to author
Forward
0 new messages