Patchwork [04/12] lbase64: New package

login
register
mail settings
Submitter Assaf Inbal
Date May 20, 2013, 12:56 p.m.
Message ID <1369054604-26139-4-git-send-email-shmuelzon@gmail.com>
Download mbox | patch
Permalink /patch/245023/
State Changes Requested
Headers show

Comments

Assaf Inbal - May 20, 2013, 12:56 p.m.
This package adds base64 encode/decode functionality for Lua

Signed-off-by: Assaf Inbal <shmuelzon@gmail.com>
---
 package/Config.in          |  1 +
 package/lbase64/Config.in  |  6 ++++++
 package/lbase64/lbase64.mk | 30 ++++++++++++++++++++++++++++++
 3 files changed, 37 insertions(+)
 create mode 100644 package/lbase64/Config.in
 create mode 100644 package/lbase64/lbase64.mk
Thomas Petazzoni - May 20, 2013, 2:52 p.m.
Dear Assaf Inbal,

On Mon, 20 May 2013 15:56:36 +0300, Assaf Inbal wrote:

> +define LBASE64_BUILD_CMDS
> +	$(MAKE) -C $(@D) CC="$(TARGET_CC)" CFLAGS="$(TARGET_CFLAGS) -fPIC" so
> +endef

Using $(TARGET_CONFIGURE_OPTS) here would be better if possible.

Also, we're normally supposed to handle both the shared library and
static library build. Ideally, when BR2_PREFER_STATIC_LIB is disabled,
build both the shared and the static library, and when
BR2_PREFER_STATIC_LIB is enabled, build only the static library.

> +
> +define LBASE64_INSTALL_TARGET_CMDS
> +	$(INSTALL) "$(@D)/base64.so" "$(TARGET_DIR)/usr/lib/lua"
> +endef

We normally don't quote file paths, and we use the following syntax:

	$(INSTALL) -D $(@D)/base64.so $(TARGET_DIR)/usr/lib/lua/base64.so

Thanks,

Thomas
Assaf Inbal - May 20, 2013, 3:23 p.m.
Hey Thomas,

Thank you for the comments.
Using TARGET_CONFIGURE_OPTS wont save much since I still need to override
CFLAGS and add -fPIC (as is done in other Lua packages).

Also, regarding the static library, the output of the package is always a
shared object since it needs to be loaded dynamically by Lua scripts. The
default target of the package is a test so I need to specifically specify
the target.

Lastly, I updated the patch for the install command.

Good day,
Assaf


On Mon, May 20, 2013 at 5:52 PM, Thomas Petazzoni <
thomas.petazzoni@free-electrons.com> wrote:

> Dear Assaf Inbal,
>
> On Mon, 20 May 2013 15:56:36 +0300, Assaf Inbal wrote:
>
> > +define LBASE64_BUILD_CMDS
> > +     $(MAKE) -C $(@D) CC="$(TARGET_CC)" CFLAGS="$(TARGET_CFLAGS) -fPIC"
> so
> > +endef
>
> Using $(TARGET_CONFIGURE_OPTS) here would be better if possible.
>
> Also, we're normally supposed to handle both the shared library and
> static library build. Ideally, when BR2_PREFER_STATIC_LIB is disabled,
> build both the shared and the static library, and when
> BR2_PREFER_STATIC_LIB is enabled, build only the static library.
>
> > +
> > +define LBASE64_INSTALL_TARGET_CMDS
> > +     $(INSTALL) "$(@D)/base64.so" "$(TARGET_DIR)/usr/lib/lua"
> > +endef
>
> We normally don't quote file paths, and we use the following syntax:
>
>         $(INSTALL) -D $(@D)/base64.so $(TARGET_DIR)/usr/lib/lua/base64.so
>
> Thanks,
>
> Thomas
> --
> Thomas Petazzoni, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com
>
Francois Perrad - May 20, 2013, 4 p.m.
2013/5/20 Assaf Inbal <shmuelzon@gmail.com>

