Is there a way to install a racket package either:
as a statically linked native executable?
have raco install it to specific path where it can be packaged and distributed as native linux distribution package?
There are two questions here. The first one being if it's possible to create a racket package as a statically linked native executable. If you mean a single executable with all the libraries statically linked, the answer is no. You can, however, create a racket distribution of your application that you can then install on machines without racket. See https://docs.racket-lang.org/raco/exe-dist.html
The second question is if you can use raco install to install the above mentioned package and the answer is no. raco will install pkgs, libraries into the system, for use with racket but not an application in a system-wide manner.
My advice is to use raco distribute and then use a system installer get it into the target system. For arch linux, I would create a raco distribute of my application and then I would create an AUR to distribute my application to my target users.
Related
The PostgreSQL used to provide EDB package for Linux x86_64 till version 10.15 like postgresql-10.15-1-linux-x64-binaries.tar.gz.
Now we want to upgrade PostgreSQL to version 13.1 and EDB package for it is not available.
Hence we want to create the package our own using documentation link. But we are able to compile package but it is not including all required files such and header and libs for SSL, tar.
How to generate a complete relocatable package like postgresql-10.15-1-linux-x64-binaries.tar to run PostgreSQL as standalone software on RHEL6/7/8 SUSE, SLES12/15 Linux versions.
or
Are there any special instructions to generate PostgreSQL 13.1 package like postgresql-10.15-1-linux-x64-binaries.tar?
I recommend that you use the PGDG packages.
Building from source is of course also an option, but I recommend that you do not try to create standalone binary packages. The proper way for that would be linking the software statically, which is not supported by the build process and would require you to have static libraries for all referenced software.
You could attempt to add all linked shared libraries to the software distribution, but you would have to make sure that these libraries are used instead of the ones on the default shared library path, which is difficult.
It seems to me that you are trying to re-invent the wheel here, and the wheel in this case is a docker container. Use that and stop worrying.
I am trying to install SDL2 on Linux Ubuntu 18.04. However there are 2 types of packages available on the repository, the 'normal' library version and the development files version.
libsdl2-2.0-0/bionic-updates,bionic-security 2.0.8+dfsg1-1ubuntu1.18.04.4 amd64
Simple DirectMedia Layer
libsdl2-dev/bionic-updates,bionic-security 2.0.8+dfsg1-1ubuntu1.18.04.4 amd64
Simple DirectMedia Layer development files
What I am asking is are there differences between the two version for developing application/game using SDL2 and which one should I install if I am just starting to learn SDL2?
Ubuntu (and other Linux distributions) often divide up packages this way: the first package contains libraries and executables needed to run something compiled with the package (SDL2 in this case), the dev packages contains the headers, additional libraries or config files needed to compile a program with package. You want to install both; normally installing the dev version of the package will pull in the other as a dependency.
You will need both, most likely :)
The lib package contains the binary SDL library. That's needed to run a program.
But in order to develop an application, you need the C header files to include in your source code - assuming that you want to create a program in C or C++. The compiler needs these files to 'see' the functions provided by the lib.
If you want to use SDL library in a different way, you could also use python and python-pygame-sdl2.
I'm running an old version of my linux distro (fedora, but this is not very relevant) and for reasons which are completely irrelevant I'm not in a position to update it. However I do need a newer version of gcc and some other libraries than those supplied by my old distro.
I could compile a newer gcc and all the other libraries of course but I thought the simplest way would be to install a minimal set of packages from the latest distro version to a directory and then just chroot there. This way I'd take advantage of the binary packages present in the newest distro and all the infrastructure around it (like dependency installation, etc.) and I wouldn't need to compile everything from source.
My question is this: if I only would like to be able to compile with the most recent gcc and run those programs, what is the minimal set of packages I need? Since we are talking about fedora, what is the minimal set of rpms (beyond glibc and gcc)? Note that I don't need any X environment, networking, or anything like that, only the most basic terminal tools.
The minimal set varies depending on your user needs and what you're linking with. What I do when making a chroot environment is have a look at the distro I want to chroot and see if they have a base rpm/deb package that kickstarts everything. Then I install that in the chroot. From there I add libraries and applications as needed.
For an example where I create a chroot for RHEL on Arch see http://www.zenskg.net/wordpress/?p=267
I would like to have a POSIX environment in Windows (to be used as a system shell) and at the same time produce native Windows executables. One option in the past was to install Cygwin and MinGW and possibly call MinGW compiler binaries from Cygwin.
Now an x64 MinGW is available straight as a Cygwin package and there are some blogs documenting how to get them play nicely together.
Before adopting this solution, I would like to know how and if the Cygwin package is different from a standalone MinGW-w64. Specifically which one is more efficient in producing native Win64 exe's? Is Cygwin package itself based on native executables, or is an extension to its gcc compilers?
Update
Some of you miscomprehended this question:
I am not interested in the difference between Cygwin and MinGW at all.
(and by the way, on the very home page of MinGW their main concern is to show how they differentiate from Cygwin)
My question instead is very specific: I am interested in the difference between a specific Cygwin package and its standalone version.
This package happens to be "mingw64-x86_64", which is split in several dependencies files, of which the most relevant is perhaps "mingw64-x86_64-gcc-core".
Sorry, but references found in some comments are utterly wrong with respect to what is asked here: first they address to Cygwin as a whole and not the mentioned package; secondly they refer to a rather old MinGW version, significantly different from that mentioned here (see here for the differences).
Someone also mentions MSYS2, which is a modern Cygwin fork, but again I am not interested to Cygwin (as whole), but to the said package.
Some of you might not be aware of this package, and in fact, if you google for "mingw64-x86_64", you don't find anything relevant for the Cygwin package, and most likely land on the general version, and this is why I am posting here.
TL;DR: Install Cygwin and the package mingw64-x86_64-gcc-core.
if the Cygwin package is different from a standalone MinGW-w64
They are the same.
MinGW - this is the project that can be found at mingw.org and
sourceforge.net/projects/mingw. This project has been superceded by the MSYS2
and MinGW-w64 projects.
Cygwin environment - Unix-like environment, namely Bash.
Cygwin compilers - these are the packages gcc-core and cygwin32-gcc-core
which include the files x86_64-pc-cygwin-gcc.exe and
i686-pc-cygwin-gcc.exe. These compilers create programs that rely on
cygwin1.dll.
MSYS2 environment - Unix-like environment, namely Bash. This is an
update to the MSYS environment provided by the old MinGW project.
MinGW-w64 compilers - these are the packages mingw64-x86_64-gcc-core and
mingw64-i686-gcc-core which include the files x86_64-w64-mingw32-gcc.exe
and
i686-w64-mingw32-gcc.exe. These compilers create Windows native
programs that do not rely on cygwin1.dll.
What do the C compilers on Cygwin generate?
For easy deployment, I'd like to ship an installation of Postgres as part of the application. Is it possible to include an already compiled and runnable version of Postgres that can be launched as process? I was able to do such thing with a Windows and MacOS version, but haven't found anything about Linux on that matter yet. Perhaps someone has tried this before and can share some insights...
You haven't stated what linux OS you're using.
Assuming it's a Redhat variant why not package your application as an RPM package? You could then declare a dependency on the standard Postgres package which would be automatically installed yum. Same principle applies if you're using Debian based systems, just a different packaging format.
From the user's perspective the OS's native packaging format is always the easiest way to install your application. Just requires effort to package it properly.
You can find cross-platform binaries from these pages on PostgreSQL official website:
For easy GUI .run installers, use links provided at http://www.enterprisedb.com/products-services-training/pgdownload.
If your target machine has no X installed on it, or you want to automate installation process with shell scripts, then you can download RPM or Deb packages from http://community.openscg.com/se/postgresql/packages.jsp
I found these links on http://www.postgresql.org/download/linux/ubuntu/, under "Cross distribution packages" and "Graphical installer".
I quote from those pages:
Note: The cross distribution packages do not fully integrate with the platform-specific packaging systems.
You must have root priviliges to install these packages, however, none of your systems library files will be altered. The supporting libraries that these binaries require are included locally as part of the install. This is the "special sauce" that allows identical binaries to run on different linux distro's.