Compiling LUA scripting language

[czerny]

I hope it looks better now.

Yes! 

[q1q2q3q4]

I need to build lua static library and then use it in another programming language (PureBasic).

This is my PureBasic source code for checking if lua library works:

Code Select Expand

ImportC "liblua52.lib"
  luaL_newstate()
EndImport

L=luaL_newstate()

But when i compile and run this source, i get error:

Code Select Expand

POLINK: error: Unresolved external symbol '_errno'.
POLINK: error: Unresolved external symbol '___stdin'.
POLINK: error: Unresolved external symbol '___stderr'.
POLINK: error: Unresolved external symbol '___stod'.
POLINK: error: Unresolved external symbol '___locale'.
POLINK: fatal error: 5 unresolved external(s).

I used dev c++ in the past to compile lua static library and that worked but now with PellesC i get this error. Can anyone help me or give any tips how to make it work?

Thanks

[Bitbeisser]

Zip the project and post the ZIP file here, so we can see what your settings are...

Ralf

[q1q2q3q4]

Zip the project and post the ZIP file here, so we can see what your settings are...

Ralf

I used project file attached in this thread by user Fuzzlix:
http://forum.pellesc.de/index.php?topic=5365.msg20665#msg20665
And lua sources:
http://www.lua.org/ftp/lua-5.2.3.tar.gz

I am trying to build 32bit static library to use it in PureBasic 5.30.

Thanks in advance

[Fuzzlix]

I used project file attached in this thread by user Fuzzlix:
http://forum.pellesc.de/index.php?topic=5365.msg20665#msg20665
And lua sources:
http://www.lua.org/ftp/lua-5.2.3.tar.gz

I am trying to build 32bit static library to use it in PureBasic 5.30.

Thanks in advance

I am very sorry but building a bug free lua using PellesC is not possible caused by a unfixed bug:
For instance:  "local a = 19267 + 22387" does not result in 41654 but in 41654.000000001 (or something similar) You can print this result using "print(a)" and you get "41654" but using this computation result in a for loop leeds to unwantet behaviour.
This bug is well known many years now but still unfixed. So there was only one way for me to get a working lua: Step away from  PellesC. I am very sorry about that.

Fuzzlix.

[jj2007]

I am very sorry but building a bug free lua using PellesC is not possible caused by a unfixed bug:
For instance:  "local a = 19267 + 22387" does not result in 41654 but in 41654.000000001 (or something similar) You can print this result using "print(a)" and you get "41654" but using this computation result in a for loop leeds to unwantet behaviour.

Hi Fuzzlix,

adding two floats will never result in an exact result - this is the nature of float numbers, not a bug. Use integers for loops.

[frankie]

Yes JJ the floating number are never correct because some of them cannot be represented exactly in binary radix (they generate irrational number or irridicible fractions), but unfortunately lua has only double precision floats  .
But this problem is well known in lua programming. Infact there are a lot of raccomandations to not use equal operator (see), that is true also in 'C' when dealing with floats. The reason is that the language can be used in a lot of machines and compilers so you cannot expect that the floating point behavior is always the same.
To correctly program numeric comparisons in lua is to prefer 'less than' or 'greater then' instead of 'equal'.
A special case is when you expect always an integer number (the fractional part is expected to be 0) in that case you can use one of the two math functions ceil or floor.
Fuzzlix you made a very good job creating the workspace to compile lua (it works like a charm  ), may I suggest to adjust project dependencies (the two executables depending on libraries) so by simply clicking 'project->rebuild workspace' the whole project compiles correctly?

[Fuzzlix]

You may want to modify my project files for your personal needs. Thats ok.

But still this strange behaviour of Numbers in PellesC makes it impossible to compile a working lua interpreter. It works using MSC. It works using GCC. And i found no solution. There need something beeing fixed in the C runtime.

Fuzzlix.

[frankie]

You may want to modify my project files for your personal needs. Thats ok.

It was a suggestion to you to fix a problem, i.e. if you try to buld the whole workspace, without project dependencies, you may experience errors due to missing libs. Defining dependencies you can compile from scratch in correct order (first libraries than executables) with a single click (project->rebuild workspace).

But still this strange behaviour of Numbers in PellesC makes it impossible to compile a working lua interpreter. It works using MSC. It works using GCC. And i found no solution. There need something beeing fixed in the C runtime.

It is not a 'strange behaviour', but a rounding problem. For a compiler that works as you expected (GCC use the MSVCRT runtime so acts as MSVC) there are many more that could behave differently: like or even worst than PellesC. That's why there are special raccomandations about numbers compare in lua.
Anyway you can compile the lua libraries with msvcrt so using the same runtime the problem will disappear 

[czerny]

I am very sorry but building a bug free lua using PellesC is not possible caused by a unfixed bug:
For instance:  "local a = 19267 + 22387" does not result in 41654 but in 41654.000000001 (or something similar)

I can not reconstruct this behavior!
The following code prints 41654.000000000000000 as expected:

Code Select Expand


#include <stdio.h>

int main(int argc, char **argv)
{
printf("%.15f\n", 19267.0 + 22387.0);
double a=19267.0;
double b=22387.0;
printf("%.15f\n", a+b);
double c = a + b;
printf("%.15f\n", c);
return 0;
}