> This package adds base64 encode/decode functionality for Lua
>
> Signed-off-by: Assaf Inbal <shmuelzon@gmail.com>
> ---
>  package/Config.in          |  1 +
>  package/lbase64/Config.in  |  6 ++++++
>  package/lbase64/lbase64.mk | 30 ++++++++++++++++++++++++++++++
>  3 files changed, 37 insertions(+)
>  create mode 100644 package/lbase64/Config.in
>  create mode 100644 package/lbase64/lbase64.mk
>
> diff --git a/package/Config.in b/package/Config.in
> index d980871..0845881 100644
> --- a/package/Config.in
> +++ b/package/Config.in
> @@ -307,6 +307,7 @@ menu "LUA libraries/modules"
>  source "package/cgilua/Config.in"
>  source "package/copas/Config.in"
>  source "package/coxpcall/Config.in"
> +source "package/lbase64/Config.in"
>  source "package/luacjson/Config.in"
>  source "package/luaexpat/Config.in"
>  source "package/luafilesystem/Config.in"
> diff --git a/package/lbase64/Config.in b/package/lbase64/Config.in
> new file mode 100644
> index 0000000..bd8503a
> --- /dev/null
> +++ b/package/lbase64/Config.in
> @@ -0,0 +1,6 @@
> +config BR2_PACKAGE_LBASE64
> +       bool "lbase64"
> +       help
> +         A base64 library for Lua
> +
> +         http://luaforge.net/projects/lbase64/
> diff --git a/package/lbase64/lbase64.mk b/package/lbase64/lbase64.mk
> new file mode 100644
> index 0000000..e253f24
> --- /dev/null
> +++ b/package/lbase64/lbase64.mk
> @@ -0,0 +1,30 @@
> +#############################################################
> +#
> +# lbase64
> +#
> +#############################################################
> +
> +LBASE64_VERSION =
>

LBASE64_VERSION = 20100323
use the same version as in LuaRocks, this is the date in the source
lbase64.c

François

Note: the module mime in LuaSocket provides the same kind of features.


+LBASE64_SITE = http://www.tecgraf.puc-rio.br/~lhf/ftp/lua/5.1
> +LBASE64_SOURCE = lbase64.tar.gz
> +LBASE64_LICENSE = Public domain
> +LBASE64_LICENSE_FILES = README
> +LBASE64_DEPENDENCIES = lua
> +
> +define LBASE64_BUILD_CMDS
> +       $(MAKE) -C $(@D) CC="$(TARGET_CC)" CFLAGS="$(TARGET_CFLAGS) -fPIC"
> so
> +endef
> +
> +define LBASE64_INSTALL_TARGET_CMDS
> +       $(INSTALL) "$(@D)/base64.so" "$(TARGET_DIR)/usr/lib/lua"
> +endef
> +
> +define LBASE64_UNINSTALL_TARGET_CMDS
> +       rm -f "$(TARGET_DIR)/usr/lib/lua/base64.so"
> +endef
> +
> +define LBASE64_CLEAN_CMDS
> +       $(MAKE) -C $(@D) clean
> +endef
> +
> +$(eval $(generic-package))
> --
> 1.8.1.2
>
> _______________________________________________
> buildroot mailing list
> buildroot@busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
>
Thomas Petazzoni - May 20, 2013, 5:25 p.m.
Dear Assaf Inbal,

On Mon, 20 May 2013 18:23:22 +0300, Assaf Inbal wrote:

> Thank you for the comments.
> Using TARGET_CONFIGURE_OPTS wont save much since I still need to override
> CFLAGS and add -fPIC (as is done in other Lua packages).

I think we still do prefer:

	$(MAKE) -C $(@D) \
		$(TARGET_CONFIGURE_OPTS)
		CFLAGS="$(TARGET_CFLAGS) -fPIC"

> Also, regarding the static library, the output of the package is always a
> shared object since it needs to be loaded dynamically by Lua scripts. The
> default target of the package is a test so I need to specifically specify
> the target.

Ok. Then maybe your package needs to depend on !BR2_PREFER_STATIC_LIB.
Or maybe more of the Lua stuff, if it requires shared libraries.

