slackware64 /usr/lib /usr/lib64 question

disturbed1 · 05-21-2009, 10:45 PM

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

gnashley · 05-21-2009, 11:33 PM

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.

disturbed1 · 05-22-2009, 12:27 AM

Quote:

Originally Posted by gnashley

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.

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?

H_TeXMeX_H · 05-22-2009, 04:01 AM

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.

disturbed1 · 05-22-2009, 04:27 AM

Quote:

Originally Posted by H_TeXMeX_H

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.

Alien Bob · 05-22-2009, 06:54 AM

Quote:

Originally Posted by disturbed1

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.

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

disturbed1 · 05-22-2009, 07:30 AM

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

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

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

gnashley · 05-24-2009, 07:33 AM

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:

disturbed1 · 05-24-2009, 08:58 AM

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

gnashley · 05-24-2009, 12:58 PM

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?

Alien Bob · 05-24-2009, 01:59 PM

Quote:

Originally Posted by disturbed1

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

hemp4fuel · 05-24-2009, 02:30 PM

Quote:

Originally Posted by Alien Bob

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.

H_TeXMeX_H · 05-24-2009, 02:38 PM

You can also do:

Code:

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

lumak · 05-24-2009, 03:57 PM

@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.

disturbed1 · 05-24-2009, 08:13 PM

Quote:

Originally Posted by H_TeXMeX_H

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

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?

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.