<br><br><div class="gmail_quote">On 23 November 2010 21:05, Florian Forster <span dir="ltr"><<a href="mailto:octo@collectd.org">octo@collectd.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi Julien,<br>
<div class="im"><br>
On Mon, Nov 22, 2010 at 11:03:14PM +0100, Schmurfy wrote:<br>
> this discussion started with octo as private messages on github but he<br>
> wisely asked me to post it on the mailing list so anyone can take part<br>
> in it so here I am !<br>
<br>
</div>thanks for taking this here :) And sorry for not looking closer at your<br>
branch yet. I certainly hope to make some time later this week.<br>
<br></blockquote><div>No problems :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
> […] the problem comes from the fact that the official lua distribution<br>
<div class="im">> is a static library which cannot be embedded in the shared library<br>
> built for collectd (I tried but failed miserably)<br>
<br>
</div>The problem is that in order to be able to link static libraries into<br>
shared objects (dynamic libraries), the static library has be be<br>
compiled with some special linker settings (-fPIC). This is an annoying<br>
problem, because many people, including many maintainers of packages of<br>
libraries, don't know this and have a hard time reproducing this bug,<br>
because it doesn't show up on a x86 system.<br>
<br>
About the two options:<br>
<br>
> The first one is to link to a shared library release of lua […]<br>
<div class="im">> The second one is to include the lua sources themselves into the collectd<br>
</div>> plugin, […]<br>
<br>
In my opinion, the second option is out of question. We've done this<br>
with liboping and libiptc in the past and nothing good came out of this.<br>
You have all the problems you have with shared objects [*] but in an<br>
even more severe variant [**]. We still include libltdl because that's<br>
the way libtool works, but with the same result [0].<br>
<br>
I'd go for a variant of the first option: Simply do a normal check for<br>
the library using autoconf and link with libtool. This will<br>
automatically get you the shared library if it is available and fall<br>
back to the static library if necessary. Being the default behavior this<br>
is what most people, including package maintainers, expect and know how<br>
to deal with.<br></blockquote><div>I will certainly need your help on this ;)</div><div>While I have no problems writing the C code itself I am not too friendly with the build systems which are in my opinion far too complex to handle for newcomers (autoconf that said) and I only have a really vague idea of what libtool does and why it exists.</div>
<div>For most of my projects (personal or profesional) I usually stick with a simple Makefile but I understand the need for tools such as autoconf for bigger projects.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
I'd like a comment on the (apparently common) "other languages should be<br>
statically linked" misconception: Shared objects have a system to cope<br>
with incompatible binary versions. A dynamic libraries implementing a<br>
scripting language is nothing special and certainly no exception. If the<br>
language itself changes, this is either transparent to the application<br>
(annoying for the user, but not our problem) or it's an API change, for<br>
which numerous detection mechanisms and solutions exist. All the reasons<br>
for dynamic linking apply to scripting languages and DSLs just as well.<br>
<br>
In the worst case, the API provided to scripts depends on the scripting<br>
language's version. If so, that's how it is. Period.<br>
<br>
To back my claims up by facts:<br>
<br>
* The Python plugin supports Python 2 *and* Python 3, which has a<br>
substantially changed concept of what a "string" is. Changes to a<br>
scripting languages hardly ever get any more sever than this.<br>
* The Java plugin has been tested with Java 1.4 through 1.6.<br>
* The Perl plugin works with Perl 5.8 and 5.10. I'm not sure about<br>
version 5.6, but I *think* that worked, too.<br>
<br>
If we can handle these complex and mainly "stand alone" languages and<br>
they manage to maintain mechanisms to work with changes made to them,<br>
I'm confident a language *intended to be integrated* will manage to keep<br>
up, too.<br></blockquote><div>As far as i am am concerned it was more a thought than a deeply anchored misconception ^^</div><div>As long as it works I am fine with the painless method but my only experience on embedded language until now is with ruby 1.8 and while it can be used embedded it is clearly not designed at all for that and I ended up embedding the sources but that was not really a decision I wanted to make. I just wish to find a way that makes the installation painless for users.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
> I was also thinking about something else but linked to lua: have<br>
> anyone thought about using a higher level language to configure<br>
> filters ?<br>
<br>
</div>That does sound like an interesting though. It'll be a lot of work to<br>
implement though. Be sure to toss around some ideas on the list before<br>
implementing anything.<br></blockquote><div>I won't even start really thinking about it before I have a working lua plugin and after that I need to really understand what happens behind these filters, so it is more of a long term idea.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Regards,<br>
—octo<br>
<br>
[*] In particular: You need to rebuild collectd and other binaries the<br>
library has been linked in when there's a security problem in the<br>
library.<br>
[**] You cannot determine that collectd uses liblua using the package's<br>
build dependencies, making it extra hard to realize there's a need<br>
to rebuild collectd.<br>
[0] <<a href="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=559801" target="_blank">http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=559801</a>><br>
<font color="#888888">--<br>
Florian octo Forster<br>
Hacker in training<br>
GnuPG: 0x0C705A15<br>
<a href="http://octo.it/" target="_blank">http://octo.it/</a><br>
</font><br>-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1.4.9 (GNU/Linux)<br>
<br>
iQIcBAEBAgAGBQJM7B6MAAoJEMPSHpbi2MmghdQQAKBxM+RC2tgmjGyC8ktlhj6O<br>
GGvg9ugukFJW8Gb2U44wFmT/7RWGi29QFXD/wBQnOJkMYTbnye0+2QEyue1jkxSv<br>
hQPTYYLsqsNSvJ0CmiyFIk1Xtnznv4dtTMtlLnFyVEyQZjhJF7O/nwAtKnNKiYPO<br>
MJxmWUJVYKZHmSUz+taPrdMCaoDmJbcoGKJNBzDUA/4jWd24QLQ77KqsCJwJSEF+<br>
iD1EyEB+SJbGb7r0zd7vR6HCx+syZktBtyIBJvoIIlV+jGKvTufF0zmnAtwoulVl<br>
uqhPPFHtxp9+t4ZHfp9u0t+li9vweju5PBbYZgbqpTv/5vWOegGHBnckg58OcVuP<br>
5+ytmpROccGGFEuOXgyZpNyyKXFdsWkzv1tPUmx9bf7NbOqmu7IYuiyXN3+XMPbk<br>
mmWxjhwELYhxsVdJ/r+fMUjKDh2Yvf+oYr3rvaTgFWLH5YqsJT8PI5MK6wU2HKxt<br>
EUFDYmM1R3zNOG0M4kd+4y8depd+5o3D8hQRN+ydSfZ8+YGj/apvJocoqjyYAXG3<br>
NYWkl6kx4LKPgEs5rquB9P2sLjYs8OZ7emIinuXtSPokXbRPPxSdgn5qumrHxER+<br>
ofw4Yul53mCv/ofpRq2gEz8Fkt4yW05AKA3LsYapYzPNakEgxp7WVRrEOQjMKwL+<br>
sz04Pj49/m9uffL7DCZI<br>
=sX27<br>
-----END PGP SIGNATURE-----<br>
<br></blockquote></div><br>