lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


On Sun, Apr 19, 2015 at 10:00 AM, Hisham <h@hisham.hm> wrote:
> Hi!
>
> Congrats on the release! Here's some feedback.
>
> My first attempt was to close the repo and run "make".
>
> I got these errors, typical of a missing -lm somewhere (the "Getting
> started" step didn't mention editing compiler or platform flags
> anywhere, though)
>
>  [CC]    bin/luac
> /Data/Variable/tmp/ccfOyfGn.o: In function `numarith':
> one.c:(.text+0xc9f5): undefined reference to `pow'
> one.c:(.text+0xca05): undefined reference to `floor'
> one.c:(.text+0xca20): undefined reference to `fmod'
> /Data/Variable/tmp/ccfOyfGn.o: In function `numisinteger':
> one.c:(.text+0x12651): undefined reference to `floor'
> /Data/Variable/tmp/ccfOyfGn.o: In function `tointeger_aux':
> one.c:(.text+0x14e0f): undefined reference to `floor'
> /Data/Variable/tmp/ccfOyfGn.o: In function `luaV_execute':
> one.c:(.text+0x17e30): undefined reference to `fmod'
> one.c:(.text+0x18087): undefined reference to `floor'
> one.c:(.text+0x18209): undefined reference to `pow'
> collect2: error: ld returned 1 exit status
> aux/rules.mk:2: recipe for target 'bin/luac' failed
> make: *** [bin/luac] Error 1
>
> (This is on 32-bit Linux.)
>

Apparently on Musl systems the math symbols are already exported by
libc.so. On others like glibc it is not.

Adding -lm to the compile line of luac indeed fixes the issue. My
mistake for now testing on glibc systems.
Thanks for the report.

> And here's a feature suggestion for future releases: LuaRocks integration.
>
> "What??", you might say, "This is minimalistic, all-static, LuaRocks
> doesn't fit the picture".
>
> However, 75% of all LuaRocks packages use the builtin build system, so
> in theory they can be mechanically integrated into your system. Have
> LuaRocks install them into a sandbox directory (`luarocks install
> --tree=/some/sandbox foo`), and then move files over. Using it to
> compile C code statically is more work, but it's also mechanizable, as
> all the information you need is in the rockspec
> (luarocks/build/builtin.lua shows how to use it). With that machinery
> in place, then adding new modules would be really, single-line
> trivial.
>
> For the other 25%, you can simply fail if build.type in a rockspec is
> ~= "builtin" with "unsupported package", and you'll still have
> hundreds of new packages for your users to choose from. Plus, your
> users get dependency tracking for free when integrating modules.
>

This is a welcome feature.

Thanks for the hints. I'll look into integrating Luarocks.

> Cheers,
> -- Hisham
>

Cheers!