LD_LIBRARY_PATH registration missing

Server Docker
1

I was just trying the swift:5.3.3-focal Docker image. It still seems to be missing shared library path registrations for Swift! :slight_smile:

You'll get such when trying to run a binary:

./my-test-app: error while loading shared libraries: libFoundation.so: cannot open shared object file: No such file or directory

In my own containers I add the registration this way:

RUN bash -c "echo '/usr/lib/swift/linux' > /etc/ld.so.conf.d/swift.conf;\
             echo '/usr/lib/swift/clang/lib/linux' >> /etc/ld.so.conf.d/swift.conf;\
             echo '/usr/lib/swift/pm' >> /etc/ld.so.conf.d/swift.conf;\
             ldconfig"
2

cc: @tomerd @drexin

3

thanks for the heads up @Helge_Hess1, would you like to help addressing with a PR into GitHub - apple/swift-docker: Docker Official Image packaging for Swift

4

I did a PR, but ugh, those are many Dockerfiles ...

P.S.: I think I did properly report the issue years ago. I'm a little surprised this isn't in yet, is anyone actually using those images? :-)

5

I did a PR, but ugh, those are many Dockerfiles ...

<3

yea seems like there is an opportunity there to reduce them / generate them

P.S.: I think I did properly report the issue years ago. I'm a little surprised this isn't in yet, is anyone actually using those images? :-)

I think most usage of these images is to build applications using the toolchain, not to run applications. for deployment, folks often copy the entire .build/release output directory into a plain linux docker (i.e. without the toolchain) and that directory should have everything you need to run the application

6

But that still doesn't contain the necessary runtime libraries? It might work for the static compiles, but I suspect such aren't very common yet.

7

I think it does, at least in my experience (modulo Foundation.Networking and Foundation.XML dependencies on libcurl, libxml, etc)

8

So something like libFoundation.so is magically appearing how? ;-) In the Docker examples you include the slim Swift image probably for that reason (vs just a plain Ubuntu). Though I'm not positive how that could have ever worked :thinking:

FROM swift:latest as builder
WORKDIR /root
COPY . .
RUN swift build -c release

FROM swift:slim
WORKDIR /root
COPY --from=builder /root .
CMD [".build/x86_64-unknown-linux/release/docker-test"]
9

oh yea, of course... forgot we also copy /usr/lib/swift/linux/lib*so* :D but the high level point remains that folks dont normally deploy into a docker image that carries the toolchain but to a vanilla docker images (plain ubuntu, centos, etc)

10

in the lambda examples we do ldd ".build/release/$executable" | grep swift | awk '{print $3}' | xargs cp -Lv -t "$target" which uses ldd to figure out the exact dependencies... ldd is not perfect but its an interesting technique

11

So the reason it works is that you copy the runtime libs from their subdirectories into a preconfigured LD_LIB_PATH, like say /usr/local/lib. That makes sense.
But the Docker sample from the repo should still fail? Or maybe it doesn't because it isn't using Foundation? No idea :slight_smile:

12

yea that's a good point about the example.... should look into that... probably because its not using foundation