this post was submitted on 25 Mar 2024
14 points (93.8% liked)

Linux

48287 readers
632 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago
MODERATORS
AgreeableLandscape@lemmy.ml
nooter692@lemmy.ml
MarcellusDrum@lemmy.ml
cypherpunks@lemmy.ml
cyclohexane@lemmy.ml
d3Xt3r@lemmy.nz
14
Create an app including binary/library dependencies (lemmy.world)
submitted 8 months ago* (last edited 8 months ago) by Magister@lemmy.world to c/linux@lemmy.ml
11 comments fedilink hide all child comments
 

I have an old application, EagleCAD, from 2014, a 32bit app, I managed to install it on my linux (Debian based, 64bits) and it works fine, but I had to look for and install some lib manually.

How can I package all this, the bin and libs, into one that I could easily re-install on about any distro? AppImage? Flatpak? Snap?

$ ldd ./eagle
	linux-gate.so.1 (0xf7ef4000)
	libXrender.so.1 => /lib/i386-linux-gnu/libXrender.so.1 (0xf7ec4000)
	libXrandr.so.2 => /lib/i386-linux-gnu/libXrandr.so.2 (0xf7eb5000)
	libXcursor.so.1 => /lib/i386-linux-gnu/libXcursor.so.1 (0xf7ea8000)
	libfreetype.so.6 => /lib/i386-linux-gnu/libfreetype.so.6 (0xf7dd8000)
	libfontconfig.so.1 => /lib/i386-linux-gnu/libfontconfig.so.1 (0xf7d85000)
	libXext.so.6 => /lib/i386-linux-gnu/libXext.so.6 (0xf7d6f000)
	libX11.so.6 => /lib/i386-linux-gnu/libX11.so.6 (0xf7c1d000)
	libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xf7c18000)
	libXi.so.6 => /lib/i386-linux-gnu/libXi.so.6 (0xf7c03000)
	libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xf7bfc000)
	librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0xf7bf7000)
	libssl.so.1.0.0 => /lib/i386-linux-gnu/libssl.so.1.0.0 (0xf7b8a000)
	libcrypto.so.1.0.0 => /lib/i386-linux-gnu/libcrypto.so.1.0.0 (0xf798b000)
	libstdc++.so.6 => /lib/i386-linux-gnu/libstdc++.so.6 (0xf7600000)
	libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf7886000)
	libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xf785f000)
	libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf7200000)
	/lib/ld-linux.so.2 (0xf7ef6000)
	libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xf7842000)
	libXfixes.so.3 => /lib/i386-linux-gnu/libXfixes.so.3 (0xf783a000)
	libpng16.so.16 => /lib/i386-linux-gnu/libpng16.so.16 (0xf75c3000)
	libbrotlidec.so.1 => /lib/i386-linux-gnu/libbrotlidec.so.1 (0xf782a000)
	libexpat.so.1 => /lib/i386-linux-gnu/libexpat.so.1 (0xf7597000)
	libxcb.so.1 => /lib/i386-linux-gnu/libxcb.so.1 (0xf7569000)
	libbrotlicommon.so.1 => /lib/i386-linux-gnu/libbrotlicommon.so.1 (0xf7546000)
	libXau.so.6 => /lib/i386-linux-gnu/libXau.so.6 (0xf7825000)
	libXdmcp.so.6 => /lib/i386-linux-gnu/libXdmcp.so.6 (0xf753f000)
	libbsd.so.0 => /lib/i386-linux-gnu/libbsd.so.0 (0xf7528000)
	libmd.so.0 => /lib/i386-linux-gnu/libmd.so.0 (0xf7519000)
top 11 comments
sorted by: hot top controversial new old
[–] taladar@sh.itjust.works 4 points 8 months ago (1 children)

You should be aware though that distros are starting to remove 32bit support in general, as in compiling their kernels without it so it will not work for many years longer.

[–] Zamundaaa@discuss.tchncs.de 4 points 8 months ago (1 children)

That's about running on 32 bit hardware, not about running 32 bit applications

[–] taladar@sh.itjust.works 2 points 8 months ago

No, that is about the kernel code bit-rotting for a decade or more now and nobody wanting to maintain it.

[–] taladar@sh.itjust.works 3 points 8 months ago (1 children)

Copy all the libraries into one folder, then make a wrapper script using the LD_LIBRARY_PATH environment variable pointing to that folder before starting the application.

[–] Magister@lemmy.world 1 points 8 months ago (1 children)

Yeah using LD_LIBRARY_PATH or RPATH etc is how I did something similar years ago, but I think there is a more modern way to do it

[–] taladar@sh.itjust.works 1 points 7 months ago (1 children)

The modern way to run 10 year old binary applications is "don't", all of the technologies you listed are designed with a security focus and that means regular updates.

[–] Magister@lemmy.world 0 points 7 months ago (1 children)

It's an offline application, I don't care

[–] taladar@sh.itjust.works 1 points 7 months ago (1 children)

The point is nobody makes deployment technologies specifically designed for your "run an old application" use case.

[–] Magister@lemmy.world 0 points 7 months ago (1 children)

Me, I'm doing it, for myself, easier to install whenever I change distro, take a laptop, etc It's also to learn how to do it, I don't know how to create a snap/flatpak image, hence the post. And it has nothing to do with an old app, it's to have an app and all its dependencies in a container

[–] taladar@sh.itjust.works 1 points 7 months ago

Most of these technologies combine some sort of sandboxing with the containerization part and the app has to be specifically adapted to use different ways to access data and system services where it needs to break the sandbox barrier.

[–] trevor@lemmy.blahaj.zone 2 points 7 months ago* (last edited 7 months ago)

Here's what I do in my docker images:

mkdir -p /lib-your-executable
ldd ./your-executable | tr -s '[:blank:]' '\n' | grep '^/' | xargs -I % cp % /lib-your-executable

Essentially, it's the same thing that you're doing, just automating getting the dependencies, and then copying everything in the lib-your-executable dir to your LD_LIBRARY_PATH. I don't know of a better way, other than statically-linking the binaries.

EDIT: fix typo in commands.