Crystal: Generate a file with all needed libraries and paths

[bararchy]

Following a discussion in Gitter with @bew and @faustinoaq.
It will be really helpful to have an option to generate an output (file\stdout) with a list of all required libraries the linker used.

Using this it's an easy work to create some kind of a packer that can copy all relevant libs into a deps/ directory or just where you need it for distribution purposes.

This will also give a solution to all those users who wants static compile but have a problem getting all the needed libs to install with .a, in the sense that they can ship the application with needed libs already pulled into a single location.

[faustinoaq]

Yeah, this would make crystal apps easier to ship on some client environments without crystal installed. like end non-developer users

Right know to avoid installing dependencies in the client and avoid static linking (sometimes is just too complicated), I copy all my dependencies using:

ldd bin/executable | tr -s '[:blank:]' '\n' | grep '^/' | xargs -I % sh -c 'mkdir -p $(dirname deps%); cp % deps%;'

Then in the client machine I ship something like:

.
├── bin
│   └── console
├── console.sh
└── deps
    └── usr
        ├── lib
        │   ├── libatomic_ops.so.1
        │   ├── libcrypto.so.1.1
        │   ├── libdl.so.2
        │   ├── libevent-2.1.so.6
        │   ├── libgcc_s.so.1
        │   ├── libgc.so.1
        │   ├── libpcre.so.1
        │   └── librt.so.1
        └── lib64
            └── ld-linux-x86-64.so.2

Then inside console.sh is this:

LD_LIBRARY_PATH=$(pwd)/deps/usr/lib:$(pwd)/deps/usr/lib64 ./bin/console

[asterite]

I have no idea how the compiler can figure this out. If @faustinoaq's suggestion works, I think this can be put in a wiki or blog and this issue closed.

[bew]

@asterite the objective here is not to generate a file with the libs full paths, but only the name of all the libs needed for a program, so for example, with a simple puts "hello!", the generated file would look like:

libpcre.so
libgc.so
libpthread.so
libevent-2.1.so
librt.so
libdl.so
libc.so

Or something like that.

I think this information can be found by the compiler by remembering all lib used, and check the @[Link(..)] attribute on them.

[asterite]

@bew Yup, I have no idea how to obtain that list. I think that's the linker's job. And we are definitely not adding logic to the compiler to interface with the many linkers available...

[bararchy]

Well, I'll close this as it seems to be maybe a different tool's job