Thanks,

Thomas
Arnout Vandecappelle - May 22, 2013, 6:19 a.m.
On 20/05/13 19:25, Thomas Petazzoni wrote:
>> >Also, regarding the static library, the output of the package is always a
>> >shared object since it needs to be loaded dynamically by Lua scripts. The
>> >default target of the package is a test so I need to specifically specify
>> >the target.
> Ok. Then maybe your package needs to depend on !BR2_PREFER_STATIC_LIB.
> Or maybe more of the Lua stuff, if it requires shared libraries.

  We currently probably have many packages that generate .so files even 
if PREFER_STATIC_LIB is true - that's why it is "prefer", right?

  That said, I'm certainly in favour of making the STATIC stuff more strict.

  Regards,
  Arnout
Assaf Inbal - May 22, 2013, 6:55 a.m.
> On 20/05/13 19:25, Thomas Petazzoni wrote:
>
>> >Also, regarding the static library, the output of the package is always a
>>> >shared object since it needs to be loaded dynamically by Lua scripts.
>>> The
>>> >default target of the package is a test so I need to specifically
>>> specify
>>> >the target.
>>>
>> Ok. Then maybe your package needs to depend on !BR2_PREFER_STATIC_LIB.
>> Or maybe more of the Lua stuff, if it requires shared libraries.
>>
>
>  We currently probably have many packages that generate .so files even if
> PREFER_STATIC_LIB is true - that's why it is "prefer", right?
>
>  That said, I'm certainly in favour of making the STATIC stuff more strict.


I think there is some misunderstanding regarding libraries in Lua. When Lua
libraries are created, they can either be Lua text files or C code that
uses Lua API so that the library's API can be called from Lua scripts. When
choosing the latter option, the output must be a shared object, when
calling the 'require' function in Lua to load an external file, Lua will
look for file names ending with either 'lua' or 'so'.
There is simply no way to 'statically link' a Lua library.
Thomas Petazzoni - May 22, 2013, 7:01 a.m.
Dear Arnout Vandecappelle,

On Wed, 22 May 2013 08:19:25 +0200, Arnout Vandecappelle wrote:
> On 20/05/13 19:25, Thomas Petazzoni wrote:
> >> >Also, regarding the static library, the output of the package is always a
> >> >shared object since it needs to be loaded dynamically by Lua scripts. The
> >> >default target of the package is a test so I need to specifically specify
> >> >the target.
> > Ok. Then maybe your package needs to depend on !BR2_PREFER_STATIC_LIB.
> > Or maybe more of the Lua stuff, if it requires shared libraries.
> 
>   We currently probably have many packages that generate .so files even 
> if PREFER_STATIC_LIB is true

Correct, but...

> - that's why it is "prefer", right?
> 
>   That said, I'm certainly in favour of making the STATIC stuff more strict.

... I dislike this idea of "prefer". I would like the
BR2_PREFER_STATIC_LIB option be turned into something like "Fully
static system", because this is also what is needed for non-MMU
platforms that have no shared library support. I don't really see the
point of having something that will "prefer static libraries" for some
packages and not for some other, without control on which ones. Of
course, if we could control on a per-package basis which library should
be built static and which should be built shared, this would make some
sense. But without such control, it really doesn't make any sense to me
to have a random selection of packages being built shared, and the rest
being built static, when you enable BR2_PREFER_STATIC_LIB=y.

So, to me, while this option is still named BR2_PREFER_STATIC_LIB, we
should think of it as BR2_USE_ONLY_STATIC_LIB. Maybe someday we'll
rename it? :-)

Of course, that raises the question of whether we should disable all
libraries/applications that use dlopen() libraries when this option is
enabled.

Best regards,

