Closed xyproto closed 9 years ago
Hi Alexander, thanks for your interest in including LambdaNative in Arch Linux. I didn't even think of making it a package in a distribution as it seems to still grow quite a bit at the moment, however, having all the dependencies resolved for you may be a huge advantage. We are in the process of trying to reduce these in the near future, which may help with the ease of installation and portability, especially to build native on win32.
As for your two questions: a) We use our own configure script instead of autoconf, as this was much simpler and allowed us to do a few things not easily achieved otherwise. In fact we originally had an autoconf/configure approach but this seemed better when we started the open source framework. - At the moment I would doubt it runs when it is not located with all the other files, as it uses relative path names everywhere and depends on the locations of the SETUP and PROFILE files. b) Well we use configure the exact same way as you describe (./configure Appname; make; make install), except for one-four parameters that are added after the configure to select what to build and how to do it. Hence, I would feel it is the right name for it (at least for the time being).
Cheers Matthias
Great, thanks for the good answer. Looking forward to the planned changes that you describe. Feel free to send me a ping once you feel lambdanative might be ready.
Cheers
Hi Alexander, I will keep this open as a reminder to get this done and get back to you. Thanks
@xyproto, as of f052222 you should be able to package lambdanative, with the package installer needing to patch the scripts/lambdanative so that LAMBDANATIVE= points to the location the lambdanative source is installed to. The user can then use lambdanative
command (e.g. lambdanative init
in their code directory to setup the build scripts).
The syntax is described in the scripts/lambdanative usage, but maybe @clpetersen can update the Wiki to provide some examples for this?
Maybe also look at [System wide installation](../wiki/System wide installation) on the Wiki?
Great! I'll look into it.
Packaging lambdanative now works fine, but when building applications with the lambdanative script, the build process attempts to touch /usr/share/lambdanative/modules/config/config.scm
, which is installed on the system and therefore read-only.
Also, the build process downloads libraries like "zlib", that are already installed on the system. Is this on purpose?
The config.scm read-only issue is fixed in commit 98b70e0, thanks for finding that. The independent compilation of libraries that may exist on the host system is intentional.. this ensures the same version is used in all builds, regardless of target. System libraries are also often dynamic, and the headers sometimes missing, so can't be rolled into the lambdanative payload.
Thanks for fixing the issue with the confg.scm file and thanks for the explanation.
One would think that targeting the latest version of the dynamic libraries, for Linux, would also be a viable alternative. Because of the possibility of security issues, targeting older library versions is usually not desirable. And if you should decide to target the latest version instead of old versions, using the dynamic libraries would make more sense than using static libraries. Especially on Arch Linux, where the libraries are always the latest version. I guess distributions like Red Hat (which are very clever with security updates, by all means) would have to suffer with possibly insecure statically compiled binaries, while the users would have to wait for all installed lambdanative applications to be recompiled with the new library versions.
When it comes to the Arch Linux package for Lambdanative, it is now available as an unofficial package here: https://aur.archlinux.org/packages/lambdanative/
After being tested there for a while, there is a possibility that it can become an official package in the future.
Thanks @xyproto - it is great to hear you got your package done. Would it help for us to release a new version including @clpetersen's fix so you can include a tarball from https://github.com/part-cw/lambdanative/releases or is a git clone the preferred method on Arch Linux?
Finally, about the libraries: At least for our internal use it is very important to have the same libraries throughout all supported platforms as this (hopefully) simplifies debugging. As you mentioned a lot of distributions ship with rather old, but security patched, libraries (e.g. glibc 2.13 on Debian wheezy). We can consider adding some dynamic linking support (feel free to file an issue for it), but it is not a current priority for us. Sorry!
Git is normally the prefered way of downloading sources for packages, so there is no need for source tarballs. If the Arch Linux package should ever be out of date and in need of a quick update, don't hesitate to click the "Flag package out-of-date" button on the package webpage and I'll get notified immediately and update it. There is also the possibility of leaving a comment if something else needs to be improved.
It is fully understandable that you wish to prioritize that applications should be easier to debug, when it comes to library use.
Best of luck with the further development of lambdanative, it's a promising project!
Thanks @xyproto, it is exciting to see this project being shipped with a Linux distribution. I agree that dynamic linking of libraries to allow security updates without recompiling the application is a desirable feature (I am mainly thinking libcrypto) but currently can't think about an easy way to do this while maintaining good debugging capabilities, especially for out mobile platforms. Please feel free to ping us again if something comes to mind or you have other improvement suggestions.
Hi,
In time, I wish to package lambdanative as an official Arch Linux package.
However, I see two obstacles:
I already made gambit-c an official package, in preparation for moving lambdanative, but I need your help in planning how it's supposed to be packaged for this to happen.
Best regards, Alexander Rødseth