32 bit libraries installed in /usr/lib64 instead of /usr/lib #4133

Closed
michaelrsweet opened this Issue Jul 1, 2012 · 7 comments

Comments

Projects
None yet
1 participant
Collaborator

michaelrsweet commented Jul 1, 2012

Version: 1.5.3
CUPS.org User: Ged

Out of sheer desperation in an attempt to solve a different issue I downloaded the source for version 1.5.3 of the CUPS and installed it on an up-to-date 32-bit Debian Squeeze. Result, misery.

/etc/init.d/cups start

cupsd: Child exited with status 127
cups: unable to start scheduler.

Further investigation revealed that the 32-bit shared libraries for 1.5.3 had been placed in /usr/lib64. The old (1.4.4) libraries were still in /usr/lib, and at least one entry point was missing from the old libraries (_cups_strcasecmp if I remember correctly).

To fix this issue I simply moved the libraries into /usr/lib and cups started. No progress yet on the issue that I'm actually trying to solve, unfortunately, perhaps more on that later...

Collaborator

michaelrsweet commented Jul 4, 2012

CUPS.org User: mike

Please supply a copy of the Makedefs and config.log files from your build.

Also, are you building e source downloaded from cups.org or the Debian sources?

Collaborator

michaelrsweet commented Jul 4, 2012

CUPS.org User: Ged

Sorry, I thought it was clear that the source that I compiled was from the CUPS Website but obviously it wasn't clear enough.

Makedefs and config.log to follow.

Collaborator

michaelrsweet commented Jul 4, 2012

CUPS.org User: Ged

Makedefs and config.log attached as MC.tgz

Collaborator

michaelrsweet commented Jul 16, 2012

CUPS.org User: mike

Hmm, I can't reproduce. Did you perhaps have a directory named /usr/lib64 prior to building CUPS? If so, CUPS will assume you have a LSB-conforming 64-bit environment.

Using --libdir=/usr/lib when configuring CUPS will suppress the check for /usr/lib64 and put things in the expected places...

Collaborator

michaelrsweet commented Jul 16, 2012

CUPS.org User: Ged

Yes, it appears that there was indeed a directory /usr/lib64 already in existence on the system. Until the compilation of CUPS, the content of that directory was just /usr/lib64/fakeroot/ and contents (two files).

I do not know why the directory is there, presumably a Debian installer put it there as I've just checked half a dozen other 32-bit Debian systems and they all contain the same /usr/lib64/fakeroot/ directory.

Collaborator

michaelrsweet commented Oct 1, 2012

CUPS.org User: mike

Fixed in Subversion repository.

Collaborator

michaelrsweet commented Oct 1, 2012

"str4133.patch":

Index: config-scripts/cups-directories.m4

--- config-scripts/cups-directories.m4 (revision 10619)
+++ config-scripts/cups-directories.m4 (working copy)
@@ -106,7 +106,7 @@
libdir="$exec_prefix/lib32"
;;
Linux*)

  •       if test -d /usr/lib64; then
    
  •       if test -d /usr/lib64 -a ! -d /usr/lib64/fakeroot; then
            libdir="$exec_prefix/lib64"
        fi
        ;;
    

michaelrsweet added this to the Stable milestone Mar 17, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment