LinuxQuestions.org - slackware64 /usr/lib /usr/lib64 question

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - slackware64 /usr/lib /usr/lib64 question (https://www.linuxquestions.org/questions/slackware-14/slackware64-usr-lib-usr-lib64-question-727692/)

slackware64 /usr/lib /usr/lib64 question

Having a PEBKAC issue here :)
I've never used a 64bit system set up this way. They've been pure 64bit with everything simply in /usr/lib with no /usr/lib64. IIRC That's how Arch used to do it.

My question is, should I continue patching all these makefiles that have libdir=/usr/lib hard coded to keep a sane system? What are the side effects of not putting all the libs in /usr/lib64? These are for the sources that don't use or follow --libdir= and LDFLAGS="-L/usr/lib64".

Can I rm -rf /usr/lib then ln -s /usr/lib64 /usr/lib and still have things work. There are a couple of files in /usr/lib now {codecs/ crda/ libsyslinux.a rpm/ sendmail siconv/ syslinux/ terminfo/ trn/} which came from a stock install.

There are not any 32bit programs I need to run. If I did, that's what KVM is for :)

PS. I want some Slackware64 Swag!!!!! hint hint open a zazzle shop

Don't go symlinking to /lib64 and /usr/lib64. If arch is using /lib and /usr/lib they are simply doing things 'wrong' -at least according to the FSHS standards.
If you dn't need 32-bit programs you should be all set to use Slackware64 without problems with a fresh install.

Quote:

Originally Posted by gnashley (Post 3548899)

I am most likely wrong about Arch. Been a while. I do recall not having to worry if something was in /usr/lib or /usr/lib64. Perhaps I'm paying better attention now compared to then.

My main concern is those apps that want to put their shared objects in /usr/lib rather than /usr/lib64. What the consequence will be if I miss one, and the $.so's are placed in /usr/lib. Would this negatively effect the system?

I don't know of any program that cannot be made to install libs to /usr/lib64, every one I've tried I've gotten to install properly. So if you have a problem with a particular one just say which one.

Quote:

Originally Posted by H_TeXMeX_H (Post 3549073)

I don't know of any program that cannot be made to install libs to /usr/lib64, every one I've tried I've gotten to install properly. So if you have a problem with a particular one just say which one.

Never said I couldn't make them ;) My question was what happens when shared objects are installed to /usr/lib, rather than /usr/lib64

Off the top of my head - there are a dozen or so others I've come across so far as well.

a52dec (requires make.am and configure to be patched)
aften (requires sed-foo on cmake_install.cmake ignores -DLIB_SUFFIX=)
OpenAL (same as aften)
libebml (requires sed-foo on make/linux/Makefile)
libmatroska (same as libebml)

SDL-Perl and soundtouch 1.4.0 (1.3.1 is ok) have other issues.

Quote:

Originally Posted by disturbed1 (Post 3549099)

I think you are doing something wrong then.
Look at the slackware64 packages I uploaded for a52dec, libebml and libmatroska for instance:

http://www.slackware.com/~alien/slac...s/a52dec/pkg64
http://www.slackware.com/~alien/slac.../libebml/pkg64
http://www.slackware.com/~alien/slac...matroska/pkg64

All it needs is that you specify /usr/lib64 as the libdir when you run "configure". Look at the accompanying SlackBuild scripts.

Eric

Quote:

I think you are doing something wrong then.

Of course I am.
libdir=$PKG/usr/lib${LIBDIRSUFFIX} :)
That's what I needed for libembl and libmatroska They were not in my SlackBuild. Tried passing libdir=/usr/lib${LIBDIRSUFFIX} <-left off the $PKG
Thanks.

For a52dec we'll leave it as a PEBKAC issue :redface:

Did I do something strange with aften and OpenAL as well?

Has anyone looked at SDL-gfx and SDL-perl.

Here's updated patches for soundtouch which should fix the 64-bit issues:
soundtouch-1.4.0-mmx-sse-compile-fix.patch

Code:

diff -up soundtouch/source/SoundTouch/Makefile.in~ soundtouch/source/SoundTouch/Makefile.in

--- soundtouch/source/SoundTouch/Makefile.in~        2009-02-15 11:21:36.000000000 +0100

+++ soundtouch/source/SoundTouch/Makefile.in        2009-02-15 11:23:30.000000000 +0100

@@ -209,7 +209,9 @@ libSoundTouch_la_SOURCES = AAFilter.cpp 

 # Note by authore: '-msse2' might not work in non-X86 compilations. If someone can

 # fix this script to automatically check for CPU architecture, please submit a patch 

 # to me.

-AM_CXXFLAGS = -O3 -msse2 -fcheck-new -I../../include

+AM_CXXFLAGS = -fcheck-new -I../../include

+mmx_optimized.lo : AM_CXXFLAGS = -mmmx -fcheck-new -I../../include

+sse_optimized.lo : AM_CXXFLAGS = -msse -fcheck-new -I../../include

 all: all-am

 

 .SUFFIXES:

soundtouch-1.4.0-x86_64-asm-broken.diff

Code:

--- ./include/STTypes.h.00        2009-05-23 10:28:43.000000000 +0200

+++ ./include/STTypes.h        2009-05-23 10:29:54.000000000 +0200

@@ -87,7 +87,7 @@

  

  #endif

 

-    #if (WIN32 || __i386__ || __x86_64__)

+    #if (WIN32 || __i386__)

        /// Define this to allow X86-specific assembler/intrinsic optimizations. 

        /// Notice that library contains also usual C++ versions of each of these

        /// these routines, so if you're having difficulties getting the optimized

soundtouch-remove-sse.diff

Code:

--- ./source/SoundTouch/Makefile.am.01        2009-05-23 10:34:54.000000000 +0200

+++ ./source/SoundTouch/Makefile.am        2009-05-23 10:36:33.000000000 +0200

@@ -36,7 +36,7 @@

 # Note by authore: '-msse2' might not work in non-X86 compilations. If someone can

 # fix this script to automatically check for CPU architecture, please submit a patch 

 # to me.

-AM_CXXFLAGS=-O3 -msse2 -fcheck-new -I../../include

+AM_CXXFLAGS=-O3 -fcheck-new -I../../include

 

 

 # other linking flags to add

Optional patches which you may find useful:
soundtouch-libversion.diff

Code:

--- ./source/SoundTouch/Makefile.am.00        2009-01-25 17:32:53.000000000 +0100

+++ ./source/SoundTouch/Makefile.am        2009-05-23 10:34:54.000000000 +0200

@@ -44,3 +44,4 @@

 # libSoundTouch_la_LIBADD = libSoundTouchOpt.la

 # libSoundTouchOpt_la_SOURCES = mmx_optimized.cpp sse_optimized.cpp 

 # libSoundTouchOpt_la_CXXFLAGS = -O3 -msse2 -fcheck-new -I../../include

+libSoundTouch_la_LDFLAGS= -version-info 1:0:0

soundtouch-nostrip.diff

Code:

--- ./source/Makefile.in.02        2009-01-25 17:33:10.000000000 +0100

+++ ./source/Makefile.in        2009-05-23 10:43:09.000000000 +0200