Thomas
Arnout Vandecappelle - May 22, 2013, 7:06 a.m.
On 22/05/13 09:01, Thomas Petazzoni wrote:
> Dear Arnout Vandecappelle,
>
> On Wed, 22 May 2013 08:19:25 +0200, Arnout Vandecappelle wrote:
>> On 20/05/13 19:25, Thomas Petazzoni wrote:
>>>>> Also, regarding the static library, the output of the package is always a
>>>>> shared object since it needs to be loaded dynamically by Lua scripts. The
>>>>> default target of the package is a test so I need to specifically specify
>>>>> the target.
>>> Ok. Then maybe your package needs to depend on !BR2_PREFER_STATIC_LIB.
>>> Or maybe more of the Lua stuff, if it requires shared libraries.
>>
>>    We currently probably have many packages that generate .so files even
>> if PREFER_STATIC_LIB is true
>
> Correct, but...
>
>> - that's why it is "prefer", right?
>>
>>    That said, I'm certainly in favour of making the STATIC stuff more strict.
>
> ... I dislike this idea of "prefer". I would like the
> BR2_PREFER_STATIC_LIB option be turned into something like "Fully
> static system", because this is also what is needed for non-MMU
> platforms that have no shared library support. I don't really see the
> point of having something that will "prefer static libraries" for some
> packages and not for some other, without control on which ones. Of
> course, if we could control on a per-package basis which library should
> be built static and which should be built shared, this would make some
> sense. But without such control, it really doesn't make any sense to me
> to have a random selection of packages being built shared, and the rest
> being built static, when you enable BR2_PREFER_STATIC_LIB=y.

  +1


> So, to me, while this option is still named BR2_PREFER_STATIC_LIB, we
> should think of it as BR2_USE_ONLY_STATIC_LIB. Maybe someday we'll
> rename it? :-)

  Probably not :-)


> Of course, that raises the question of whether we should disable all
> libraries/applications that use dlopen() libraries when this option is
> enabled.

  Hm. Does dlopen() still work when e.g. libc is linked statically? I 
guess not, because the dlopen()en library  would probably need some 
symbols from libc. Therefore, packages that dlopen() should depend on 
!BR2_PREFER_STATIC_LIB.


  Now, I would say that we require the "use only" logic only for new 
packages, and we fix packages as we go. I don't think it's worth to spend 
a lot of effort fixing all the existing packages (like lua libraries, 
gst-plugins, who knows what).


  Regards,
  Arnout
Thomas Petazzoni - May 22, 2013, 7:28 a.m.
Dear Assaf Inbal,

On Wed, 22 May 2013 09:55:14 +0300, Assaf Inbal wrote:

> >  We currently probably have many packages that generate .so files even if
> > PREFER_STATIC_LIB is true - that's why it is "prefer", right?
> >
> >  That said, I'm certainly in favour of making the STATIC stuff more strict.
> 
> I think there is some misunderstanding regarding libraries in Lua. When Lua
> libraries are created, they can either be Lua text files or C code that
> uses Lua API so that the library's API can be called from Lua scripts. When
> choosing the latter option, the output must be a shared object, when
> calling the 'require' function in Lua to load an external file, Lua will
> look for file names ending with either 'lua' or 'so'.
> There is simply no way to 'statically link' a Lua library.

Ok. In this case, presumably all those Lua modules/libraries should
have a 'depends on !BR2_PREFER_STATIC_LIB'.

Best regards,

