| Message ID | 1369054604-26139-4-git-send-email-shmuelzon@gmail.com |
|---|---|
| State | Changes Requested |
| Headers | show |
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
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 >
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 >
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
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
> 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.
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
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
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
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
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
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
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
>>>>> "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, will you send an updated patch taking the review feedback into > consideration? Sure thing. See attached.
>>>>> "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.
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))
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