[prev in list] [next in list] [prev in thread] [next in thread] 

List:       lua-l
Subject:    Re: autotools and Lua modules
From:       Jay Carlson <nop () nop ! com>
Date:       2010-06-27 1:14:10
Message-ID: AANLkTimCPl18J_9lg4n2d5Yy2iI5WvuaEJcRCDb3SRy5 () mail ! gmail ! com
[Download RAW message or body]

This is a little off-topic, but it's been driving me crazy for years.

On Sat, Jun 19, 2010 at 8:22 AM, Luiz Henrique de Figueiredo <
lhf@tecgraf.puc-rio.br> wrote:

> > Anyone know how to write a Makefile.am in order to generate a .so Lua
> > module?
>
> I'm sorry, I don't know anything about autotools but this works for me
> in Linux:
>
> MAKESO= $(CC) -shared
>
> test.so:        test.o
>        $(MAKESO) -o $@ test.o
>
> In 64-bit Linux platforms, you may need to add -fPIC to CFLAGS.
>

It's not just 64-bit Linux systems; 32-bit Linux platforms other than i386
will probably need position-independent code for dynamic shared objects.

Very few Lua modules will need -fPIC, vice -fpic; on some architectures it's
a big performance hit to ask for support for giant GOTs.  The linker will
tell you in the unlikely case you have a lot of globally visible symbols in
play.

I wish you'd recommend -fpic on i386 too.  In addition to creating dirty
pages and additional work at every load, there are security implications to
requiring writable text pages.  Getting away with non-PIC DSOs on i386 is
one of those optimizations like -ffast-math one tends to only look at when
there's significant, benchmarked differences apparent.

To be fair, lpeg's code is 30k on i386.  For most purposes, adding eight
pages of memory pressure is just lost in the noise compared to one GC cycle
of a decent-sized Lua app.  So perhaps any memory savings is swamped by the
engineering cost of maintaining a more complicated build system.

Jay

[Attachment #3 (text/html)]

<div class="gmail_quote">This is a little off-topic, but it&#39;s been driving me \
crazy for years.<br><br>On Sat, Jun 19, 2010 at 8:22 AM, Luiz Henrique de Figueiredo \
<span dir="ltr">&lt;<a \
href="mailto:lhf@tecgraf.puc-rio.br">lhf@tecgraf.puc-rio.br</a>&gt;</span> wrote:<br> \
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px \
solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">&gt; Anyone know how to \
write a Makefile.am in order to generate a .so Lua<br>

&gt; module?<br>
<br>
</div>I&#39;m sorry, I don&#39;t know anything about autotools but this works for \
me<br> in Linux:<br>
<br>
MAKESO= $(CC) -shared<br>
<br>
test.so:            test.o<br>
            $(MAKESO) -o $@ test.o<br>
<br>
In 64-bit Linux platforms, you may need to add -fPIC to \
CFLAGS.<br></blockquote><div><br>It&#39;s not just 64-bit Linux systems; 32-bit Linux \
platforms other than i386 will probably need position-independent code for dynamic \
shared objects.<br> <br>Very few Lua modules will need -fPIC, vice -fpic; on some \
architectures it&#39;s a big performance hit to ask for support for giant GOTs.   The \
linker will tell you in the unlikely case you have a lot of globally visible symbols \
in play.   <br> <br>I wish you&#39;d recommend -fpic on i386 too.   In addition to \
creating dirty pages and additional work at every load, there are security \
implications to requiring writable text pages.   Getting away with non-PIC DSOs on \
i386 is one of those optimizations like -ffast-math one tends to only look at when \
there&#39;s significant, benchmarked differences apparent.<br> <br>To be fair, \
lpeg&#39;s code is 30k on i386.   For most purposes, adding eight pages of memory \
pressure is just lost in the noise compared to one GC cycle of a decent-sized Lua \
app.   So perhaps any memory savings is swamped by the engineering cost of \
maintaining a more complicated build system.<br> <br>Jay<br></div></div>



[prev in list] [next in list] [prev in thread] [next in thread]