Thomas
Bryan Hundven - May 22, 2013, 7:29 a.m.
On Wed, May 22, 2013 at 12:06 AM, Arnout Vandecappelle <arnout@mind.be> wrote:
> On 22/05/13 09:01, Thomas Petazzoni wrote:
>>
>> Dear Arnout Vandecappelle,
>>
>> On Wed, 22 May 2013 08:19:25 +0200, Arnout Vandecappelle wrote:
>>>
>>> On 20/05/13 19:25, Thomas Petazzoni wrote:
>>>>>>
>>>>>> Also, regarding the static library, the output of the package is
>>>>>> always a
>>>>>> shared object since it needs to be loaded dynamically by Lua scripts.
>>>>>> The
>>>>>> default target of the package is a test so I need to specifically
>>>>>> specify
>>>>>> the target.
>>>>
>>>> Ok. Then maybe your package needs to depend on !BR2_PREFER_STATIC_LIB.
>>>> Or maybe more of the Lua stuff, if it requires shared libraries.
>>>
>>>
>>>    We currently probably have many packages that generate .so files even
>>> if PREFER_STATIC_LIB is true
>>
>>
>> Correct, but...
>>
>>> - that's why it is "prefer", right?
>>>
>>>    That said, I'm certainly in favour of making the STATIC stuff more
>>> strict.
>>
>>
>> ... I dislike this idea of "prefer". I would like the
>> BR2_PREFER_STATIC_LIB option be turned into something like "Fully
>> static system", because this is also what is needed for non-MMU
>> platforms that have no shared library support. I don't really see the
>> point of having something that will "prefer static libraries" for some
>> packages and not for some other, without control on which ones. Of
>> course, if we could control on a per-package basis which library should
>> be built static and which should be built shared, this would make some
>> sense. But without such control, it really doesn't make any sense to me
>> to have a random selection of packages being built shared, and the rest
>> being built static, when you enable BR2_PREFER_STATIC_LIB=y.
>
>
>  +1
>
>
>
>> So, to me, while this option is still named BR2_PREFER_STATIC_LIB, we
>> should think of it as BR2_USE_ONLY_STATIC_LIB. Maybe someday we'll
>> rename it? :-)
>
>
>  Probably not :-)
>
>
>
>> Of course, that raises the question of whether we should disable all
>> libraries/applications that use dlopen() libraries when this option is
>> enabled.
>
>
>  Hm. Does dlopen() still work when e.g. libc is linked statically? I guess
> not, because the dlopen()en library  would probably need some symbols from
> libc. Therefore, packages that dlopen() should depend on
> !BR2_PREFER_STATIC_LIB.
>

When implementing static toolchain support in crosstool-ng, I avoided
building libc statically like the plague. But gcc and binutils being
built statically for the host was a win. GDB also dislikes being built
statically, because of dlopen().

-Bryan

>
>  Now, I would say that we require the "use only" logic only for new
> packages, and we fix packages as we go. I don't think it's worth to spend a
> lot of effort fixing all the existing packages (like lua libraries,
> gst-plugins, who knows what).
>
>
>
>  Regards,
>  Arnout
>
>
> --
> Arnout Vandecappelle                          arnout at mind be
> Senior Embedded Software Architect            +32-16-286500
> Essensium/Mind                                http://www.mind.be
> G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
> LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
> GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
> _______________________________________________
> buildroot mailing list
> buildroot@busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
Thomas Petazzoni - May 22, 2013, 7:30 a.m.
Dear Arnout Vandecappelle,

On Wed, 22 May 2013 09:06:57 +0200, Arnout Vandecappelle wrote:

> > So, to me, while this option is still named BR2_PREFER_STATIC_LIB, we
> > should think of it as BR2_USE_ONLY_STATIC_LIB. Maybe someday we'll
> > rename it? :-)
> 
>   Probably not :-)

Well, with the nice Config.in.legacy stuff you've done, you've opened
new horizons to people like me who like to rename config options just
for the sake of it :-)

> > Of course, that raises the question of whether we should disable all
> > libraries/applications that use dlopen() libraries when this option is
> > enabled.
> 
>   Hm. Does dlopen() still work when e.g. libc is linked statically? I 
> guess not, because the dlopen()en library  would probably need some 
> symbols from libc. Therefore, packages that dlopen() should depend on 
> !BR2_PREFER_STATIC_LIB.

Yes, I believe so.

>   Now, I would say that we require the "use only" logic only for new 
> packages, and we fix packages as we go. I don't think it's worth to spend 
> a lot of effort fixing all the existing packages (like lua libraries, 
> gst-plugins, who knows what).

Yes, I agree. For now, the BR2_PREFER_STATIC_LIB=y configurations in
the autobuilders are raising a sufficient number of issues, so let's
try to solve those first. Once this settle down, I'll enable something
that checks whether any shared library is installed in the
BR2_PREFER_STATIC_LIB=y case, and which will make the build fail if
it's the case.

Best regards,

