SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
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.
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?
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.
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.
Last edited by disturbed1; 05-22-2009 at 04:28 AM.
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:
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?
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
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
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?
@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.
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.
Last edited by disturbed1; 05-24-2009 at 08:31 PM.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.