@@ -407,7 +407,7 @@

 installcheck: installcheck-recursive

 install-strip:

        $(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \

-          install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \

+          install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG= \

          `test -z '$(STRIP)' || \

            echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install

 mostlyclean-generic:

--- ./include/Makefile.in.02        2009-01-25 17:33:10.000000000 +0100

+++ ./include/Makefile.in        2009-05-23 10:41:39.000000000 +0200

@@ -345,7 +345,7 @@

 installcheck: installcheck-am

 install-strip:

        $(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \

-          install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \

+          install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG= \

          `test -z '$(STRIP)' || \

            echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install

 mostlyclean-generic:

--- ./Makefile.in.02        2009-01-25 17:33:10.000000000 +0100

+++ ./Makefile.in        2009-05-23 10:42:13.000000000 +0200

@@ -635,7 +635,7 @@

 installcheck: installcheck-recursive

 install-strip:

        $(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \

-          install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \

+          install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG= \

          `test -z '$(STRIP)' || \

            echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install

 mostlyclean-generic:

Thanks for the patches!!!
Worked a treat.

This is what I had to use on aften and OpenAL

Code:



sed -i -e "s|{CMAKE_INSTALL_PREFIX}/lib|{CMAKE_INSTALL_PREFIX}/lib64|g" \

  cmake_install.cmake

SDL-gfx builds without error (--disable-mmx) - SDL-perl pops up the error attempting to link to SDL-gfx. Which led me to belive a problem with SDL-gfx.

Code:

Running Mkbootstrap for SDL_perl ()

chmod 644 SDL_perl.bs

rm -f blib/arch/auto/SDL_perl/SDL_perl.so

LD_RUN_PATH="/usr/X11R6/lib64" cc  -shared -O2 -fPIC SFont.o SDL_perl.o OpenGL.o  -o blib/arch/auto/SDL_perl/SDL_perl.so      \

          -L/usr/X11R6/lib64 -L/usr/lib64 -lSDL -lpthread -lGL -lGLU -lSDL_gfx -lSDL_image -lSDL_mixer -lSDL_net -lSDL_ttf -ljpeg -lpng -lsmpeg        \



/usr/lib64/gcc/x86_64-slackware-linux/4.3.3/../../../../x86_64-slackware-linux/bin/ld: /usr/X11R6/lib64/libSDL_gfx.a(SDL_gfxPrimitives.o): relocation R_X86_64_32S against `a local symbol' can not be used when making a shared object; recompile with -fPIC

/usr/X11R6/lib64/libSDL_gfx.a: could not read symbols: Bad value

collect2: ld returned 1 exit status

make: *** [blib/arch/auto/SDL_perl/SDL_perl.so] Error 1

Using CPAN gives a simular error.

Checked the SlackBuild, -fPIC is in the CFLAGS. I redownloaded the source file, and everything works fine. Strange :scratch:

Thanks for the tip on the cmake_install.cmake changes needed. I was just writing a bit of new code for handling these files in src2pkg the other day and this looks like it should be looked at.
Can you show a link to the SDL_perl archive? And what version of SDL_gfx is that?

Quote:

Originally Posted by disturbed1 (Post 3551072)

This is what I had to use on aften and OpenAL

Code:



sed -i -e "s|{CMAKE_INSTALL_PREFIX}/lib|{CMAKE_INSTALL_PREFIX}/lib64|g" \

  cmake_install.cmake

In slackware64 we just pass this to cmake:

Code:

-DLIB_SUFFIX=${LIBDIRSUFFIX}

Eric

Quote:

Originally Posted by Alien Bob (Post 3551273)

In slackware64 we just pass this to cmake:

Code:

-DLIB_SUFFIX=${LIBDIRSUFFIX}

Eric

With aften this didn't work, it was ignored and /usr/lib was used, but the approach disturbed1 mentioned above works.

You can also do:

Code:

cmake -DCMAKE_INSTALL_PREFIX=/usr -DLIB_INSTALL_DIR=/usr/lib64 .

@H_TeXMeX_H
Where was your comment yesterday! I spent forever trying to find out what parameter it was... But then had I known Cmake better, I would have just read the CMakeLists.txt and found it right way... Honestly... LIB_INSTALL_DIR really should have been standardized to look like the other cmake parameters... like LIBRARY_INSTALL_DIRECTORY... or just be made a fully standard cmake parameter and append CMAKE_ to it. I did find LIBRARY_OUTPUT_DIRECTORY but that doesn't appear to be used as expected.

Quote:

Originally Posted by H_TeXMeX_H (Post 3551297)

You can also do:

Code:

cmake -DCMAKE_INSTALL_PREFIX=/usr -DLIB_INSTALL_DIR=/usr/lib64 .

Doesn't work for aften either.

On some cmake apps it does, some need -DLIB_SUFFIX=64 like Alien Bob pointed out.

Quote:

Originally Posted by gnashley (Post 3551237)

It was a corrupt source archive, either gfx or perl, I re-downloaded both. The versions I now have are 2.0.19-beta for SDL_gfx, and 1.20.0 for SDL_perl.

Frozen bubble works, so now the Girlfriend is happy :)
Needed LIBDIR=/usr/lib64 after make install. That still seems goofy to me, like libembl and libmatroska which also needed libdir=$PKG/usr/lib64 on the same line as make install.