Thomas
Thomas Petazzoni - May 22, 2013, 7:42 a.m.
Dear Bryan Hundven,

On Wed, 22 May 2013 00:29:57 -0700, Bryan Hundven wrote:

> >  Hm. Does dlopen() still work when e.g. libc is linked statically? I guess
> > not, because the dlopen()en library  would probably need some symbols from
> > libc. Therefore, packages that dlopen() should depend on
> > !BR2_PREFER_STATIC_LIB.
> 
> When implementing static toolchain support in crosstool-ng, I avoided
> building libc statically like the plague.

With glibc, sure. However, uClibc was, as far as I know, designed from
the ground up to allow static linking, which is needed for some non-MMU
platforms.

> But gcc and binutils being built statically for the host was a win.
> GDB also dislikes being built statically, because of dlopen().

In this case, gdb for the target would have to be
'depends on !BR2_PREFER_STATIC_LIB'. I don't believe it's a problem:
it's unlikely that anyone will want to run a full-blown gdb on a
non-MMU platform. Non-MMU platform users are reasonable people: they
use cross-gdb + gdbserver :)

Best regards,

Thomas
Bryan Hundven - May 22, 2013, 7:46 a.m.
On Wed, May 22, 2013 at 12:42 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Bryan Hundven,
>
> On Wed, 22 May 2013 00:29:57 -0700, Bryan Hundven wrote:
>
>> >  Hm. Does dlopen() still work when e.g. libc is linked statically? I guess
>> > not, because the dlopen()en library  would probably need some symbols from
>> > libc. Therefore, packages that dlopen() should depend on
>> > !BR2_PREFER_STATIC_LIB.
>>
>> When implementing static toolchain support in crosstool-ng, I avoided
>> building libc statically like the plague.
>
> With glibc, sure. However, uClibc was, as far as I know, designed from
> the ground up to allow static linking, which is needed for some non-MMU
> platforms.
>
>> But gcc and binutils being built statically for the host was a win.
>> GDB also dislikes being built statically, because of dlopen().
>
> In this case, gdb for the target would have to be
> 'depends on !BR2_PREFER_STATIC_LIB'. I don't believe it's a problem:
> it's unlikely that anyone will want to run a full-blown gdb on a
> non-MMU platform. Non-MMU platform users are reasonable people: they
> use cross-gdb + gdbserver :)

Fair enough. And your right, I think the only problem I had with gdb
was with python support on the target. Just adding my ad-lib. ;)

-Bryan

> Best regards,
>
> Thomas
> --
> Thomas Petazzoni, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com
Peter Korsgaard - June 16, 2013, 7:52 p.m.
>>>>> "François" == François Perrad <francois.perrad@gadz.org> writes:

 François> 2013/5/20 Assaf Inbal <shmuelzon@gmail.com>

 François>     This package adds base64 encode/decode functionality for Lua

 François>     Signed-off-by: Assaf Inbal <shmuelzon@gmail.com>
 François>     ---
 François>      package/Config.in          |  1 +
 François>      package/lbase64/Config.in  |  6 ++++++
 François>      package/lbase64/lbase64.mk | 30 ++++++++++++++++++++++++++++++
 François>      3 files changed, 37 insertions(+)
 François>      create mode 100644 package/lbase64/Config.in
 François>      create mode 100644 package/lbase64/lbase64.mk

 François>     diff --git a/package/Config.in b/package/Config.in
 François>     index d980871..0845881 100644
 François>     --- a/package/Config.in
 François>     +++ b/package/Config.in
 François>     @@ -307,6 +307,7 @@ menu "LUA libraries/modules"
 François>      source "package/cgilua/Config.in"
 François>      source "package/copas/Config.in"
 François>      source "package/coxpcall/Config.in"
 François>     +source "package/lbase64/Config.in"
 François>      source "package/luacjson/Config.in"
 François>      source "package/luaexpat/Config.in"
 François>      source "package/luafilesystem/Config.in"
 François>     diff --git a/package/lbase64/Config.in b/package/lbase64/Config.in
 François>     new file mode 100644
 François>     index 0000000..bd8503a
 François>     --- /dev/null
 François>     +++ b/package/lbase64/Config.in
 François>     @@ -0,0 +1,6 @@
 François>     +config BR2_PACKAGE_LBASE64
 François>     +       bool "lbase64"
 François>     +       help
 François>     +         A base64 library for Lua
 François>     +
 François>     +         http://luaforge.net/projects/lbase64/
 François>     diff --git a/package/lbase64/lbase64.mk b/package/lbase64/lbase64.mk
 François>     new file mode 100644
 François>     index 0000000..e253f24
 François>     --- /dev/null
 François>     +++ b/package/lbase64/lbase64.mk
 François>     @@ -0,0 +1,30 @@
 François>     +#############################################################
 François>     +#
 François>     +# lbase64
 François>     +#
 François>     +#############################################################
 François>     +
 François>     +LBASE64_VERSION =


 François> LBASE64_VERSION = 20100323
 François> use the same version as in LuaRocks, this is the date in the source lbase64.c
 François>  
 François> François

 François> Note: the module mime in LuaSocket provides the same kind of
 François> features.

