Skip to content

Fix Docker: embed rpath and copy libcups.so.2 into runtime stage (issue #1275)#1582

Open
abubakarsabir924-cell wants to merge 3 commits into
OpenPrinting:masterfrom
abubakarsabir924-cell:fix/docker-libcups-runtime-issue-1275
Open

Fix Docker: embed rpath and copy libcups.so.2 into runtime stage (issue #1275)#1582
abubakarsabir924-cell wants to merge 3 commits into
OpenPrinting:masterfrom
abubakarsabir924-cell:fix/docker-libcups-runtime-issue-1275

Conversation

@abubakarsabir924-cell
Copy link
Copy Markdown
Contributor

@abubakarsabir924-cell abubakarsabir924-cell commented May 18, 2026

Problem

Closes #1275

docker compose up starts but container exits immediately with:
/usr/sbin/cupsd: error while loading shared libraries: libcups.so.2:
cannot open shared object file: No such file or directory

Root Causes

  1. PR Update Dockerfile to Multi-Stage #1153 regression: libcups.so.2 and CUPS support directories
    were not copied from builder into runtime stage
  2. Runtime apt packages missing from runtime stage
  3. No RPATH in binaries so dynamic linker cannot find libcups.so.2

Fix

  • Pass LDFLAGS='-Wl,-rpath,/usr/lib64' at configure time
  • Explicitly COPY libcups.so.2 into runtime stage
  • Install correct runtime packages in runtime stage
  • Add Browsing No to prevent avahi crash in container
  • Run ldconfig in runtime stage

Tested

PR OpenPrinting#1153 introduced a multi-stage Dockerfile but left two bugs:

1. libcups.so.2 was not copied into the runtime stage, causing:
   error while loading shared libraries: libcups.so.2: cannot open
   shared object file: No such file or directory

2. Runtime apt dependencies (openssl, libavahi-client3, etc.)
   were missing from the runtime stage.

Fix:
- Pass LDFLAGS='-Wl,-rpath,/usr/lib64' at configure time
- Explicitly COPY libcups.so.2 into runtime stage
- Install correct runtime packages in runtime stage
- Add Browsing No to prevent avahi crash in container
- Run ldconfig in runtime stage

Fixes OpenPrinting#1275
@abubakarsabir924-cell
Copy link
Copy Markdown
Contributor Author

Hi @michaelrsweet Sir,

I've been investigating issue #1275 where docker compose up fails
with libcups.so.2: cannot open shared object file.

After deep analysis I found two root causes from PR #1153:

  1. libcups.so.2 was not copied into the runtime stage
  2. Runtime apt packages were missing (openssl, libavahi-client3, etc.)
  3. No RPATH embedded in binaries

I tested this fix on Debian Linux:

  • docker build completes successfully
  • Container stays running (docker ps shows Up)
  • CUPS web UI responds with HTTP 200 on port 631

Also fixed avahi assertion crash (browser.c:245) by adding
Browsing No to cupsd.conf since avahi-daemon cannot run
properly inside a Docker container without dbus.

Would appreciate your review. Thanks!

@michaelrsweet michaelrsweet self-assigned this May 18, 2026
@michaelrsweet michaelrsweet added bug Something isn't working platform issue Issue is specific to an OS or desktop labels May 18, 2026
Copy link
Copy Markdown
Member

@michaelrsweet michaelrsweet left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See comments.

Comment thread Dockerfile Outdated
Comment thread Dockerfile Outdated
- Remove LDFLAGS rpath (not needed, not portable across architectures)
- Use make install DESTDIR=/buildroot instead of copying individual files
- Add lib64->lib symlink and run ldconfig for library discovery

Tested: container stays Up, curl returns HTTP 200
@abubakarsabir924-cell
Copy link
Copy Markdown
Contributor Author

abubakarsabir924-cell commented May 19, 2026

Sir @michaelrsweet,

Updated the fix based on your review feedback:

  1. Removed LDFLAGS rpath completely

  2. Used make install DESTDIR=/buildroot as you suggested

  3. Added --libdir=/usr/lib to configure so libcups.so.2 installs
    to the standard path that ldconfig finds on all architectures
    (avoids the /usr/lib64 x86_64-specific issue you pointed out)

Tested on Debian Linux:

  • docker build successful
  • Container stays Up
  • curl returns HTTP 200

Thanks for the review!

Previous approach used /usr/lib64 which is x86_64 specific and
not present in Ubuntu's ldconfig search path. Using --libdir=/usr/lib
at configure time ensures libcups.so.2 installs to the standard
location that ldconfig finds on all architectures.

Also using make install DESTDIR=/buildroot as suggested by
@michaelrsweet to copy the entire build root instead of
individual files.

Tested: container stays Up, curl returns HTTP 200
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working platform issue Issue is specific to an OS or desktop

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Unable to run cups in docker container

2 participants