LinuxQuestions.org

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

disturbed1 05-21-2009 11:45 PM

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

gnashley 05-22-2009 12:33 AM

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 01:27 AM

Quote:

Originally Posted by gnashley (Post 3548899)
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 05: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 05:27 AM

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.

Alien Bob 05-22-2009 07:54 AM

Quote:

Originally Posted by disturbed1 (Post 3549099)
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 08: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 :redface:

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


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

gnashley 05-24-2009 08: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 09: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 :scratch:

gnashley 05-24-2009 01: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 02:59 PM

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

hemp4fuel 05-24-2009 03:30 PM

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.

H_TeXMeX_H 05-24-2009 03:38 PM

You can also do:

Code:

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

lumak 05-24-2009 04: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 09:13 PM

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


All times are GMT -5. The time now is 06:11 PM.