Assaf, will you send an updated patch taking the review feedback into
consideration?
Assaf Inbal - June 17, 2013, 5:31 a.m.
>
> Assaf, will you send an updated patch taking the review feedback into
> consideration?


Sure thing. See attached.
Peter Korsgaard - June 17, 2013, 8:59 p.m.
>>>>> "Assaf" == Assaf Inbal <shmuelzon@gmail.com> writes:

 Assaf>     Assaf, will you send an updated patch taking the review
 Assaf>     feedback into consideration?

 Assaf> Sure thing. See attached.

Committed with minor fixes, thanks.

Patch

diff --git a/package/Config.in b/package/Config.in
index d980871..0845881 100644
--- a/package/Config.in
+++ b/package/Config.in
@@ -307,6 +307,7 @@  menu "LUA libraries/modules"
 source "package/cgilua/Config.in"
 source "package/copas/Config.in"
 source "package/coxpcall/Config.in"
+source "package/lbase64/Config.in"
 source "package/luacjson/Config.in"
 source "package/luaexpat/Config.in"
 source "package/luafilesystem/Config.in"
diff --git a/package/lbase64/Config.in b/package/lbase64/Config.in
new file mode 100644
index 0000000..bd8503a
--- /dev/null
+++ b/package/lbase64/Config.in
@@ -0,0 +1,6 @@ 
+config BR2_PACKAGE_LBASE64
+	bool "lbase64"
+	help
+	  A base64 library for Lua
+
+	  http://luaforge.net/projects/lbase64/
diff --git a/package/lbase64/lbase64.mk b/package/lbase64/lbase64.mk
new file mode 100644
index 0000000..e253f24
--- /dev/null
+++ b/package/lbase64/lbase64.mk
@@ -0,0 +1,30 @@ 
+#############################################################
+#
+# lbase64
+#
+#############################################################
+
+LBASE64_VERSION =
+LBASE64_SITE = http://www.tecgraf.puc-rio.br/~lhf/ftp/lua/5.1
+LBASE64_SOURCE = lbase64.tar.gz
+LBASE64_LICENSE = Public domain
+LBASE64_LICENSE_FILES = README
+LBASE64_DEPENDENCIES = lua
+
+define LBASE64_BUILD_CMDS
+	$(MAKE) -C $(@D) CC="$(TARGET_CC)" CFLAGS="$(TARGET_CFLAGS) -fPIC" so
+endef
+
+define LBASE64_INSTALL_TARGET_CMDS
+	$(INSTALL) "$(@D)/base64.so" "$(TARGET_DIR)/usr/lib/lua"
+endef
+
+define LBASE64_UNINSTALL_TARGET_CMDS
+	rm -f "$(TARGET_DIR)/usr/lib/lua/base64.so"
+endef
+
+define LBASE64_CLEAN_CMDS
+	$(MAKE) -C $(@D) clean
+endef
+
+$(eval $(generic-package))