[ANN] Lua 5.2.2 (rc1) now available

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
37 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.2 (rc1) now available

Luiz Henrique de Figueiredo
> Then I added
>
>
> #ifndef _WIN32
> #define __cdecl
> #endif
>
> static void __cdecl laction (int i) {
> ____________+++++++

Why is this needed? If so, why now and not before?

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.2 (rc1) now available

Luiz Henrique de Figueiredo
In reply to this post by Dirk Laurie-2
> There's a quirk in the current Firefox that had me fooled.
>
> When I download the file via Firefox, left-clicking on the
> link in the e-mail followed by the "save file" option, the file
> thus save needs to be gunzipped, renamed to its original
> name, and gunzipped again.
>
> It's OK if I right-click and choose "Save link as", or use
> a command-line tool like wget.

What happens with the links in Lua's site, such as those in http://www.lua.org/ftp/ ?

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.2 (rc1) now available

Dirk Zoller-2
In reply to this post by Luiz Henrique de Figueiredo
On 20.02.2013 22:33, Luiz Henrique de Figueiredo wrote:

>> Then I added
>>
>>
>> #ifndef _WIN32
>> #define __cdecl
>> #endif
>>
>> static void __cdecl laction (int i) {
>> ____________+++++++
>
> Why is this needed?

Because signal handlers require it:

   http://msdn.microsoft.com/en-us/library/xdkz3x12%28v=vs.71%29.aspx

> If so, why now and not before?

It was in 5.2.1 too.
As a late adopter, I didn't care mention. Yet on day one...


Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.2 (rc1) now available

Hisham
In reply to this post by Luiz Henrique de Figueiredo
On 20 February 2013 16:46, Luiz Henrique de Figueiredo
<[hidden email]> wrote:
> I'm especially interested in how it fares in the various flavors of
> Linux/BSD/etc, now that we've removed -lncurses from the link line.

It links and runs fine on Linux here with "make linux".

GCC 4.6.0, glibc 2.11.1, binutils 2.21.1, readline 6.0, ncurses 5.7.
All packages are vanilla (straight from the upstream sources) and
compiled on my own machine.

-- Hisham
http://hisham.hm/

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.2 (rc1) now available

Scott Morgan
In reply to this post by Luiz Henrique de Figueiredo
On 20/02/13 19:46, Luiz Henrique de Figueiredo wrote:
> Thanks. It does too in OSX 10.7.5, which is the last one I have access
> to. I'm especially interested in how it fares in the various flavors
> of Linux/BSD/etc, now that we've removed -lncurses from the link line.

Slackware64 13.37
gcc-4.5.2
glibc-2.13
ncurses-5.9
readline-5.2

'make linux' bombed without the -lncurses option.

gcc -o lua   lua.o liblua.a -lm -Wl,-E -ldl -lreadline
/usr/lib64/gcc/x86_64-slackware-linux/4.5.2/../../../../lib64/libreadline.so:
undefined reference to `PC'
/usr/lib64/gcc/x86_64-slackware-linux/4.5.2/../../../../lib64/libreadline.so:
undefined reference to `tgetflag'
/usr/lib64/gcc/x86_64-slackware-linux/4.5.2/../../../../lib64/libreadline.so:
undefined reference to `tgetent'
/usr/lib64/gcc/x86_64-slackware-linux/4.5.2/../../../../lib64/libreadline.so:
undefined reference to `UP'
/usr/lib64/gcc/x86_64-slackware-linux/4.5.2/../../../../lib64/libreadline.so:
undefined reference to `tputs'
/usr/lib64/gcc/x86_64-slackware-linux/4.5.2/../../../../lib64/libreadline.so:
undefined reference to `tgoto'
/usr/lib64/gcc/x86_64-slackware-linux/4.5.2/../../../../lib64/libreadline.so:
undefined reference to `tgetnum'
/usr/lib64/gcc/x86_64-slackware-linux/4.5.2/../../../../lib64/libreadline.so:
undefined reference to `BC'
/usr/lib64/gcc/x86_64-slackware-linux/4.5.2/../../../../lib64/libreadline.so:
undefined reference to `tgetstr'
collect2: ld returned 1 exit status

Added it back in and it built fine.

Scott


Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.2 (rc1) now available

Roberto Ierusalimschy
In reply to this post by Dirk Zoller-2
> >>Then I added
> >>
> >>
> >>#ifndef _WIN32
> >>#define __cdecl
> >>#endif
> >>
> >>static void __cdecl laction (int i) {
> >>____________+++++++
> >
> >Why is this needed?
>
> Because signal handlers require it:
>
>   http://msdn.microsoft.com/en-us/library/xdkz3x12%28v=vs.71%29.aspx

Are you sure?  According to this page, it seems that this declaration
should not be necessary:

  http://msdn.microsoft.com/en-us/library/zkwh89ks%28v=vs.80%29.aspx

  __cdecl
  [...]
  This is the default calling convention for C and C++ programs.
  [...]
  Because the C naming and calling conventions are the default, the
  only time you need to use __cdecl is when you have specified the /Gz
  (stdcall) or /Gr (fastcall) compiler option.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.2 (rc1) now available

Enrico Colombini
In reply to this post by Luiz Henrique de Figueiredo
On 20/02/2013 20.46, Luiz Henrique de Figueiredo wrote:
> I'm especially interested in how it fares in the various flavors of
> Linux/BSD/etc, now that we've removed -lncurses from the link line.

On CentOS 6.3 (2.6.32-279.el6.i686 #1 SMP), which is basically Red Hat,
it compiles and looks OK (after installing readline-devel, as requested).

Also, previous lines seem to be recalled correctly in the interactive
interpreter.

--
   Enrico

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.2 (rc1) now available

Peter Cawley
In reply to this post by Roberto Ierusalimschy
On Thu, Feb 21, 2013 at 1:51 PM, Roberto Ierusalimschy <[hidden email]> wrote:
> >>Then I added
> >>
> >>
> >>#ifndef _WIN32
> >>#define __cdecl
> >>#endif
> >>
> >>static void __cdecl laction (int i) {
> >>____________+++++++
> >
> >Why is this needed?
>
> Because signal handlers require it:
>
>   http://msdn.microsoft.com/en-us/library/xdkz3x12%28v=vs.71%29.aspx

Are you sure?  According to this page, it seems that this declaration
should not be necessary:

  http://msdn.microsoft.com/en-us/library/zkwh89ks%28v=vs.80%29.aspx

  __cdecl
  [...]
  This is the default calling convention for C and C++ programs.
  [...]
  Because the C naming and calling conventions are the default, the
  only time you need to use __cdecl is when you have specified the /Gz
  (stdcall) or /Gr (fastcall) compiler option.

The alternative way of phrasing the above is that you need "__cdecl" there just in case the code is compiled with /Gz or /Gr. 

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.2 (rc1) now available

Dirk Zoller-2
In reply to this post by Roberto Ierusalimschy
On 02/21/2013 02:51 PM, Roberto Ierusalimschy wrote:

>>>> Then I added
>>>>
>>>>
>>>> #ifndef _WIN32
>>>> #define __cdecl
>>>> #endif
>>>>
>>>> static void __cdecl laction (int i) {
>>>> ____________+++++++
>>>
>>> Why is this needed?
>>
>> Because signal handlers require it:
>>
>>    http://msdn.microsoft.com/en-us/library/xdkz3x12%28v=vs.71%29.aspx
>
> Are you sure?  According to this page, it seems that this declaration
> should not be necessary:
>
>    http://msdn.microsoft.com/en-us/library/zkwh89ks%28v=vs.80%29.aspx
>
>    __cdecl
>    [...]
>    This is the default calling convention for C and C++ programs.
>    [...]
>    Because the C naming and calling conventions are the default, the
>    only time you need to use __cdecl is when you have specified the /Gz
>    (stdcall) or /Gr (fastcall) compiler option.


Like I said in my original mail

   "to make both MS-VC with my preferred settings
    and a bunch of other compilers happy."

I throw this software embedding Lua at many compilers and ignore
your makefiles.

"Traditionally" this _cdecl or __cdecl has been needed for callbacks
in MS environments. Also for things like qsort(). I'm surprised you
aren't familiar with this quirk.

Dirk

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.2 (rc1) now available

steve donovan
On Thu, Feb 21, 2013 at 6:27 PM, Dirk Zoller <[hidden email]> wrote:
> I throw this software embedding Lua at many compilers and ignore
> your makefiles.

Well, then there is no problem ;)

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.2 (rc1) now available

Dirk Zoller-2
On 02/21/2013 05:31 PM, steve donovan wrote:
> On Thu, Feb 21, 2013 at 6:27 PM, Dirk Zoller <[hidden email]> wrote:
>> I throw this software embedding Lua at many compilers and ignore
>> your makefiles.
>
> Well, then there is no problem ;)

Really there isn't.  Forget it. I patched it here.


Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.2 (rc1) now available

Luiz Henrique de Figueiredo
In reply to this post by Scott Morgan
> Slackware64 13.37
> gcc-4.5.2
> glibc-2.13
> ncurses-5.9
> readline-5.2
>
> 'make linux' bombed without the -lncurses option.

Strange... From a recent discussion of this issue here, the consensus was
that readline should know its dependencies.

Anyway, to fix this in your case, you don't need to edit src/Makefile; can do
        make linux MYLIBS=-lncurses

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.2 (rc1) now available

Scott Morgan
On 21/02/13 19:14, Luiz Henrique de Figueiredo wrote:

>> Slackware64 13.37
>> gcc-4.5.2
>> glibc-2.13
>> ncurses-5.9
>> readline-5.2
>>
>> 'make linux' bombed without the -lncurses option.
> Strange... From a recent discussion of this issue here, the consensus was
> that readline should know its dependencies.
>
> Anyway, to fix this in your case, you don't need to edit src/Makefile; can do
> make linux MYLIBS=-lncurses

It's that whole termcap vs. ncurses thing...

$ make linux MYLIBS=-ltermcap

...worked as well.

I'm not that familiar with these libs and most googling points back to
this list and your thread asking about this issue several years ago :)

Slackware builds readline using the --with-curses configure option, but...

$ ldd -r /usr/lib64/libreadline.so
     linux-vdso.so.1 =>  (0x00007fffa65ff000)
     libc.so.6 => /lib64/libc.so.6 (0x00007fe06a17b000)
     /lib64/ld-linux-x86-64.so.2 (0x00007fe06a789000)
undefined symbol: PC    (/usr/lib64/libreadline.so)
undefined symbol: UP    (/usr/lib64/libreadline.so)
undefined symbol: BC    (/usr/lib64/libreadline.so)
undefined symbol: tgetflag    (/usr/lib64/libreadline.so)
undefined symbol: tgetent    (/usr/lib64/libreadline.so)
undefined symbol: tputs    (/usr/lib64/libreadline.so)
undefined symbol: tgoto    (/usr/lib64/libreadline.so)
undefined symbol: tgetnum    (/usr/lib64/libreadline.so)
undefined symbol: tgetstr    (/usr/lib64/libreadline.so)

Which, I think, means the option was ignored (probably because
libtermcap was present). Is this a bug with Slack's build?

Scott


Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.2 (rc1) now available

Luiz Henrique de Figueiredo
I have the same problem in one CentOS 5.9 machine around here:

        $ ldd -r /usr/lib/libreadline.so
        undefined symbol: tgetflag (/usr/lib/libreadline.so)
        ...

It does seem wrong that a shared library should not know about its dependencies.

Anyway, "make linux MYLIBS=-ltermcap" works for me too in that machine.

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.2 (rc1) now available

William Ahern
In reply to this post by Luiz Henrique de Figueiredo
On Tue, Feb 19, 2013 at 10:00 PM, Luiz Henrique de Figueiredo [hidden email]> wrote:
> Lua 5.2.2 (rc1) is now available at
>         http://www.lua.org/work/lua-5.2.2-rc1.tar.gz
<snip>
> We thank everyone for their feedback on Lua 5.2 till now.
> All feedback welcome. Thanks.

`make solaris` OK on Solaris/x86-64 11.0.

`make freebsd` OK on FreeBSD/x86-64 9.0.

`make bsd` OK on NetBSD/x86-64 5.1.2.

`make bsd` OK on OpenBSD/x86-32 5.1.

`make bsd` OK on OpenBSD/x86-64 5.2.

Tested by running 'print "hello world"' from an interactive instance.

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.2 (rc1) now available

William Ahern
On Fri, Feb 22, 2013 at 12:13:49PM -0800, William Ahern wrote:

> On Tue, Feb 19, 2013 at 10:00 PM, Luiz Henrique de Figueiredo [hidden email]> wrote:
> > Lua 5.2.2 (rc1) is now available at
> >         http://www.lua.org/work/lua-5.2.2-rc1.tar.gz
> <snip>
> > We thank everyone for their feedback on Lua 5.2 till now.
> > All feedback welcome. Thanks.
>
> `make solaris` OK on Solaris/x86-64 11.0.
>
> `make freebsd` OK on FreeBSD/x86-64 9.0.
>
> `make bsd` OK on NetBSD/x86-64 5.1.2.
>
> `make bsd` OK on OpenBSD/x86-32 5.1.
>
> `make bsd` OK on OpenBSD/x86-64 5.2.
>
> Tested by running 'print "hello world"' from an interactive instance.

Oops. I was testing -rc2 on NetBSD. That explains why I didn't get the same
error in NetBSD as another poster. But I was testing -rc1 on others. *sigh*
I copy+pasted the URL from two different sources but wasn't paying
attention.

I'll try again....


Reply | Threaded
Open this post in threaded view
|

Re: [ANN] Lua 5.2.2 (rc1) now available

Aaron B.
On Fri, 22 Feb 2013 12:20:30 -0800
William Ahern <[hidden email]> wrote:

> Oops. I was testing -rc2 on NetBSD. That explains why I didn't get the same
> error in NetBSD as another poster. But I was testing -rc1 on others. *sigh*
> I copy+pasted the URL from two different sources but wasn't paying
> attention.

Yup, -rc1 fails but -rc2 works on every NetBSD I've tried (5.1.2/amd64
and 5.0.1/sparc64.)

--
Aaron B. <[hidden email]>

12